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.
@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.
@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.
@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.
@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).
@1918
.
Apparently he did change your work. Slightly, but still. Creating maps still take effort, and I don't see how being under a different denomination is such an issue. Perhaps you can clarify.
Supposedly, the model has been modified to some extent- if that is indeed the case, then I think your point regarding how the mod uses the same model is invalid. I cannot verify this, however.
I 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
@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.
@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.
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.
@Hedero
.
I probably need more context, but here goes nothing:
clamp(VTOL,-1,0) + Roll@Someterribleuser
.
Go ahead!
As 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.
@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.
@Tlloyd
.
Mobile modding is unsupported.
What is this lol
You cannot embed videos.
@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).What is the bug?
@RandomDisplay
.
In what way? Could you provide some context?
Nice work with the superelevation equation. Glad to see more people figuring that one out.
@PINEAPPLZ
.
Properly scale your tires.
@Spangsege
.
Go ahead! Thanks for asking.
@1918
.
Apparently he did change your work. Slightly, but still. Creating maps still take effort, and I don't see how being under a different denomination is such an issue. Perhaps you can clarify.
Supposedly, the model has been modified to some extent- if that is indeed the case, then I think your point regarding how the mod uses the same model is invalid. I cannot verify this, however.
Something like
abs(deltaangle(TargetHeading, Heading)) < 30The weird symbols are converted from <.
Should do the job.
@Kureshik
.
Doesn't work, in what sense?
@PlaneFlightX
.
Did you replace the items I specified you should replace?
@Bombsmithfurry67
.
https://snowflake0s.github.io/funkyguide.html
@NumbersNumbersTheMan
.
Cool, I'm gonna try my hand at it. Basically gonna try and have auto-timed flak and lead. Should have superelevation too.
I mean, you have to manipulate proportions and things. It's not a magic number, it still requires math.
Superelevation or no?
Great job. One only missing superelevation.