Ah. A misunderstanding on my part. I will certainly mention it in the case that I use your throttleability logic (which I probably will if I build a voidframe). I will probably use a cannon approach, but the throttle logic will definitely be appropriated (Trig thrust isn't good on warp-capable ships, so your version of throttleability is MUCH better for space travel).
@ThomasRoderick That fits very well with my understanding of the lore, with some good individuality on your part too. Definitely, a warp drive that just imparted a massive force on a ship would kill the entire crew - your explanation of a warp drive makes more sense.
.
Orbitas had some extra lore related to everything breaking (I think the term was "The Grounding", but "Flashout" sounds better tbh.
.
Man. I should make a new voidframe sometime!
True, though I am just not sure how the code works. The way that numerical integration works with Funky Trees is counterintuitive for me, and may be buggy too. I'm not sure how to fix your code, but I can provide a substitute that uses some nice trig arithmetic. Each cycle stays the same length, but amount of time that the light is on can vary with throttle.
@Alpha6 I'm still playing! I actually have a build that is almost ready to upload. My job has been pretty demanding, so I don't have much motivation to post atm. Feel free to use whatever you want for lore!
@ThomasRoderick I cant test it at the moment because work is being really demanding these days. If you want flash rates to change with throttle, you can also use a sine function that has a throttle-dependent frequency.
@ThomasRoderick If you are within your part budget, then I don’t see why it would hurt to have those thrust levels. The nice part is that the control scheme will be intuitive, too!
@ThomasRoderick Ah, yeah that’s an annoying bug. Using different sets of drives would be cool. Maybe some Funky Trees with throttle inputs would make gearing more user-friendly.
@ThomasRoderick Thanks for the understanding. I had some old code that used cosine instead of sine. The new code that I pasted in my previous comment fixes it!
Referencing my recent comment, this code should work: asin(throttle) / 90
For your rotator. Check if a throttle of 50% makes the angle 60 from the horizontal, and 30 from the vertical.
Trig thrust is certainly applicable to a space situation. Corvidae’s (I’m a little dense, so I can’t follow the hint) solution was pretty much to use a small angle to produce approximately linear throttability. In other words, simply rotating your thrusters doesn’t give them perfect throttlability (50% throttle actually yields about 70% of thrust if you just rotate) because of how trigonometry works. So, to make the behavior more linear, I used small angles to the point where I could use small angle approximation.
.
Of course, Corvidae’s approach was very inefficient. Instead, we can use funky trees to give us the correct angle for “linear” throttlability (I.e 50% throttle = 50% thrust). Some inverse trig will help us here. I did some experimentation a while ago, and produced some decent code. The problem with the code was that it didn’t use the proper assumptions, so it isn’t useful, yet. Though I am certain that this approach would work.
.
We can validate this approach by checking if the angle between the horizontal and the engine is 60 degrees at 50% throttle. After all, the cosine of 60 degrees is 0.5. We can also check if the angle between the vertical and the engine is 30 for the same reasons.
.
Sorry if so rambled. Feel free to ask for more info. I can also create the rotator that will use arctrig to give you the behavior that I am describing, if you want.
Only if you want to! More features is usually good, until the control scheme gets too complicated. Also only add features that you want! That said - a shield sounds cool.
Just tried it, and its excellent! The way that you generate torque is actually quite similar to a system that is in my next upload. However, you figured out how to apply torques at an angles besides the yaw axis, which I couldn't figure out how to do. I did notice that the gyro torques were quite small at extra-high altitudes (space). I'm not sure if that was designed or not, but I think the build could benefit from having larger torques in space.
Sounds like an awful time for me to upload a build that I have worked on for months lol. Sounds fun though.
Edit: hold up. I COMPLETELY misunderstood this forum post
@ThomasRoderick Good point - Orbitas had a low beam velocity. Also, thank you! You made my day right there. It’s been a wild 4 years, and I’m glad that you have joined me. I’m at work rn, but I’ll test ASAP. Probably later this evening (I’m on pacific time).
Man, it’s been a long time since I heard that word. Nostalgia. In theory, yes - though in my experience it always was a little more random. Maybe my plane wasn’t shaped right though.
Ooh. Nice. Those old drives that I used back in the day are really buggy (the one with guns and armor), but a cannon-based drive should work perfectly!
@Aarons123 No problem! To change the direction of the bidirectional delay, we invert some of the functions: Bool * floor(smooth(clamp01(Bool), Bool ? 1 / delayTime : pow(10,10) ))
. Where: Bool = a boolean input. For example, an activation group (Activate1) delayTime = your delay time (seconds)
.
This delay behaves the way that you would expect a delay to behave. It looks the way it does to allow the smooth function to behave as we want it to.
You use a modified version of something that I call a bidirectional delay function: ceil(smooth(clamp01(Bool), Bool ? pow(10, 10) : 1 / delayTime ))
. Where: Bool = a boolean input. For example, an activation group (Activate1) delayTime = your delay time (seconds)
.
This code is the inverse of what I am used to doing, so I'm not sure if it will be right. Let me know if it works. If not, I can edit it as needed. @Aarons123 @jamesPLANESii
.
Edit: The first bool was removed as it messed up the delay.
@Jhon5O4 Of course! Be sure to use the successor system, and give credit to me in the description. These types of crediting practices are standard in the SP community. With credit, the mods won’t remove a repaint :).
I’m not sure what the key is for Mac, but you can find it in the controls menu. You will want to open the console (the hotkey can be found in your controls), and type the following commands: debugExpression “latitude” debugExpression “Longitude”
I don’t work with props too much. What exactly happens with the governor engages? Does the prop reach the designed RPM when the governor engages?
@SnoWFLakE0s Ty!
I suppose that’s true. Thankfully there is no drag in space!
+1Good observation. That’s ok though - just some extra parts.
+1This posts contains documentation for an upcoming build. If you want me to tag you in the upload, let me know!
@ThomasRoderick Something like that. I'll probably use some different terminology, but yeah, that would be the gist of it.
+1Ah. A misunderstanding on my part. I will certainly mention it in the case that I use your throttleability logic (which I probably will if I build a voidframe). I will probably use a cannon approach, but the throttle logic will definitely be appropriated (Trig thrust isn't good on warp-capable ships, so your version of throttleability is MUCH better for space travel).
+1@ThomasRoderick That would be a pretty fun crossover! I’ll consider making one.
+1Good hot take, but you are wrong. I have to disagree.
Part count is REALLY important for downloads. If you have 300 more parts than usual, expect ~1000 less downloads than usual.
@ThomasRoderick That fits very well with my understanding of the lore, with some good individuality on your part too. Definitely, a warp drive that just imparted a massive force on a ship would kill the entire crew - your explanation of a warp drive makes more sense.
+1.
Orbitas had some extra lore related to everything breaking (I think the term was "The Grounding", but "Flashout" sounds better tbh.
.
Man. I should make a new voidframe sometime!
@ThomasRoderick Sounds good! The old parachute systems are now really buggy. Think RIDs but 100x worse.
+1Awesome! I enjoy a bit of SPEcorp lore :)
+1Exactly that logic! Pretty much using the “peaks” as light pulses.
+1True, though I am just not sure how the code works. The way that numerical integration works with Funky Trees is counterintuitive for me, and may be buggy too. I'm not sure how to fix your code, but I can provide a substitute that uses some nice trig arithmetic. Each cycle stays the same length, but amount of time that the light is on can vary with throttle.
+1@Alpha6 I'm still playing! I actually have a build that is almost ready to upload. My job has been pretty demanding, so I don't have much motivation to post atm. Feel free to use whatever you want for lore!
+4@ThomasRoderick ah. Yeah, I’m not sure how to do that. Maybe superimposing a sine wave over a value of 1-Throttle would work.
+1@ThomasRoderick I cant test it at the moment because work is being really demanding these days. If you want flash rates to change with throttle, you can also use a sine function that has a throttle-dependent frequency.
+1English subtitles would really expand your target audience.
@ThomasRoderick If you are within your part budget, then I don’t see why it would hurt to have those thrust levels. The nice part is that the control scheme will be intuitive, too!
+1@ThomasRoderick Ah, yeah that’s an annoying bug. Using different sets of drives would be cool. Maybe some Funky Trees with throttle inputs would make gearing more user-friendly.
+2@ThomasRoderick Thanks for the understanding. I had some old code that used cosine instead of sine. The new code that I pasted in my previous comment fixes it!
+1Referencing my recent comment, this code should work:
+1asin(throttle) / 90
For your rotator. Check if a throttle of 50% makes the angle 60 from the horizontal, and 30 from the vertical.
@KnightOfRen When in doubt, add more hidden wings. More lift is probably what you need. Adjust thrust as needed using overload on your engines.
Trig thrust is certainly applicable to a space situation. Corvidae’s (I’m a little dense, so I can’t follow the hint) solution was pretty much to use a small angle to produce approximately linear throttability. In other words, simply rotating your thrusters doesn’t give them perfect throttlability (50% throttle actually yields about 70% of thrust if you just rotate) because of how trigonometry works. So, to make the behavior more linear, I used small angles to the point where I could use small angle approximation.
+1.
Of course, Corvidae’s approach was very inefficient. Instead, we can use funky trees to give us the correct angle for “linear” throttlability (I.e 50% throttle = 50% thrust). Some inverse trig will help us here. I did some experimentation a while ago, and produced some decent code. The problem with the code was that it didn’t use the proper assumptions, so it isn’t useful, yet. Though I am certain that this approach would work.
.
We can validate this approach by checking if the angle between the horizontal and the engine is 60 degrees at 50% throttle. After all, the cosine of 60 degrees is 0.5. We can also check if the angle between the vertical and the engine is 30 for the same reasons.
.
Sorry if so rambled. Feel free to ask for more info. I can also create the rotator that will use arctrig to give you the behavior that I am describing, if you want.
@KnightOfRen Are you trying for a VTOL System, or a standard flight system?
+1.
VTOL is actually easier on large spaceships tbh.
Only if you want to! More features is usually good, until the control scheme gets too complicated. Also only add features that you want! That said - a shield sounds cool.
+1Around 200,000 feet of altitude and 4,000 mph. Might have been operator error though.
+1Just tried it, and its excellent! The way that you generate torque is actually quite similar to a system that is in my next upload. However, you figured out how to apply torques at an angles besides the yaw axis, which I couldn't figure out how to do. I did notice that the gyro torques were quite small at extra-high altitudes (space). I'm not sure if that was designed or not, but I think the build could benefit from having larger torques in space.
+1No problem! Your walker builds are unique and very well-done. I appreciate that.
+1Sounds like an awful time for me to upload a build that I have worked on for months lol. Sounds fun though.
+6Edit: hold up. I COMPLETELY misunderstood this forum post
@ThomasRoderick Good point - Orbitas had a low beam velocity. Also, thank you! You made my day right there. It’s been a wild 4 years, and I’m glad that you have joined me. I’m at work rn, but I’ll test ASAP. Probably later this evening (I’m on pacific time).
+1Man, it’s been a long time since I heard that word. Nostalgia. In theory, yes - though in my experience it always was a little more random. Maybe my plane wasn’t shaped right though.
+1@Aarons123 Thats odd. What do you have set as the activation group? Not as the input, but the activationgroup field.
@Aarons123 Ah, I think my code is a little off. Try removing the first activate2, and see what happens.
Nice! Guns still work in a majority of situations, so you should be fine.
+1@Aarons123 ah! put a clamp01 around the first
Activate2. That should make the delay work upon deactivation. Hopefully, at least.@Aarons123 Do you need the delay when you activate, or deactivate?
EDIT: wait. next time I should read the entire comment. one sec
Ooh. Nice. Those old drives that I used back in the day are really buggy (the one with guns and armor), but a cannon-based drive should work perfectly!
+1No worries! I mean some minor details that add color or accentuate some features.
+1@ThomasRoderick Ah, yeah. Then some accents would be pretty nice. I don’t have any specifics, though it seems like you have that down!
+1Looks nice. Maybe add some minor accents to bring out the saucer shape.
+1@Aarons123 No problem! To change the direction of the bidirectional delay, we invert some of the functions:
Bool* floor(smooth(clamp01(Bool),Bool? 1 /delayTime: pow(10,10) )).
Where:
Bool= a boolean input. For example, an activation group (Activate1)delayTime= your delay time (seconds).
This delay behaves the way that you would expect a delay to behave. It looks the way it does to allow the smooth function to behave as we want it to.
You use a modified version of something that I call a bidirectional delay function:
ceil(smooth(clamp01(
Bool),Bool? pow(10, 10) : 1 /delayTime)).
Where:
Bool= a boolean input. For example, an activation group (Activate1)delayTime= your delay time (seconds).
This code is the inverse of what I am used to doing, so I'm not sure if it will be right. Let me know if it works. If not, I can edit it as needed. @Aarons123 @jamesPLANESii
.
Edit: The first bool was removed as it messed up the delay.
How should I perform a polynomial fit for my data given that I do not know what degreee will give me the best least-squares fit?
No problem. Glad I could help!
@Jhon5O4 Of course! Be sure to use the successor system, and give credit to me in the description. These types of crediting practices are standard in the SP community. With credit, the mods won’t remove a repaint :).
@WrongFlyer It should, as long as you enter those commands when the level is loaded.
I’m not sure what the key is for Mac, but you can find it in the controls menu. You will want to open the console (the hotkey can be found in your controls), and type the following commands:
debugExpression “latitude”
debugExpression “Longitude”
You can use your debug window to display coords