@spefyjerbf
Ah, if that's the case I guess it works. I've been playing around with the speed data types a bit recently because I was trying to get the best measurement type for my bombsight, but I just found IAS works best for most purposes... Or so I believe. Excellent graphics, by the way. Always found that you make super appealing images- did you study graphics design at some point?
Very nice, although I'm not sure if GS is the right speed value to use for the last one. In my tests, I found the GS doesn't seem to work as intended- a 90 degree climb should show GS = 0, but apparently not... Something to note.
@LightBender
.
No, the bombsight automatically calculates everything about the possible trajectory of the bomb. Check if you've installed the bombsight correctly, and try not to fly at extreme angles- it works best in level flight.
@exosuit
.
If you mean the two reticles in image included in the post, they are both standard reticles, only that one is used for higher altitude bombing. All weather just means that this reticle is light-up: you'll be able to use this just fine even at night.
@Zanedavid
.
Yep, the errors only start making some difference when at 5000m+ altitude, but generally for a bombing run of more than 1 bomb you should be able to hit targets easy.
@Zanedavid
.
At 1000m this is very accurate. Expect an effective deviation of roughly maybe 10-25 m. If you look at a target at 1000m, you will probably hit that target. The bombsight automatically calculates the bombing solution according to your altitude, your speed, and the orientation of your plane. Every factor that can be accounted for has been integrated into the system.
@FlyingHueman
.
While I originally did not actually base it off the Norden, after I did the math I realized I needed a two-plane stabilizer. Then while I was doing some research, I realized this was basically a Norden! Pretty cool, huh...
@Minecraftpoweer
.
Ah, so you're stating an issue with maximum possible elevation and depression. That's easily solved. We can just make the input of the elevation rotator something like (Trim - PitchAngle*a), where a is some constant you find yourself (depends on your build). Then you can make sure that the max elevation is [Stabilizer-induced elevation] + [User-controlled elevation - Stabilizer-induced elevation]. Does this make sense to you?
only worked if the gun was facing the same way as the cockpit (could be fixed if the cockpit was on the turret)
True, and this is indeed limiting in some ways. However regarding this-
the max is 20 on the stabilizer and on the elevator rotator and if you're going down a hill it could still go up to 40
I'm not exactly sure why you had that issue. If you want to limit your stabilizer's range, just change the min/max on the clamp function. Not hard at all. Instead of the original- clamp(PitchAngle*0.01, -1, 1), you can just do clamp(PitchAngle*0.01, -0.5, 0.5) to limit the max dep/elev to 45º on a 90º range rotator.
.
For gun elevation, just add a hinge rotator. Nothing too hard there.
Completely possible. Pretty easy, actually- if you use my stabilizer mechanism- a rotator with an input of clamp(PitchAngle*0.01, -1, 1), and set zeroOnDeactivate = false, then every requirement here is met.
@DeezDucks
.
I haven't considered it too much- I believe TAS might be more accurate, if I can manage the time today I'll go and test it to see which performs better.
@ChisP
.
If you've read my work at all, you'll understand that
This calculates the ballistic trajectory of a "dropped" projectile
The system assumes a free-fall trajectory- no deviation.
This system is not for guiding bombs, but for estimating where the bomb will hit. Although, I am fairly sure you'll be able to make guided bombs if you really try.
@Kirby144p
.
Here's a slightly more elegant solution- this doesn't need any other modifications except for the actual input (no need to deal with damperMultiplier):
clamp(PitchAngle*0.01, -1, 1)
all you need is a rotator with 90º range (the default). No other modifications needed. Although, this also requires that you add a separate part to elevate your gun- though when modifying older builds to have a stabilizer, my solution will likely be easier to use, and the same can be done to add a horizontal stabilizer:
clamp(RollAngle*0.01, -1, 1)
Both in tandem create an effective two-plane stabilizer.
@WNP78
.
A question- how many digits can the input system process? To me it looks like the system can't calculate numbers that are more than four digits, such as 1000, or 0.001.
Also, how long of an input can the system handle?
@RASEN1914
+1.
I've already done one. Check it out here.
@DerekSP
.
Troubleshooting for Funky Trees:
1. Syntax (spacing)
2. Check for invalid variables
For your specific case, you can set activationGroup to
- Activate1to achieve the function you want.Yep, I already demonstrated it in one of my posts. Oski is correct, you can do it already- you just have to do it yourself.
@spefyjerbf
+1.
Much thanks for the kind words, added to my contacts. Will contact ya when I need help.
@typeZERO
+1.
Answers (respectively):
Yes, infinity (attribute in XML)
Not yet
Untested
No
Yes
@Galaxy34
+1.
Of course. Have you ever seen a modless build not work on other devices? With the new update, this will now work for everyone.
@spefyjerbf
+1.
Thanks, I often feel my stuff is slightly unpolished- been taking some inspiration from you as well!
@spefyjerbf
+1Ah, if that's the case I guess it works. I've been playing around with the speed data types a bit recently because I was trying to get the best measurement type for my bombsight, but I just found IAS works best for most purposes... Or so I believe. Excellent graphics, by the way. Always found that you make super appealing images- did you study graphics design at some point?
Very nice, although I'm not sure if GS is the right speed value to use for the last one. In my tests, I found the GS doesn't seem to work as intended- a 90 degree climb should show GS = 0, but apparently not... Something to note.
+1@Tankace1
.
XML. The guns haven't changed.
@ChisP
.
What issue did you have with the muzzle velocity? Was the range too far (probably the case, as shells have no drag)?
@MattEpic
+2.
Definitely possible now.
@Mattangi2
.
Certainly!
Radiator cowls are already modifiable, I believe. I'm not exactly sure how RPM would be modeled though, it isn't really a thing is SP yet.
@LightBender
.
No, the bombsight automatically calculates everything about the possible trajectory of the bomb. Check if you've installed the bombsight correctly, and try not to fly at extreme angles- it works best in level flight.
@Zanedavid
.
You can turn it off in your quality settings. ESC menu > Quality Settings > Predictor off
@Fartspoppop
.
Use your brain, eyes, and something called searching on the Internet. Not to be condescending, but honestly you aren't trying at all.
@exosuit
.
If you mean the two reticles in image included in the post, they are both standard reticles, only that one is used for higher altitude bombing. All weather just means that this reticle is light-up: you'll be able to use this just fine even at night.
@Zanedavid
.
Yep, the errors only start making some difference when at 5000m+ altitude, but generally for a bombing run of more than 1 bomb you should be able to hit targets easy.
@11qazxc
+1.
Yup- check out my take on it here. It works pretty well!
@EliteArsenals24
.
Thanks! The new input systems are pretty cool, I get to do this sort of stuff.
@KerlonceauxIndustries
.
I'm working on the theory behind it, I think I can get a rudimentary FCS up soon.
@Kimcotupan15
+1.
Thanks! It's nothing beyond a HS Physics course, but it's still very cool to know that this can work in SP now.
Don't use mods. #1 rule when building.
+2Very cool! I'm assuming you're using something with a sinusoidal function and time?
@Zanedavid
+1.
At 1000m this is very accurate. Expect an effective deviation of roughly maybe 10-25 m. If you look at a target at 1000m, you will probably hit that target. The bombsight automatically calculates the bombing solution according to your altitude, your speed, and the orientation of your plane. Every factor that can be accounted for has been integrated into the system.
@FlyingHueman
.
While I originally did not actually base it off the Norden, after I did the math I realized I needed a two-plane stabilizer. Then while I was doing some research, I realized this was basically a Norden! Pretty cool, huh...
@LeonardoEngineering
+1.
A marvel of engineering indeed!
@CrashFighter05
.
Haha, thanks for the spotlight!
@Kirby144p
.
See this discussion thread here. I've addressed a lot of your concerns.
Pings!
+1.
@Leehopard @randomusername @Thelegitpilot13
Pings!
.
@Alienbeef0421 @exosuit @WarHawk95
Pings!
.
@Kirby144p @ChisP @DeezDucks
Pings!
.
@Minecraftpoweer @EliteArsenals24 @Oski
@Minecraftpoweer
.
Ah, so you're stating an issue with maximum possible elevation and depression. That's easily solved. We can just make the input of the elevation rotator something like
(Trim - PitchAngle*a), whereais some constant you find yourself (depends on your build). Then you can make sure that the max elevation is [Stabilizer-induced elevation] + [User-controlled elevation - Stabilizer-induced elevation]. Does this make sense to you?@Minecraftpoweer
.
True, and this is indeed limiting in some ways. However regarding this-
I'm not exactly sure why you had that issue. If you want to limit your stabilizer's range, just change the min/max on the clamp function. Not hard at all. Instead of the original-
clamp(PitchAngle*0.01, -1, 1), you can just doclamp(PitchAngle*0.01, -0.5, 0.5)to limit the max dep/elev to 45º on a 90º range rotator..
For gun elevation, just add a hinge rotator. Nothing too hard there.
@Minecraftpoweer
.
Seems unnecessary to me. You wouldn't need much else than that for a good stabilizer though?
@Imashovel
+2.
Weapons Guidance is realistically impossible with mere inputs... At least with what we have now.
@Dllama4 @Minecraftpoweer
Completely possible. Pretty easy, actually- if you use my stabilizer mechanism- a rotator with an input of
+1clamp(PitchAngle*0.01, -1, 1), and set zeroOnDeactivate = false, then every requirement here is met.@DeezDucks
.
I haven't considered it too much- I believe TAS might be more accurate, if I can manage the time today I'll go and test it to see which performs better.
@DeezDucks
.
Applaud my supreme power!
@ChisP
.
If you've read my work at all, you'll understand that
This system is not for guiding bombs, but for estimating where the bomb will hit. Although, I am fairly sure you'll be able to make guided bombs if you really try.
+2@Natedog120705
.
In a way.
@Natedog120705
.
Check here, here, and this devblog post.
@Kirby144p
.
Here's a slightly more elegant solution- this doesn't need any other modifications except for the actual input (no need to deal with damperMultiplier):
clamp(PitchAngle*0.01, -1, 1)all you need is a rotator with 90º range (the default). No other modifications needed. Although, this also requires that you add a separate part to elevate your gun- though when modifying older builds to have a stabilizer, my solution will likely be easier to use, and the same can be done to add a horizontal stabilizer:
+3clamp(RollAngle*0.01, -1, 1)Both in tandem create an effective two-plane stabilizer.
Cool! Definitely. Although, one could argue those would go under 'Parts'.
+2@Thelegitpilot13
+1.
Sure, I'll release the input statement code once I release it as a build!
@Minecraftpoweer
+1.
Gah, it's nothing beyond a basic HS physics course. The hard part was typing everything right and not forgetting things.
@toxicgamer88
Here's the link to my work. I've tested it and I think it works, but please check!
@WNP78
.
A question- how many digits can the input system process? To me it looks like the system can't calculate numbers that are more than four digits, such as 1000, or 0.001.
Also, how long of an input can the system handle?