@asteroidbook345 ok then that's what I'll do. It's morning here so the upload will probably happen in 12 hours. I'll probably also make a gif post to explain how the variables do.
@asteroidbook345 Uh, space between minus sign and variable, and LG is just an abbreviation, you need to actually write "LandingGear" when doing it...
I suppose you should know....
@asteroidbook345 No need for that.
Same thing, smooth LG function.
And then: (assume you're smoothing from -1 to 1)
Landing gear movement : -0.5 ~ 0.5
Door movement: -1 ~ -0.5 and 0.5 ~ 1
For example:
clamp01(abs(smooth(- LG, 0.25)) - 0.5)
and then set door close at 1 and open at 0.
The input would start at 1 (door close), go to 0 (door open, landing gear start moving), and then go to 1 again (landing gear stored, door close)
The reason why this is better than sine function is that sine function still moves, while absolute plus clamp can make sure your door stay 100% open.
@asteroidbook345 Smooth function.
First, set a smooth function to make a "smooth" landing gear function.
"smooth(- LandingGear, 0.25)" would go from -1 to 1 smoothly in 8 seconds.
Then you set the landing gear arms to move when this function goes from -1 to 0, and gear doors to move when 0 to 1.
So when you retract the gear, it would retract the arms first, then close the door.
When you extend the gear, it would open the door first, then extend the arm.
@jamesPLANESii I do, I just don't want anyone to underestimate what we're gonna have in 1.9.202... You see what he said, "99% don't use FT let alone calculus" NO.
@TheKraken3 Uh, no, if you look at the more popular uploaded planes, almost every one of them are using funky trees (and calculus, for 1.9.200 beta).
It will soon become a given, a must have.
@sheepsblood Yes it IS a return home navigation. It only gives you your relative position from where you started. That's why it's an INS rather than a GPS.
In my future builds I may come up with an advanced version with map and configurable starting point (Avalanche airport, Yeager, Wright, etc) but right now this is nothing more than a technology demonstrator, to show everyone what the latest FT technology can do.
@SnoWFLakE0s I'm not sure I understand the pictures.
One rotater is boolean, one is input ID, and they behave conversely?
Well yeah, from the time I noticed that my ground proximity warning failed (using boolean) while my landing gear mechanism didn't (using inputID) I knew this can't be right....
@SnoWFLakE0s " I'm assuming the devs thought it made more sense that the value of LandingGear = true when the game HUD actually shows that it's "on" (previously this wasn't the case)."
Yes this is my guess as well, but obviously devs forgot about some planes being stuck in the wormhole between 1.9.1 and 1.9.2.
The reason why LG is lit is to cope with IRL landing gear lights. But it doesn't really mean that gear down = true, gear up = false makes more sense especially when it comes to rotators and FTs.
Remember, in the current state of 1.9.2, if we don't use FT and only give LG input to a rotator, it actually DOES behave like gear down = false, gear up = true. (that's why only my ground proximity warning glitched while my landing gears didn't.
What does this mean? it means that LG as a boolean is contradicting with its non-FT input id counterpart with the exact same name. This is going to be confusing.
Think about it. We have to tell greenhorn FT-ers that LG as an inputID gives 1=up, 0=down, and LG as a FT boolean gives -1=up, 1= down. (up and down here refers to the UI symbol).
@SnoWFLakE0s That has nothing to do with reversing the negativity of LG input.
You can make all 0,1 in to -1,1 yet it's not gonna change the negativity.
What I'm experiencing is more like LG -1,1 for 1.9.1 and "1,-1" for 1.9.2.
Plus I don't see any problem with LG using the same domain as AGs.
The reason why this bothers me is that my latest creation, the Ju-288G-1, was made malfunctioning because of this 1.9.200, just a week after its release.
And I was going to release its brother G2 this weekend.
Now with this update all these plan are trashed.
I now have to wait until 1.9.2 is stable to release my G-2, and I will have to make a 1.9.2-compatible version for G1 later on. All this trouble, only because no backward compatibility AND because this update chose the worst timing to happen.
@SnoWFLakE0s Sincerely speaking the LG input was NOT a bug in 1.9.1, it's just a mis-assigned positive/negative.
Think about this: scientists made a mistake hundreds of years ago and now electrons have minus charge (which is very anti-intuitive, but no-one wants to change it because of the complexity to do so)
@Brields95 BS.
"Values will be implicitly converted between these types if possible, FOR BACKWARDS COMPATIBILITY"
This is what Andrew said, so backward compatibility is definitely a thing. And I just found something that hinders this. Therefore it is a bug.
If he didn't mention this or he tells me that he's giving up LG input compatibility then I won't say a thing, but neither of these criterion was true.
@SnoWFLakE0s The fact is Andrew said backward compatibility. Anything that doesn't do this is a bug. 1.9.1 is DEFINED as the norm since we're talking about backward compatibility here. Anything in 1.9.200 that contradicts this is the bug.
You can define 1.9.1 as wrong as you like, but you won't solve the problem that everything from 1.9.1 that uses LG input in FT has to be redesigned in 1.9.200 and thus loses backward compatibility.
Let me tell you one thing, Angle of attack in 1.9 is also reversed (positive AoA IRL is known is minus in 1.9). But I'm not going to tell Andrew to reverse this because this will make every AoA indicator from 1.9 to cease functioning..
@SnoWFLakE0s Well that's amazing.
How on earth are mobile users supposed to open that console when they don't have a keyboard?
And for that reverse thing, what's the deal now, does Andrew's "backward compatibility" no longer exists? why are we discussing as if this is entirely normal and not a bug?
@SnoWFLakE0s It's not just that, now the positive and negative for LandingGear seems to be reversed.
in 1.9.1 I used "LandingGear - 0.5" as a boolean-ish command, its effect has been REVERSED. This is not the problem of 0/1 vs. -1/1.
@AndrewGarrison
LandingGear variable is not backwards compatible because of the data category change.
If you use simple LandingGear input it's fine, but the number output for FT seems to be reversed in 1.9.202.
As a result some 1.9 mechanisms cannot work in 1.9.202 (for example, my ground proximity warning) unless the clause has been reversed.
"sideways prop wash over the tail"
=>"Spiral slipstream"
Also there's a third thing called P-factor, but I wonder how you're gonna make it happen in the game...
Does these realism affect playability for mobile players?
@xiaofootball Yes I do. I know that plane dynamics is changed strangely by ordnance. Releasing it after having it is still somehow different from not having them at all.
I was just trying to solve the problem the plane is experiencing, that is, landing instability.
@xiaofootball I gave it a try.
1. suspension is too soft. You need harder and more damper or your plane would keep bouncing around.
2. sideway traction is poor.
3. As a pusher configuration your plane is born unstable, try to XML remove nosewheel braking action.
4. the nosewheel creates a natural asymmetry, try double wheel nosewheel . The asymmetry in landing gear would either cause the plane to spin out of control or cause you to over-correct the yaw.
I think given a few hours I should be able to make this stable, but perhaps you should try yourself.
Also this is why I don't use custom landing gear on turning wheels. They behave strangely. If everything fails try to use a stock LG on the nosewheel
@Natedog120705 A WWII shipbuilding sandbox game on Steam.
It's made by a bunch of Warship Craft veterans in China, and AFAIK it hasn't supported (actually working) carriers yet
@xiaofootball Perhaps you should upload the plane and let us see what's happening.
it could be that you're loading ordnance too far outboard and causing the plane to be easily inbalanced.
The aircraft must be in the air prior to releasing the weapon
These two sounds fishy.
I have some occasions where resizable wheel with no suspension + landing after takeoff, causes the wheels to constantly bounce on and off the ground.
And obviously when the wheel is not on the ground you get no traction.
I would usually suggest having resizable wheel suspension plus another shock (i.e. double layer of suspension)
@AndrewGarrison
@WNP78
@jamesPLANESii Not for N95 with exhalation valve, which means what you exhale does not get filtered.
@asteroidbook345 go set properties on steam to "public test" and you'll get 1.9.202 beta.
Hey bro, I've uploaded the plane and a simple tutorial and tagged you. Go take a look.
@asteroidbook345
@asteroidbook345 ok then that's what I'll do. It's morning here so the upload will probably happen in 12 hours. I'll probably also make a gif post to explain how the variables do.
Or how about this, I'll upload my Ju 288 G-2 unlisted, with a modern airliner-style landing gear door action, and let you use it as a reference?
Well I think I told you about the "smooth function" method enough yesterday... What part of it do you not understand? Perhaps we can start with that.
@asteroidbook345 Uh, space between minus sign and variable, and LG is just an abbreviation, you need to actually write "LandingGear" when doing it...
I suppose you should know....
@asteroidbook345 No need for that.
Same thing, smooth LG function.
And then: (assume you're smoothing from -1 to 1)
Landing gear movement : -0.5 ~ 0.5
Door movement: -1 ~ -0.5 and 0.5 ~ 1
For example:
clamp01(abs(smooth(- LG, 0.25)) - 0.5)
and then set door close at 1 and open at 0.
The input would start at 1 (door close), go to 0 (door open, landing gear start moving), and then go to 1 again (landing gear stored, door close)
The reason why this is better than sine function is that sine function still moves, while absolute plus clamp can make sure your door stay 100% open.
@asteroidbook345 Smooth function.
First, set a smooth function to make a "smooth" landing gear function.
"smooth(- LandingGear, 0.25)" would go from -1 to 1 smoothly in 8 seconds.
Then you set the landing gear arms to move when this function goes from -1 to 0, and gear doors to move when 0 to 1.
So when you retract the gear, it would retract the arms first, then close the door.
When you extend the gear, it would open the door first, then extend the arm.
@Aeromen
@Strikefighter04
@nadvgia
@AircraftoftheRedStar
@Random40
@emanuelga
@Firepower1000
@WarHawk95
@InternationalAircraftCompany
@jamesPLANESii I do, I just don't want anyone to underestimate what we're gonna have in 1.9.202... You see what he said, "99% don't use FT let alone calculus" NO.
@TheKraken3 Uh, no, if you look at the more popular uploaded planes, almost every one of them are using funky trees (and calculus, for 1.9.200 beta).
It will soon become a given, a must have.
@TheKraken3 1.9.2 added calculus, bro. That's actually pretty big.
I think we need to think what exactly's coming from the next big update first.
It seems that the next update is 1.9.2 or something...
@MrSilverWolf If that's the case it would be easy to make, but real world VOR would usually require multiple VOR stations between the destinations...
@sheepsblood Yes it IS a return home navigation. It only gives you your relative position from where you started. That's why it's an INS rather than a GPS.
In my future builds I may come up with an advanced version with map and configurable starting point (Avalanche airport, Yeager, Wright, etc) but right now this is nothing more than a technology demonstrator, to show everyone what the latest FT technology can do.
Brakepower is already moddable for resizable wheel.
Explosion is moddable for cannon.
This calls for the existence of some Angry Birds fighters...
I think German at least had some Spitfire MkVs converted into DB605 engine...
@Shippy456 To simulate the nature of "recoilless" rifle, and to give it a look closer to the real thing.
@SnoWFLakE0s I'm not sure I understand the pictures.
One rotater is boolean, one is input ID, and they behave conversely?
Well yeah, from the time I noticed that my ground proximity warning failed (using boolean) while my landing gear mechanism didn't (using inputID) I knew this can't be right....
@SnoWFLakE0s " I'm assuming the devs thought it made more sense that the value of LandingGear = true when the game HUD actually shows that it's "on" (previously this wasn't the case)."
Yes this is my guess as well, but obviously devs forgot about some planes being stuck in the wormhole between 1.9.1 and 1.9.2.
The reason why LG is lit is to cope with IRL landing gear lights. But it doesn't really mean that gear down = true, gear up = false makes more sense especially when it comes to rotators and FTs.
Remember, in the current state of 1.9.2, if we don't use FT and only give LG input to a rotator, it actually DOES behave like gear down = false, gear up = true. (that's why only my ground proximity warning glitched while my landing gears didn't.
What does this mean? it means that LG as a boolean is contradicting with its non-FT input id counterpart with the exact same name. This is going to be confusing.
Think about it. We have to tell greenhorn FT-ers that LG as an inputID gives 1=up, 0=down, and LG as a FT boolean gives -1=up, 1= down. (up and down here refers to the UI symbol).
@SnoWFLakE0s That has nothing to do with reversing the negativity of LG input.
You can make all 0,1 in to -1,1 yet it's not gonna change the negativity.
What I'm experiencing is more like LG -1,1 for 1.9.1 and "1,-1" for 1.9.2.
Plus I don't see any problem with LG using the same domain as AGs.
The reason why this bothers me is that my latest creation, the Ju-288G-1, was made malfunctioning because of this 1.9.200, just a week after its release.
And I was going to release its brother G2 this weekend.
Now with this update all these plan are trashed.
I now have to wait until 1.9.2 is stable to release my G-2, and I will have to make a 1.9.2-compatible version for G1 later on. All this trouble, only because no backward compatibility AND because this update chose the worst timing to happen.
@SnoWFLakE0s Sincerely speaking the LG input was NOT a bug in 1.9.1, it's just a mis-assigned positive/negative.
Think about this: scientists made a mistake hundreds of years ago and now electrons have minus charge (which is very anti-intuitive, but no-one wants to change it because of the complexity to do so)
@Brields95 BS.
"Values will be implicitly converted between these types if possible, FOR BACKWARDS COMPATIBILITY"
This is what Andrew said, so backward compatibility is definitely a thing. And I just found something that hinders this. Therefore it is a bug.
If he didn't mention this or he tells me that he's giving up LG input compatibility then I won't say a thing, but neither of these criterion was true.
@SnoWFLakE0s The fact is Andrew said backward compatibility. Anything that doesn't do this is a bug. 1.9.1 is DEFINED as the norm since we're talking about backward compatibility here. Anything in 1.9.200 that contradicts this is the bug.
You can define 1.9.1 as wrong as you like, but you won't solve the problem that everything from 1.9.1 that uses LG input in FT has to be redesigned in 1.9.200 and thus loses backward compatibility.
Let me tell you one thing, Angle of attack in 1.9 is also reversed (positive AoA IRL is known is minus in 1.9). But I'm not going to tell Andrew to reverse this because this will make every AoA indicator from 1.9 to cease functioning..
@SnoWFLakE0s Well that's amazing.
How on earth are mobile users supposed to open that console when they don't have a keyboard?
And for that reverse thing, what's the deal now, does Andrew's "backward compatibility" no longer exists? why are we discussing as if this is entirely normal and not a bug?
@SnoWFLakE0s Dev consle? as in the "`" thing?
Never even considered they'll use something not available to mobile.
@SnoWFLakE0s What the hell is debug command?
I expect to see something like validation UI but I found none.
@SnoWFLakE0s It's not just that, now the positive and negative for LandingGear seems to be reversed.
in 1.9.1 I used "LandingGear - 0.5" as a boolean-ish command, its effect has been REVERSED. This is not the problem of 0/1 vs. -1/1.
@AndrewGarrison
LandingGear variable is not backwards compatible because of the data category change.
If you use simple LandingGear input it's fine, but the number output for FT seems to be reversed in 1.9.202.
As a result some 1.9 mechanisms cannot work in 1.9.202 (for example, my ground proximity warning) unless the clause has been reversed.
@AndrewGarrison does control surface input now accepts FT?
"sideways prop wash over the tail"
=>"Spiral slipstream"
Also there's a third thing called P-factor, but I wonder how you're gonna make it happen in the game...
Does these realism affect playability for mobile players?
@xiaofootball Yes I do. I know that plane dynamics is changed strangely by ordnance. Releasing it after having it is still somehow different from not having them at all.
I was just trying to solve the problem the plane is experiencing, that is, landing instability.
picture is not showing....
@xiaofootball I gave it a try.
1. suspension is too soft. You need harder and more damper or your plane would keep bouncing around.
2. sideway traction is poor.
3. As a pusher configuration your plane is born unstable, try to XML remove nosewheel braking action.
4. the nosewheel creates a natural asymmetry, try double wheel nosewheel . The asymmetry in landing gear would either cause the plane to spin out of control or cause you to over-correct the yaw.
I think given a few hours I should be able to make this stable, but perhaps you should try yourself.
Also this is why I don't use custom landing gear on turning wheels. They behave strangely. If everything fails try to use a stock LG on the nosewheel
@Natedog120705 A WWII shipbuilding sandbox game on Steam.
It's made by a bunch of Warship Craft veterans in China, and AFAIK it hasn't supported (actually working) carriers yet
@xiaofootball Perhaps you should upload the plane and let us see what's happening.
it could be that you're loading ordnance too far outboard and causing the plane to be easily inbalanced.
These two sounds fishy.
I have some occasions where resizable wheel with no suspension + landing after takeoff, causes the wheels to constantly bounce on and off the ground.
And obviously when the wheel is not on the ground you get no traction.
I would usually suggest having resizable wheel suspension plus another shock (i.e. double layer of suspension)
@thefalkenreich
@MrPorg137
@MrSilverWolf
@AircraftoftheRedStar
@Wi1dSk7
@thecrusader
@BoganBoganTheMan
@Thelegitpilot13
@RailfanEthan
@Random40
@TheFantasticTyphoon
@HarrisCraft
@Imashovel
@FranzPeterSiegfried
@TheSolarFlare
@Aarons123
@TheFantasticTyphoon
@Sm10684
@Thelegitpilot13