@Nerfaddict
.
You probably shouldn't use rate(x) to make FBW. You can, but you should most definitely use the PID instead. The reason why is freaks out is because Roll and Pitch are semi-boolean parameters. They change instantly. If you know anything about derviatives in calculus, that translates to rate(x) = infinity. No wonder it freaks out.
@FlyingHueman
.
This is due to the data type change. If you do -LandingGear, you're effectively doing either -true or -false. You can force the LandingGear to become numerical by doing LandingGear + 0. However, there are still are couple of bugs around how these values are appraised by parts so bear with it for now.
@Kakhikotchauri1
.
I don't think your code is doing anything wrong... I don't exactly understand what you're trying to do. Could you write a logic truth table for me?
@asteroidbook345
.
Holy mother of pings...
Regardless, there is a system that I cooked up with some others earlier. Idk if it's what you need, but Leonardo has the stuff right now so ask him.
@sheepsblood
.
Although I just very recently learned about PID controllers, but I think I have some idea over the syntax. So PID is used as PID(current, target, p, i, d), so current would be your currently measured parameter (e.g. Altitude), target, to my knowledge, is the target value of the parameter, and p, i, d is what you expect (proportion, integral, derivative).
@ThePilotDude
.
I can't be sure off the top of my head, but I'm fairly sure it'd go under group under gyroscope... also note that this is for the beta. I can't gurantee it works.
Ah shoot! I was just about to do this... Nice job.
As long as all bugs get fixed, the reference-point type system may be feasible with the SelectedWeapon identifier system.
@ThePilotDude
.
For your first question: As long as you can make a physics/mathematical representation, it's possible.
For your second question, yes. Try setting the group to Activate3 = -1, but I'm not going to gurantee it works right now (the beta right now has a considerable amount of bugs).
@ShockRF
.
The devs don't have time to explain math to you. Read the Wikipedia article on it. You need to know about calculus to use it.
Basically p = error, i = integral, d = derivative.
@Pulkit
.
Of course it works... you have to consider proportions. This rotator rotates 180 for an input of 1, and that means it points at 15. If you wanted to display m/s you'd have to do rate(GS)/15, not just rate(GS).
@spefyjerbf
.
On a side note, looks like there's a bug with boolean values' behavior... To properly use the new operators that'll have to get fixed first.
@vcharng
.
I'm not exactly sure if I'm on the same page, but regarding the LandingGear issue, in 1.9.1 there was an issue where LandingGear parsed as -1/1 correctly but only if it was alone. So an input of LandingGear behaved as -1/1, but if you used LandingGear in FT, it would parse as 0/1... Causing quite a few issues.
.
Try going back to 1.9.1, try the following in a rotator:
1. LandingGear
2. LandingGear + 0
You'll see that there's an issue there. The aim of the boolean system was to fix these issues.
Oh, I just tested this in 1.9.2 as well... Regarding your comment:
LG as a boolean is contradicting with its non-FT input id counterpart
This is an interesting issue. Check these: LG on 1.9.2 LG off 1.9.2
.
You should phrase yourself better though, I honestly thought you were randomly complaining, not pointing out a valid issue. I think (?) I get what you're trying to get at now. I'll plug a bug report for this.
@vcharng
.
To be accurate, 0/1 for 1.9.1 and 1/-1 for 1.9.2. Why didn't you address my previous comment though? It looks like there was some misunderstanding, I guess that's why I was so confused about what you were trying to get at. My previous comment:
In 1.9.1: LandingGear - 0.5 will be -0.5 if LandingGear is ON or 0.5 if LandingGear is OFF
.
In 1.9.202: LandingGear - 0.5 will be 0.5 if LandingGear is OFF or -1.5 if LandingGear is OFF.
It has indeed been reversed, check using the debug command.
Some images that might help you understand... Check the top left corner and the bottom center HUD reading for each. This is for 1.9.2. LG On / LG Off
This switch in negativity is due to the conversion from numerical (0/1) to boolean (true/false) this patch. 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). I think it's a step towards more consistency throughout FT personally, especially for newer learners.
Does something not look inconsistent to you? I do think that I would've preferred the values of true/false to be 1/0 instead, but if it's been decided that true/false will be 1/-1, I simply need to adapt to the new changes. Also, there's something called a compromise... I think that's what's happening here.
Values will be implicitly converted between these types if possible
You clearly haven't understood the meaning of datatypes in 1.9.2 yet. This is already been decided upon by devs- also the backwards compatibility you speak of is for (true -> 1, false -> -1), not "keeping an inconsistency bug throughout". The issue with LG itself is addressed here:
Some potential parsing bugs were fixed with - signs.
That is in regards to some of the boolean datatypes not parsing correctly, like LG. So, the breakdown: LandingGear had a bug- it got fixed. Backwards compatibility: boolean datatypes will be converted to numerical forms when possible, not meaning "keep bugs that created inconsistency".
.
Why are you so butthurt about it in the first place? It's not too big of an issue.
@Nerfaddict
.
You probably shouldn't use
rate(x)to make FBW. You can, but you should most definitely use the PID instead. The reason why is freaks out is because Roll and Pitch are semi-boolean parameters. They change instantly. If you know anything about derviatives in calculus, that translates to rate(x) = infinity. No wonder it freaks out.@FlyingHueman
.
This is due to the data type change. If you do
-LandingGear, you're effectively doing either-trueor-false. You can force theLandingGearto become numerical by doingLandingGear + 0. However, there are still are couple of bugs around how these values are appraised by parts so bear with it for now.@Mustang51
.
Quality Settings -> Predictor -> Off
@Kakhikotchauri1
.
Your syntax is wrong. For subtraction and addition, you need spaces in between terms
like + this.@Kakhikotchauri1
.
I don't think your code is doing anything wrong... I don't exactly understand what you're trying to do. Could you write a logic truth table for me?
@cedblox332
+1.
Awesome, keep on liking math.
@asteroidbook345
.
Holy mother of pings...
Regardless, there is a system that I cooked up with some others earlier. Idk if it's what you need, but Leonardo has the stuff right now so ask him.
@PositivePlanes
.
- That makes it look hideous
- That inflates your ammo count for no good reason
- They don't act like actual shell casings (look at how these tumble in the air)
+3@Skyler717
.
Yes. What more explanation do you need? If you don't understand them, you probably don't need them...
Idk mate, looks fine to me
@Skyler717
.
What exactly do you mean?
GForceis a variable number.@Ruffes123
.
Let me try the same sort of concept, and see how it works.
@Baldovino
.
They can be used against other planes. Just that they won't use them against you. Does anyone even read the dev notes? It clearly says:
Am I just making this stuff up?
@DickBrazen
+1.
There are links to the resources in the video description. As for the subtitles, I'll try to push that out if you so wish.
SimplePlanes 2 is likely a completely standalone new game, not an update to SP 1.
Might be a
flashScaleissue.@sheepsblood
.
An example from an acquaintance.
@ChisP
.
No.
@DPSAircraft
.
ActivateXX is anything from 1-8
@sheepsblood
.
Although I just very recently learned about PID controllers, but I think I have some idea over the syntax. So PID is used as
PID(current, target, p, i, d), socurrentwould be your currently measured parameter (e.g.Altitude),target, to my knowledge, is the target value of the parameter, andp, i, dis what you expect (proportion, integral, derivative).@GeneralOliverVonBismarck
+1.
I never stop people from using what I post. Go ahead.
@ThePilotDude
.
I can't be sure off the top of my head, but I'm fairly sure it'd go under
groupundergyroscope... also note that this is for the beta. I can't gurantee it works.@ThePilotDude
.
It's possible both in Overload and XML files. The XML modding meta right now is more of "First try Overload, mass edits in XML files".
Ah shoot! I was just about to do this... Nice job.
+1As long as all bugs get fixed, the reference-point type system may be feasible with the
SelectedWeaponidentifier system.@ThePilotDude
.
For your first question: As long as you can make a physics/mathematical representation, it's possible.
For your second question, yes. Try setting the
grouptoActivate3 = -1, but I'm not going to gurantee it works right now (the beta right now has a considerable amount of bugs).@Roswell
.
Definitely.
@GeneralPatrick2
+3.
Keep in mind that each casing system will create an additional 2 parts for every shot of cannon ammo. That can stack quick.
@riko
.
Yep, it's supposed to work but it's bugged right now. Remember, this is the beta...
@Randomdoggo
.
The latter. The game is the same for everyone.
@ShockRF
.
The devs don't have time to explain math to you.
Read the Wikipedia article on it. You need to know about calculus to use it.
Basically p = error, i = integral, d = derivative.
@Numbers
+1.
It's not an update. You need a special app to try it.
@EGplanes
.
It's already there. Change
functiontoMultiRole. You aren't trying hard enough..
Have you even read this post?
Clearly you aren't looking hard enough, or reading at all...
@Pulkit
.
Of course it works... you have to consider proportions. This rotator rotates 180 for an input of 1, and that means it points at 15. If you wanted to display m/s you'd have to do
rate(GS)/15, not justrate(GS).@Pulkit
.
rate(GS)will indeed get you the acceleration, but you need some sort of adequate display system. For text formatting, use the search bar.What other game are you playing? SimplePlanes is the same game across all platforms...
@jamesPLANESii
.
The absolute value of
x.@Fireaxe05
.
You need TestFlight.
@Nerfaddict
.
You don't modify it. It's a variable. You may use it in functions, however, like in
ammo(x).@Rickyjasper2
.
It's a game update, it's for every platform...
@riko
.
SelectedWeaponis a variable that equates to a string value of whatever weapon name is selected in the weapons drawer.@EliteArsenals24
.
Sure, I was just too lazy to go do it. If you so wish, I'll push one out soon.
@JusteMaker123
.
It's already there... Sort of.
@spefyjerbf
.
On a side note, looks like there's a bug with boolean values' behavior... To properly use the new operators that'll have to get fixed first.
@Nerfenthusiast
.
I don't think that's a feature. The dev console is largely for checking stuff, not interacting with the level.
@vcharng
.
I'm not exactly sure if I'm on the same page, but regarding the LandingGear issue, in 1.9.1 there was an issue where
LandingGearparsed as -1/1 correctly but only if it was alone. So an input ofLandingGearbehaved as -1/1, but if you usedLandingGearin FT, it would parse as 0/1... Causing quite a few issues..
Try going back to 1.9.1, try the following in a rotator:
1.
LandingGear2.
LandingGear + 0You'll see that there's an issue there. The aim of the boolean system was to fix these issues.
Oh, I just tested this in 1.9.2 as well... Regarding your comment:
This is an interesting issue. Check these:
LG on 1.9.2
LG off 1.9.2
.
You should phrase yourself better though, I honestly thought you were randomly complaining, not pointing out a valid issue. I think (?) I get what you're trying to get at now. I'll plug a bug report for this.
@vcharng
.
To be accurate, 0/1 for 1.9.1 and 1/-1 for 1.9.2. Why didn't you address my previous comment though? It looks like there was some misunderstanding, I guess that's why I was so confused about what you were trying to get at. My previous comment:
Some images that might help you understand... Check the top left corner and the bottom center HUD reading for each. This is for 1.9.2.
LG On / LG Off
This switch in negativity is due to the conversion from numerical (0/1) to boolean (true/false) this patch. 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). I think it's a step towards more consistency throughout FT personally, especially for newer learners.
@vcharng
.
Here's the value chart from 1.9.1 (for
Booleandata types):Brake (0, 1)LandingGear (-1, 1)
FireGuns (0, 1)
FireWeapons (0, 1)
LaunchCountermeasures (0, 1)
Activate1 (-1, 1)
Activate2 (-1, 1)
Activate3 (-1, 1)
Activate4 (-1, 1)
Activate5 (-1, 1)
Activate6 (-1, 1)
Activate7 (-1, 1)
Activate8 (-1, 1)
Does something not look inconsistent to you? I do think that I would've preferred the values of true/false to be 1/0 instead, but if it's been decided that true/false will be 1/-1, I simply need to adapt to the new changes. Also, there's something called a compromise... I think that's what's happening here.
@vcharng
.
You clearly haven't understood the meaning of datatypes in 1.9.2 yet. This is already been decided upon by devs- also the backwards compatibility you speak of is for (true -> 1, false -> -1), not "keeping an inconsistency bug throughout". The issue with LG itself is addressed here:
That is in regards to some of the boolean datatypes not parsing correctly, like LG. So, the breakdown: LandingGear had a bug- it got fixed. Backwards compatibility: boolean datatypes will be converted to numerical forms when possible, not meaning "keep bugs that created inconsistency".
.
Why are you so butthurt about it in the first place? It's not too big of an issue.
@vcharng
.
Hey, it's called normal because what was in 1.9.1 was the bug. The rendition in 1.9.2 is what it was supposed to be.
@vcharng
.
It is available to mobile... Check patch notes from last update.