I think they do behave a bit differently. Whether it's accurate or not I have no idea - the issue with cases like this is there is a lot of data on airfoils in the "normal" angle of attack region but very little existing performance data and methods on predicting the behaviour in these unusal cases. The typical aerodynamicist would I suppose respond to the question "what happens if I put the wing on backwards" would be something like "don't". Unless SP2 sells three jundrillion copies and we can fund the construction of a high-reynolds wind tunnel for development use then we just have to make up something plausible.
There's no need to give the person or the matter attention really. Maybe you occasionally see a spam comment, you report it and move on with your day, it gets cleaned up at some point. All they want is attention, all we have to do is not give it to them, and they'll eventually grow up and think back and cringe at how they thought that they could somehow "destroy" a game company and it's wonderful community by... checks notes being annoying on the internet.
I can't see the images, but there is different code in the backend of FT on PC/mobile due to some platform differences - but they should should act the same. If you can give an FT expression that gives a different result on PC/mobile then I can look into it when I get time (lot on at the moment). You can also force the PC version to use the mobile-like backend with the dev console command SetExpressionEmit false (but the mobile version cannot use the PC backend). You'll have to restart the level for that to take effect.
@cosman the NACAPROP airfoil is not designed to be used on a wing, it exists for the propellor engines and it can only be used on a wing by overload/XML editing. So it's not going to be realistic
I don't see why the altitude would be stored as an integer, it's generally a floating point value, which has a much higher limit. The physics system also internally works in metres
@JA311M condition is any boolean (true/false) value. See the operators section - comparison operators produce a boolean value, and there are also boolean operators that can combine multiple
Rudder variable is just yaw + a yaw rate damping term to prevent the wobble you get from adverse yaw. As for the pitch I think I just made it so that the angle of the stabilator is set relative to the AoA instead of relative to the aircraft's body. It essentially gives the tail more authority at high AoA and makes the aircraft artificially less stable.
@Jerba x was just a stand in for whatever you wanted to drive the sine based on. In the example below I set it as sin(sum(Throttle)), with no x. Of course you can multiply throttle by a constant to change the frequency of the wave and multiply the whole expression to change the amplitude
@Jerba for that, you'd want something like sin(sum(Throttle)) since you don't want it to go all the way down to zero when you throttle down, just stop where it is.
@Jerba just sin(x) is enough for a sine wave. And yes it's mostly the same in juno, but some of the data you can access is different, and there's support for vectors
@Softballyesssss not sure what you mean by the old way, there should be backwards compatibility for all crafts, so you're free to just.. do things the however the "old way" is and it should still work.
The reason is due to the precision of the depth buffer. Insufficient depth buffer precision causes an effect called "Z-fighting" (example). SP needs good precision in depth at both very close ranges (for in-cockpit details etc) and far away (runways, roads etc), so a single depth buffer was not sufficient to cover the full range of view with adequate precision especially on some mobile platforms where the depth buffer is stored differently. So SP uses two cameras, each with their own depth buffer.
@darthgently in SP there is a menu you can open that allows you to create custom craft-level variables. You can enter the name of the variable, followed by a value it will be set to every frame. If you press the button to expand the full properties, you can also set an assignment priority that can change how it will act if the same variable is written to from multiple places, and also a condition which the variable will only update if said condition is true. In order to "set" a variable when something occurs, you can just make a setter with the condition set to only run that line when the condition is true.
@darthgently yeah, you can't really do it with PID directly. In the post it shows how you can deconstruct PID into sum and rate, so you'd use that NewSum in its place
@darthgently There are a few ways you could achieve that kind of behaviour.
One is to use the smooth function, which would have a conditional expression in both arguments. In normal mode the target point would be something like sign(x) * a_big_number where x is the input that would have gone to sum, so that the smooth is always moving towards that very far away target in the direction you want it to go, and the max movement speed is abs(x), so the speed the input changes. When in reset mode, the target value would be zero, and the speed would be set to a really high number so it can reach zero in a single frame.
The second way would be to use the variables system to keep a zero value used to "calibrate" the sum, kind of like how a digital scales calibrates. It would look something like RawSum : sum(x) SumZero : RawSum with the condition set to only run this line when you want to reset it NewSum: RawSum - SumZero
There are practical limits to how far a camera can render due to the precision of the depth buffer, and the floating point precision of the meshes being rendered.
The way JNO renders the full scale solar system is by actually having two scenes at once, the foreground scene at normal size, and then a "scale model" of the solar system that is rendered behind it. The terrain transitions between these two models when you get close to it. It gets quite complicated and unfortunately I don't have the time to help add it to SP.
@Mousewithamachinegun123 you might be viewing the http version of the site, instead of https. When you try to login, the site redirects you to the secure https site to protect your login info. If you go back to the URL you were looking at before and it starts with http:// you will appear as logged out, because for security reasons your browser will not send authentication tokens unencrypted. Changing the url to have https:// might fix that. If you have a bookmark for the site or something, make sure it's to the https:// protocol to spare that bother
I think it should have been obvious you weren't supposed to be able to do this, I'm disappointed you chose to anyway instead of letting us know. I'll be deleting most of the tags that you and others added, don't do it again and I'll be able to see if you do.
@gg5577 That's the old propeller engine part from before there were the configurable advanced propellors. It's just in there for compatibility with old builds that were made with it, it's been entirely superseded by the new ones that are fully customisable. As for what the input was set to, it was last touched well before funky trees was even a thing so I think you probably just had that set on the part before you changed the type and it carried over.
Also, I saw you edited out that bit on the phone you were using, are you definitely using the Galaxy A13? This is actually quite relevant because we've had issues with that device before; I believe it may be one of the few modern smartphones that uses 32-bit instruction set instead of 64-bit, so it shows up whenever there's an issue in the 32-bit build of the game.
@Aviator720 does it just pause for a bit and come back, or does the app completely crash end exit? And by that do you mean that it freezes when you try to enter the flight scene?
If it's a specific plane, can you let me know which? Or if it's specific to your device could you let me know what device you're running on? I don't have a lot of time so I might not be able to investigate right away but it's important to keep track of this stuff.
this isn't a bug, just behaviour of the game that you personally would rather be different
you've already pinged multiple devs about it on a different post
this post isn't for bug reporting
the update cycle this post refers to was 2 months ago and we're now very busy on making big things for the future, rather than constantly making small tweaks to SP
I would also like to point out as I have in the past that it's possible for a person to own and enjoy multiple games, we're not egotistical enough to expect that our players shall only play the games we make and nothing else. And it's not like another game gaining a player directly correlates to SP losing one. In the end it is a positive thing to have a burgeoning genre with different games filling their own niche. I'm not one to censor discussion of other games, though I do question if this post really adds anything valuable to the discussion
Unfortunately this didn't quite make it into the mod API, so you can either use an input controller as hpgbproductions says, or use reflection. If you're familiar with reflection you'd need to be calling AircraftControls.GetAxisGetter and make sure to set the contextPart argument with your part script so that it has an expressions context (this is the parameter that's not in the mod api version of the method, and it's what enables the FT parser to run). Then you would have to save the returned function and evaluate it every fixedupdate
@windshifter1 as for adding damper to floppy rotators, not really. However if you use a control base part and set the spring to zero, it will essentially become floppy (on the axes that are set as control axes in the xml). Then you can scale the damper.
is there a way to make suspension compression permanent? So when the suspension part compresses, it doesn't bounce back?
not precisely. However, you could try turning the "spring" component down to very low or zero and the "damper" right up. Spring resists displacement, and damper resists motion, so with a high damper it should resist motion but not return to its home position. However this isn't perfect because damper is proportional to motion speed directly, so small forces will still be able to deform the spring - just slowly over time. So it might look like your car is melting in the sun if you leave it out too long. That's the distinction between friction and damper, friction in this case will give full frictional force to oppose motion regardless of the speed of that motion. Unfortunately that frictional behaviour is more mathematically complex and it's not implemented anywhere except in actual collision friction. I'm not going to say it's impossible though, I think it could be in theory possible by using a piston and a damper shock in series, with the piston actively monitoring the extension of the shock and making adjustments to hold its value. But I can't say exactly how that would be achieved, only that I think it's probably possible. It also sounds very complex though and having two things in series could make the whole structure weaker in terms of the physics engine.
I think they do behave a bit differently. Whether it's accurate or not I have no idea - the issue with cases like this is there is a lot of data on airfoils in the "normal" angle of attack region but very little existing performance data and methods on predicting the behaviour in these unusal cases. The typical aerodynamicist would I suppose respond to the question "what happens if I put the wing on backwards" would be something like "don't". Unless SP2 sells three jundrillion copies and we can fund the construction of a high-reynolds wind tunnel for development use then we just have to make up something plausible.
+19There's no need to give the person or the matter attention really. Maybe you occasionally see a spam comment, you report it and move on with your day, it gets cleaned up at some point. All they want is attention, all we have to do is not give it to them, and they'll eventually grow up and think back and cringe at how they thought that they could somehow "destroy" a game company and it's wonderful community by... checks notes being annoying on the internet.
+8I can't see the images, but there is different code in the backend of FT on PC/mobile due to some platform differences - but they should should act the same. If you can give an FT expression that gives a different result on PC/mobile then I can look into it when I get time (lot on at the moment). You can also force the PC version to use the mobile-like backend with the dev console command
SetExpressionEmit false(but the mobile version cannot use the PC backend). You'll have to restart the level for that to take effect.@cosman the NACAPROP airfoil is not designed to be used on a wing, it exists for the propellor engines and it can only be used on a wing by overload/XML editing. So it's not going to be realistic
@LoganAir123 thanks for being honest but you won't get it for that reason. We removed the last batch for inactivity
@V1 what makes you so sure?
I don't see why the altitude would be stored as an integer, it's generally a floating point value, which has a much higher limit. The physics system also internally works in metres
@JA311M condition is any boolean (true/false) value. See the operators section - comparison operators produce a boolean value, and there are also boolean operators that can combine multiple
Rudder variable is just yaw + a yaw rate damping term to prevent the wobble you get from adverse yaw. As for the pitch I think I just made it so that the angle of the stabilator is set relative to the AoA instead of relative to the aircraft's body. It essentially gives the tail more authority at high AoA and makes the aircraft artificially less stable.
+3@MyNameIsAXY it's in the "memory functions" section
@Jerba x was just a stand in for whatever you wanted to drive the sine based on. In the example below I set it as
sin(sum(Throttle)), with no x. Of course you can multiply throttle by a constant to change the frequency of the wave and multiply the whole expression to change the amplitude@Jerba for that, you'd want something like
sin(sum(Throttle))since you don't want it to go all the way down to zero when you throttle down, just stop where it is.@Jerba just sin(x) is enough for a sine wave. And yes it's mostly the same in juno, but some of the data you can access is different, and there's support for vectors
i think you would lose money if you bet that
+14Just a camera is good
+3@Zhixunlin23 there's no rule about that
+4@Joshua8262 I'm not aware of any updates that broke these
+1@Softballyesssss not sure what you mean by the old way, there should be backwards compatibility for all crafts, so you're free to just.. do things the however the "old way" is and it should still work.
@Zhixunlin23 7
+1simple planes 2
+9i had to stop for a challenger 2 crossing the road once
+7we are so back
+6or should I say wing're so back
@Lwillswith2sentryguns yes, I see no reason to make the game online-only.
+19Not gonna mention those wings?
+1@LoneSpaceGaming with boolean values,
!=is logically equivalent to XOR@Aviatorloke meters I think
The reason is due to the precision of the depth buffer. Insufficient depth buffer precision causes an effect called "Z-fighting" (example). SP needs good precision in depth at both very close ranges (for in-cockpit details etc) and far away (runways, roads etc), so a single depth buffer was not sufficient to cover the full range of view with adequate precision especially on some mobile platforms where the depth buffer is stored differently. So SP uses two cameras, each with their own depth buffer.
+1@darthgently in SP there is a menu you can open that allows you to create custom craft-level variables. You can enter the name of the variable, followed by a value it will be set to every frame. If you press the button to expand the full properties, you can also set an assignment priority that can change how it will act if the same variable is written to from multiple places, and also a condition which the variable will only update if said condition is true. In order to "set" a variable when something occurs, you can just make a setter with the condition set to only run that line when the condition is true.
@darthgently yeah, you can't really do it with PID directly. In the post it shows how you can deconstruct PID into sum and rate, so you'd use that
+1NewSumin its place@darthgently There are a few ways you could achieve that kind of behaviour.
One is to use the
smoothfunction, which would have a conditional expression in both arguments. In normal mode the target point would be something likesign(x) * a_big_numberwhere x is the input that would have gone tosum, so that the smooth is always moving towards that very far away target in the direction you want it to go, and the max movement speed isabs(x), so the speed the input changes. When in reset mode, the target value would be zero, and the speed would be set to a really high number so it can reach zero in a single frame.The second way would be to use the variables system to keep a zero value used to "calibrate" the sum, kind of like how a digital scales calibrates. It would look something like
+1RawSum:sum(x)SumZero:RawSumwith the condition set to only run this line when you want to reset itNewSum:RawSum - SumZerotry now
There are practical limits to how far a camera can render due to the precision of the depth buffer, and the floating point precision of the meshes being rendered.
The way JNO renders the full scale solar system is by actually having two scenes at once, the foreground scene at normal size, and then a "scale model" of the solar system that is rendered behind it. The terrain transitions between these two models when you get close to it. It gets quite complicated and unfortunately I don't have the time to help add it to SP.
+2@Mousewithamachinegun123 you might be viewing the http version of the site, instead of https. When you try to login, the site redirects you to the secure https site to protect your login info. If you go back to the URL you were looking at before and it starts with
+1http://you will appear as logged out, because for security reasons your browser will not send authentication tokens unencrypted. Changing the url to havehttps://might fix that. If you have a bookmark for the site or something, make sure it's to thehttps://protocol to spare that botherHere's the steps for it
I think it should have been obvious you weren't supposed to be able to do this, I'm disappointed you chose to anyway instead of letting us know. I'll be deleting most of the tags that you and others added, don't do it again and I'll be able to see if you do.
+1see https://status.gearhost.com/incidents/sphc0zynhf8z
+1@thatsjustmidofficial RollInput is just Roll
@gg5577 That's the old propeller engine part from before there were the configurable advanced propellors. It's just in there for compatibility with old builds that were made with it, it's been entirely superseded by the new ones that are fully customisable. As for what the input was set to, it was last touched well before funky trees was even a thing so I think you probably just had that set on the part before you changed the type and it carried over.
Also, I saw you edited out that bit on the phone you were using, are you definitely using the Galaxy A13? This is actually quite relevant because we've had issues with that device before; I believe it may be one of the few modern smartphones that uses 32-bit instruction set instead of 64-bit, so it shows up whenever there's an issue in the 32-bit build of the game.
+2@Aviator720 does it just pause for a bit and come back, or does the app completely crash end exit? And by that do you mean that it freezes when you try to enter the flight scene?
If it's a specific plane, can you let me know which? Or if it's specific to your device could you let me know what device you're running on? I don't have a lot of time so I might not be able to investigate right away but it's important to keep track of this stuff.
+1@DatMaluchGuy19
- this isn't a bug, just behaviour of the game that you personally would rather be different
- you've already pinged multiple devs about it on a different post
- this post isn't for bug reporting
- the update cycle this post refers to was 2 months ago and we're now very busy on making big things for the future, rather than constantly making small tweaks to SP
+1The way people usually do this is by checking how much
ammoof those bombs is left and therefore how many bombs have been droppedAmazing. In hindsight it was inevitable but now it's been done. And well.
+13@Aviator720 since you're not the first person to say this I'm just going to refer you to some of my previous comments that should fill you in:
+13what we're doing
people asking about flyout
more about flyout (half a year ago)
I would also like to point out as I have in the past that it's possible for a person to own and enjoy multiple games, we're not egotistical enough to expect that our players shall only play the games we make and nothing else. And it's not like another game gaining a player directly correlates to SP losing one. In the end it is a positive thing to have a burgeoning genre with different games filling their own niche. I'm not one to censor discussion of other games, though I do question if this post really adds anything valuable to the discussion
+2Unfortunately this didn't quite make it into the mod API, so you can either use an input controller as hpgbproductions says, or use reflection. If you're familiar with reflection you'd need to be calling
AircraftControls.GetAxisGetterand make sure to set thecontextPartargument with your part script so that it has an expressions context (this is the parameter that's not in the mod api version of the method, and it's what enables the FT parser to run). Then you would have to save the returned function and evaluate it every fixedupdate@Randomplayer andrew did
+1@windshifter1 as for adding damper to floppy rotators, not really. However if you use a control base part and set the spring to zero, it will essentially become floppy (on the axes that are set as control axes in the xml). Then you can scale the damper.
@windshifter1
not precisely. However, you could try turning the "spring" component down to very low or zero and the "damper" right up. Spring resists displacement, and damper resists motion, so with a high damper it should resist motion but not return to its home position. However this isn't perfect because damper is proportional to motion speed directly, so small forces will still be able to deform the spring - just slowly over time. So it might look like your car is melting in the sun if you leave it out too long. That's the distinction between friction and damper, friction in this case will give full frictional force to oppose motion regardless of the speed of that motion. Unfortunately that frictional behaviour is more mathematically complex and it's not implemented anywhere except in actual collision friction. I'm not going to say it's impossible though, I think it could be in theory possible by using a piston and a damper shock in series, with the piston actively monitoring the extension of the shock and making adjustments to hold its value. But I can't say exactly how that would be achieved, only that I think it's probably possible. It also sounds very complex though and having two things in series could make the whole structure weaker in terms of the physics engine.