@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.
@Kreep2knight
.
Actually, I was horrible at programming and anything CS before FT! Wrap your head around it once and you never forget. If you really need one I can explain things to you.
Are these boolean operators? As in if I put VTOL>0.5 I will get a "1" when over 0.5 and a "-1" when under 0.5?
.
TL;DR: Yes and yes. Your logic is spot-on.
.
The comparison operators are as math works anywhere else. Specifically, the non-inclusive comparison operators- < and > - mean that if the value is equal, it is still untrue because it is non-inclusive. There's also the inclusive operators- <= and >= - which will behave the same as the non-inclusive operators but when compared values are the same, the operator will return true because it is inclusive.
.
Will it round up like with the round(x) function?
.
Comparison has nothing to do with rounding. It will behave as outlined above.
.
These are great questions, hope I helped.
@47parzival41
.
Depends completely on the context. I have special code that calculates the tank turret orientation and checks which direction the tank is moving in. If that's what's being wanted here, I definitely can help.
But fundamentally, you're going to have to use the variable AngleOfAttack in order to determine your movement direction.
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.
@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.
@ChrisPy
.
Typical projectile motion equation.
Please check around before you post such things.
@Kreep2knight
.
Actually, I was horrible at programming and anything CS before FT! Wrap your head around it once and you never forget. If you really need one I can explain things to you.
@47parzival41
.
.
TL;DR: Yes and yes. Your logic is spot-on.
.
The comparison operators are as math works anywhere else. Specifically, the non-inclusive comparison operators- < and > - mean that if the value is equal, it is still untrue because it is non-inclusive. There's also the inclusive operators- <= and >= - which will behave the same as the non-inclusive operators but when compared values are the same, the operator will return true because it is inclusive.
.
.
Comparison has nothing to do with rounding. It will behave as outlined above.
.
These are great questions, hope I helped.
@FeiWu
.
You can start with sign(AngleOfAttack) < 0. I'll get to you if you need something more sophisticated.
@47parzival41
.
Depends completely on the context. I have special code that calculates the tank turret orientation and checks which direction the tank is moving in. If that's what's being wanted here, I definitely can help.
But fundamentally, you're going to have to use the variable
AngleOfAttackin order to determine your movement direction.