X and Y simply depend on the Cartesian system that you are using it's not really an issue. In my case I employ the right hand type Cartesian system, which is probably are more correct system (I believe at the time of writing the wiki I used the left-hand type, which I assume you are also be using).
What I find odd though is what you eventually come up with as your final solution. It simply isn't necessary; I've experimentally verified that TargetHeading and TargetElevation are completely unaffected by cockpit orientation. I will provide video evidence of this later on. In the meantime, please check the FT guide for diagrams that explain these variables in a more visual manner. You must take the cockpit as a point in space; the orientation simply doesn't matter.
TargetHeading is a global measurement in the first place, so might as well utilize that instead. If you need a relative measurement, you can simply use deltaangle(Heading,TargetHeading).
Your math seems to overcomplicated. Dunno what's up with that, I'll send you something relevant that's easier to deal with: https://pastebin.pl/view/6b2a8c85
Incorrect. All existing systems seem to use relative coordinates. If you're talking about turret-cockpit offset, that's can very easily be compensated for via trig/parallax.
The missile knows where it is at all times. It knows this because it knows where it isn't. By subtracting where it is from where it isn't, or where it isn't from where it is (whichever is greater), it obtains a difference, or deviation. The guidance subsystem uses deviations to generate corrective commands to drive the missile from a position where it is to a position where it isn't, and arriving at a position where it wasn't, it now is. Consequently, the position where it is, is now the position that it wasn't, and it follows that the position that it was, is now the position that it isn't.
In the event that the position that it is in is not the position that it wasn't, the system has acquired a variation, the variation being the difference between where the missile is, and where it wasn't. If variation is considered to be a significant factor, it too may be corrected by the GEA. However, the missile must also know where it was.
The missile guidance computer scenario works as follows. Because a variation has modified some of the information the missile has obtained, it is not sure just where it is. However, it is sure where it isn't, within reason, and it knows where it was. It now subtracts where it should be from where it wasn't, or vice-versa, and by differentiating this from the algebraic sum of where it shouldn't be, and where it was, it is able to obtain the deviation and its variation, which is called error.
@MiG21Pilot
.
I have no idea why people are so obsessed about "horizontal stabilizers" (frankly I very much dislike that terminology- it is very inaccurate) but this is a completely independent system unaffected by other systems.
Cool, nicely done. Here's a function that detects the total # of changes in a boolean variable that might be more universally applicable:
. Change Counter Script:
sum(abs(rate(EXP)))
. This script returns the number of times a change in the variable EXP has occurred (best fit for boolean or fixed-interval change variables). For example, ammo("Cannon") can be substituted for EXP to count the number of shots fired (with some adjustment), or the variable LandingGear to count the number of times the LandingGear button was pressed.
.
It may aid in shortening code character count if you use this "change counter" instead. You could also theoretically have the first click automatically start a timer, and end the timer at a predetermined time, then divide recorded change count by said time interval to get the CPS result, which may be preferable over using smooth(). Just my $0.02.
a. Not very familiar with the engineering world
b. Not sure about how seriously to take this
Let me clarify: this is the equivalent of a 5 year old hitting up a publisher saying that his book idea about a guy flying in a cape is very nice and should be published.
@Tabris
.
There are many bright engineers in the world. They make ideas every day. A non engineering person's ideas are either nonsense or have been tested 30 million times already if it isn't a product yet. If it's not out there, it isn't feasible or better than its competitors.
There's already lots of planes that do this, go look at them- but the general idea is that you find a linear regression which you already seem to have- and set variable x as IAS and you're set. Ideally you want some clamping to prevent excess.
@Highground @MausTrap1946
.
Y'all are wrong. I don't know how the myth of SelectedWeaponName propagated, but the correct variable name is SelectedWeapon, not SelectedWeaponName. When in doubt, verify your variables with the Funky Tree Guide.
@WereOutOfNamesArentWe
.
For some reason that didn't trigger a notification, but luckily I found the post regardless.
.
As for the question in the post, to my knowledge I don't think there is an issue with overflow, ever. SP is 32-bit, there's no way you're exceeding the 32bit cap. I don't know what's meant by using beacon lights without adequate context, but beacon lights function when the input > 0, as more clearly delineated in v1.10. Perhaps that's the issue? I've worked with large numbers before, it's never actually been an issue. Pasting source code can help me troubleshoot the exact source of the error.
@vcharng
.
High velocity, as in >1000m/s? Under that should have considerable effects beyond a kilometer or so.
Ah, also modern VT systems can go down to around 30mm, so I was looking more in that sort of payload range. The rate methods also have the flaw of not considering target vector direction. Hopefully the system I'm developing, using target position interpolation, should resolve that issue. Also, apparently Hispanos did have HE rounds. Huh.
a SACLOS missile-without-using-missile-part weapon system
It's definitely impossible without a missile part. SACLOS requires that the missile have a known flight speed, but any other part aside from missiles have very wacky motion.
How effective are the current auto fuses without proper compensation? All existing system use linear rate leaders which aren't as effective, and the timing should be quite off unless the target is flying in a straight line from you. Does it work with realistic shell sizes? (i.e. <40mm)
@Notaleopard
.
All current existing cannon auto aim systems fail to adequately compensate for height differences and triangular distance offset. The one I'm developing should fix those issues; hang tight.
@Qwertyuiop88
.
Lot's of things go in and out in the development cycle. Originally actual scripting support was envisioned, but due to issues FT was implemented instead, for example.
@CHLYB
.
MP is not an official gamemode. Besides, current MP is broken beyond belief in so many ways that people who aren't devs don't understand- you'll likely never see it officially implemented, Desktop or not.
@47parzival41
.
It's gonna be difficult to explain how you should set up auto turrets then. Auto turrets primarily rely on advanced versions of kinematics with emphasis on calculus; if you don't quite understand it will be very difficult for you to set it up on your own.
@47parzival41
.
I mean, the rate leading isn't perfect, but... Do you have some understanding of how derivatives and integrals work? It's best you have some idea of what those are to use it properly.
@47parzival41
.
To point you in the right direction, the angle, in degrees, between your cockpit's location and the target's bearing can be found by deltaangle(TargetHeading, Heading).
Incorrect- a very late spotlight can cause such things.
+5I just saw your newer comment regarding Heading direction; I caught this a long time ago. Diagram from FT guide.
X and Y simply depend on the Cartesian system that you are using it's not really an issue. In my case I employ the right hand type Cartesian system, which is probably are more correct system (I believe at the time of writing the wiki I used the left-hand type, which I assume you are also be using).
What I find odd though is what you eventually come up with as your final solution. It simply isn't necessary; I've experimentally verified that TargetHeading and TargetElevation are completely unaffected by cockpit orientation. I will provide video evidence of this later on. In the meantime, please check the FT guide for diagrams that explain these variables in a more visual manner. You must take the cockpit as a point in space; the orientation simply doesn't matter.
TargetHeading is a global measurement in the first place, so might as well utilize that instead. If you need a relative measurement, you can simply use
deltaangle(Heading,TargetHeading).Your math seems to overcomplicated. Dunno what's up with that, I'll send you something relevant that's easier to deal with: https://pastebin.pl/view/6b2a8c85
Incorrect. All existing systems seem to use relative coordinates. If you're talking about turret-cockpit offset, that's can very easily be compensated for via trig/parallax.
OMG!!!!!11!!! please gib
@KnightOfRen
+1.
Do the parachutes not have a delay function inbuilt? I suppose you can use a smoothed boolean to do that then.
x = 60/7
+2The missile knows where it is at all times. It knows this because it knows where it isn't. By subtracting where it is from where it isn't, or where it isn't from where it is (whichever is greater), it obtains a difference, or deviation. The guidance subsystem uses deviations to generate corrective commands to drive the missile from a position where it is to a position where it isn't, and arriving at a position where it wasn't, it now is. Consequently, the position where it is, is now the position that it wasn't, and it follows that the position that it was, is now the position that it isn't.
+1In the event that the position that it is in is not the position that it wasn't, the system has acquired a variation, the variation being the difference between where the missile is, and where it wasn't. If variation is considered to be a significant factor, it too may be corrected by the GEA. However, the missile must also know where it was.
The missile guidance computer scenario works as follows. Because a variation has modified some of the information the missile has obtained, it is not sure just where it is. However, it is sure where it isn't, within reason, and it knows where it was. It now subtracts where it should be from where it wasn't, or vice-versa, and by differentiating this from the algebraic sum of where it shouldn't be, and where it was, it is able to obtain the deviation and its variation, which is called error.
@MiG21Pilot
.
I have no idea why people are so obsessed about "horizontal stabilizers" (frankly I very much dislike that terminology- it is very inaccurate) but this is a completely independent system unaffected by other systems.
Wikipedia
+1Other
.
People take university courses in learning how to tune PIDs. You can learn it using online resources, but it is difficult.
Cool, nicely done. Here's a function that detects the total # of changes in a boolean variable that might be more universally applicable:
.
Change Counter Script:
+2sum(abs(rate(EXP))).
This script returns the number of times a change in the variable EXP has occurred (best fit for boolean or fixed-interval change variables). For example, ammo("Cannon") can be substituted for EXP to count the number of shots fired (with some adjustment), or the variable LandingGear to count the number of times the LandingGear button was pressed.
.
It may aid in shortening code character count if you use this "change counter" instead. You could also theoretically have the first click automatically start a timer, and end the timer at a predetermined time, then divide recorded change count by said time interval to get the CPS result, which may be preferable over using
smooth(). Just my $0.02.@Numbers
.
In case you either are:
a. Not very familiar with the engineering world
b. Not sure about how seriously to take this
Let me clarify: this is the equivalent of a 5 year old hitting up a publisher saying that his book idea about a guy flying in a cape is very nice and should be published.
+5@Tabris
.
There are many bright engineers in the world. They make ideas every day. A non engineering person's ideas are either nonsense or have been tested 30 million times already if it isn't a product yet. If it's not out there, it isn't feasible or better than its competitors.
@marcox43
+1.
Correct.
I assume the FT stab- PitchAngle/cos(RollAngle) style was used?
noice
@JDog3106
.
As long as you have the math it will work out.
I agree on most points, but instruments are incredibly easy to make now... and far more customizable than mod ones.
TLDR: You need math
@officialryanyang
.
I'm currently working on the same thing and it's a more-than-complicated task. I'll get to you when I can finish work on it.
There's already lots of planes that do this, go look at them- but the general idea is that you find a linear regression which you already seem to have- and set variable x as IAS and you're set. Ideally you want some clamping to prevent excess.
@officialryanyang
.
I can help for sure! But either way I'm going to need a bit more context for exactly what help you need.
@Highground @MausTrap1946
+1.
Y'all are wrong. I don't know how the myth of
SelectedWeaponNamepropagated, but the correct variable name isSelectedWeapon, notSelectedWeaponName. When in doubt, verify your variables with the Funky Tree Guide.Funky Trees Guide
+2@Hedero
.
I probably need more context, but here goes nothing:
clamp(VTOL,-1,0) + Roll@Someterribleuser
.
Go ahead!
Literally just
+1Activate7As in the physics context?
@marcox43
.
Yes.
@vcharng
.
Odd. I regularly use numbers on the magnitude of 10^5 and above; I haven't had this issue.
@vcharng
.
Beacons light up whenever input > 0. Is that what you want happening? Not some specific indication?
@vcharng
.
Are you directly inserting this code into the
inputof beacon lights?@WereOutOfNamesArentWe
.
For some reason that didn't trigger a notification, but luckily I found the post regardless.
.
As for the question in the post, to my knowledge I don't think there is an issue with overflow, ever. SP is 32-bit, there's no way you're exceeding the 32bit cap. I don't know what's meant by using beacon lights without adequate context, but beacon lights function when the input > 0, as more clearly delineated in v1.10. Perhaps that's the issue? I've worked with large numbers before, it's never actually been an issue. Pasting source code can help me troubleshoot the exact source of the error.
Already ingame. Try harder.
+4@vcharng
.
High velocity, as in >1000m/s? Under that should have considerable effects beyond a kilometer or so.
Ah, also modern VT systems can go down to around 30mm, so I was looking more in that sort of payload range. The rate methods also have the flaw of not considering target vector direction. Hopefully the system I'm developing, using target position interpolation, should resolve that issue. Also, apparently Hispanos did have HE rounds. Huh.
It's definitely impossible without a missile part. SACLOS requires that the missile have a known flight speed, but any other part aside from missiles have very wacky motion.
How effective are the current auto fuses without proper compensation? All existing system use linear rate leaders which aren't as effective, and the timing should be quite off unless the target is flying in a straight line from you. Does it work with realistic shell sizes? (i.e. <40mm)
@Notaleopard
.
All current existing cannon auto aim systems fail to adequately compensate for height differences and triangular distance offset. The one I'm developing should fix those issues; hang tight.
@WrongFlyer
.
Those are old names for some of the airports. Forgot which they correspond to, but early SP airports where named differently.
@Qwertyuiop88
.
Lot's of things go in and out in the development cycle. Originally actual scripting support was envisioned, but due to issues FT was implemented instead, for example.
@Vladimir1944
+1.
You can already do 99% of those things you requested with some creativity and math.
@Tlloyd
.
Mobile modding is unsupported.
What is this lol
You cannot embed videos.
@CHLYB
+2.
MP is not an official gamemode. Besides, current MP is broken beyond belief in so many ways that people who aren't devs don't understand- you'll likely never see it officially implemented, Desktop or not.
@Chancey21
+1.
Heh... I reported that one. I noticed it just after 1.9... Got a chance to report it so I did, lol.
@47parzival41
.
It's gonna be difficult to explain how you should set up auto turrets then. Auto turrets primarily rely on advanced versions of kinematics with emphasis on calculus; if you don't quite understand it will be very difficult for you to set it up on your own.
@47parzival41
.
I mean, the rate leading isn't perfect, but... Do you have some understanding of how derivatives and integrals work? It's best you have some idea of what those are to use it properly.
@47parzival41
.
To point you in the right direction, the angle, in degrees, between your cockpit's location and the target's bearing can be found by
deltaangle(TargetHeading, Heading).