Problem with JU-88 A-1:
Almost Impossible for me to complete the undercarriage and a working cockpit is a bit above my abilities currently.
You can check my Ju288 LG demonstrator. Its cockpit is made in reference of Ju88 cockpit, and its landing gear should be more complicated than the Ju88, you only need to simplify it a bit.
well for larger planes they do take longer...
If you want quick adjustment of power you should really consider using propeller pitch rather than throttle to control the output.
My WWII planes with constant-speed propellers usually respond to changes within 2 seconds (but you need to know what pitch is the best at different speed and altitude)
as for manual pitch and manual throttle, they respond even faster, close to the 1 second you are hoping for.
As another person who has limited success in Funky Trees (check my landing gear post), I suggest Funky Foresters.
We don't cut down the tree, we plant them and cultivate them, therefore foresters instead of lumberjacks.
yeah with these we can have totally custom guided weapons...
I'd suggest "AngleToTarget", "PitchToTarget" and "DistanceToTarget"
And maybe a second series of "AngleToAiming" and so on.
So that we can make SACLOS missiles.
@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.
@ThomasRoderick Well this thing was a WWI concept that the luftwaffe came up in 1940... it's already outdated.
Torpedoes are expensive, that's why they tried to find a cheaper solution.
That's why this thing fell out of favor when rocket munitions and guided bombs came out.
@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.
"I have fine tuner and overpowered downloaded even though I never downloaded them"
They are now built-in in 1.9.
"I have downloaded alot more than just the nukes mod but it's the only one I have applied at the moment"
are you using Android? Android version banned mods, that's why the two mods mentioned earlier were included in vanilla game.
Problem with JU-88 A-1:
Almost Impossible for me to complete the undercarriage and a working cockpit is a bit above my abilities currently.
You can check my Ju288 LG demonstrator. Its cockpit is made in reference of Ju88 cockpit, and its landing gear should be more complicated than the Ju88, you only need to simplify it a bit.
The devs said about a "if~ Then~ Else~" clause in 1.9.202 beta, but I have yet to make it work.
But you also have 21.9K upvote now....
well for larger planes they do take longer...
If you want quick adjustment of power you should really consider using propeller pitch rather than throttle to control the output.
My WWII planes with constant-speed propellers usually respond to changes within 2 seconds (but you need to know what pitch is the best at different speed and altitude)
as for manual pitch and manual throttle, they respond even faster, close to the 1 second you are hoping for.
@TheKraken3 Yeah, maybe, perhaps the foresters are the devs who made them, and we people who use them are carpenters...
+9As another person who has limited success in Funky Trees (check my landing gear post), I suggest Funky Foresters.
We don't cut down the tree, we plant them and cultivate them, therefore foresters instead of lumberjacks.
yeah with these we can have totally custom guided weapons...
I'd suggest "AngleToTarget", "PitchToTarget" and "DistanceToTarget"
And maybe a second series of "AngleToAiming" and so on.
So that we can make SACLOS missiles.
@asteroidbook345 hole pieces is basically what I said as "part subtraction"...
Hull Parts subtraction.
+11this is a basic function for all CAD software, and with that we can easily make countless weird-shaped parts.
@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.
I prefer the kind of GA ramp, where you enter from one side and exit from other. Common for smaller aircrafts in countries with abundant land.
+5Hey 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...
@MrSilverWolf I am thinking about making a VOR, but setting the station position will be a problem...
+2@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...
@ThomasRoderick Well this thing was a WWI concept that the luftwaffe came up in 1940... it's already outdated.
+1Torpedoes are expensive, that's why they tried to find a cheaper solution.
That's why this thing fell out of favor when rocket munitions and guided bombs came out.
@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?
Oh wow they really added Calculus!
+1"I have fine tuner and overpowered downloaded even though I never downloaded them"
+2They are now built-in in 1.9.
"I have downloaded alot more than just the nukes mod but it's the only one I have applied at the moment"
are you using Android? Android version banned mods, that's why the two mods mentioned earlier were included in vanilla game.