Sorry I couldn't as much as I could. You've done plenty well on your own- this is very cool! It's technically possible to make a stabilizer for the bombsight, but this means the aperture of the bombsight will be messed up- so probably not as practical. Awesome job, great that you managed to figure it out.
As for a suggestion, how 'bout you change the color ever so slightly on the moving reticle, perhaps? That might help in accentuating it.
@FlyingHueman
.
Regarding your pistons extending beyond what they should (or going in weird directions), you can limit your piston's travel using clamp(), but that's not the main issue here. Are the directions of your vectors aligned correctly?
@FlyingHueman
.
Great, extremely happy that someone else is also trying their hand at projectile physics. Well, I've sort of understood your situation, but it would be ideal if you could supply your system with a diagram, as I did with my bombsight. This is also a fundamental practice of physics and engineering, so I strongly recommend that you do draw up, at least, a basic diagram. This will greatly assist me in assisting you. Sorry for the extra workload, but otherwise this becomes much more difficult to work out.
@RamboJutter
.
First of all, are you familiar enough with normal XML modding? I've seen plenty of builders ask for help with FT even before they know how to use basic XML. Assuming that this is the case, then I'll address your question. Funky trees only works with funky trees. None else. The V>x type of input is the archaic system from 1.7 and while it still works, it solely exists for the purpose of not to break any older builds. The two types cannot be combined. I think this is the only misunderstanding you have, the rest of your logic is spot on. Using some boolean algebra, you can figure out that to produce the same effect as V>400 with funky trees, you should use the statement clamp01(IAS - A). Replace the letter A with the equivalent of 400mph in meters per second- funky trees work with SI units only. Your idea of using + as a logic OR gate is correct, and for further reading try reading the Wikipedia page on boolean algebra, particularly the section on operators. This is the primary method through which you will have to operate the funky trees system, so I strongly suggest gaining some basic knowledge of it.
Your phrasing is sort of unreadable, but regardless what use would anyone have for an oscillating turret? The very purpose of a turret is to be controllable.
@FlyingHueman
.
Target data is uninputable with the system- but have you thought of if the operator does it himself? That is, using other inputs like Trim, you can set a range to the target and whatnot. I've got the theoretical components mostly down, but relative velocity is somewhat easy to measure using trigonometry (although, it assumes 10 billion things and is not the best method) and it would result in a somewhat accurate firing solution for at the very least a short while. It's still a work-in-progress, but I can definitely see it work once I figure out the physics- I kind of need to relearn my vector arithmetic to do this one.
@typeZERO
.
Weapons can now be named (instead of Guardian, Inferno etc). Set name = whatever you want for this one. Multirole weapons can target both air and ground targets. Set function = multirole for this.
@wonkapilot
.
Of course. My salvo cannon wasn't designed with this system in mind, and is incompatible by 'default'- but if you can follow along, then you can very easily modify it to work together. My salvo cannon build has I think two hinge rotators to elevate the gun, hidden inside the turret. Click on each of those hinge rotators, and set the angle range to 90°, then also make sure through Overload that it contains the input statement for the gunnery system (written above in the description of this build) for input. Also make sure to change the other rotator that traverses the turret, hidden under the turret of the salvo cannon, into 90° angle range as well. You don't need to mess with the XML for this one. If you have trouble following along, then I'll post a version of the salvo cannon that works with this system for you should you require it.
@FlyingHueman
.
Thanks for the kind words- and yes, that's the first thing I thought of when I realized I could make this. I already have a version of my ranging system with these new digital displays, resulting in a much cleaner and straightforward interface, but it isn't functionally different from the original, which is why I don't want to do a reupload. However, when I do end up making the full on FCS system, a digital display would be of incredible utility to the user.
@Minecraftpoweer
.
I guess so, but it would also be annoying to not be able to write it out- if anything, having both would be best. I prefer the current state over a visual programming system.
@Minecraftpoweer
.
This system is really messy though. The following is code for just one, just one of the lights in a digital display for the thousands place: (formatting broken)
The lower places (hundreds, tens, ones) get even more messy. The above is merely one light though- I have basically 7 of those for each digit-display. Works fantastically, though.
@Darjeelings183
.
I'll say 25km, because then each mil on the system will neatly become 2.5 km each. Or better yet, I'll create a digital display to do that for ya, how does that sound?
@phd614871
.
I would greatly appreciate if you could help out with this! I saw your work with the LED displays, but I'm not sure about how they worked. Mind if you help me out?
@Notaleopard
.
If you're on a mobile device, unfortunately you cannot use the mod version of DesignerSuite for blueprints because mod support is unavailable on mobile. This thumbnail alteration can only be done with PC users as of now.
I wonder if it would work if I did something like:
a-0.01 < x < a+0.01, but with * to have multiple qualifiers.
So something like this: clamp01(ceil(X - 1.99)) * clamp01(ceil(2.01 - X))
In theory, this should mean that if X is both larger than 1.99 and smaller than 2.01, the function will evaluate to 1, thus letting for a pretty precise qualifier for a value of a = 2.
@exosuit
.
Ah, I see what you mean now. Sorry for sounding stupid and pestering you with questions.
Sorry I couldn't as much as I could. You've done plenty well on your own- this is very cool! It's technically possible to make a stabilizer for the bombsight, but this means the aperture of the bombsight will be messed up- so probably not as practical. Awesome job, great that you managed to figure it out.
As for a suggestion, how 'bout you change the color ever so slightly on the moving reticle, perhaps? That might help in accentuating it.
@exosuit
.
How'd ya get the 'idler wheel' to spring back then?
@exosuit
.
Awesome. I imagine it's done with shocks?
@NFIGMT
With these: `
Place them on each side of text to make
thiseffect.Hmmm.
+3@edensk
+1.
Yep, my mistake.
Edit the
+1massScaleattribute with Overload.@PositivePlanes
.
Nope, FT is only for inputController type parts. Parachutes are activationGroup operated.
@BoganBoganTheMan
.
Needs more jpeg
@RamboJutter
.
Well, then someone else is going to whine about how to put this into an XML file.
@MrPorg137
.
While you can do it with FT, I prefer gyros for it. Mount a gyro on a two-axis free rotating platform.
@MrPorg137
.
Use a gyro for that, not FT.
@MossySasquatch
.
Use trigonometry.
@RamboJutter
.
Section 5, Practical Use, in bold. Not to be demeaning, but just because you haven't seen it doesn't mean I haven't written it.
@FlyingHueman
.
You can do that for sure, I'll try to solve it out myself and get back to you.
@MrPorg137
.
Funky trees, learn it.
@FlyingHueman
.
Regarding your pistons extending beyond what they should (or going in weird directions), you can limit your piston's travel using
clamp(), but that's not the main issue here. Are the directions of your vectors aligned correctly?@FlyingHueman
.
Great, extremely happy that someone else is also trying their hand at projectile physics. Well, I've sort of understood your situation, but it would be ideal if you could supply your system with a diagram, as I did with my bombsight. This is also a fundamental practice of physics and engineering, so I strongly recommend that you do draw up, at least, a basic diagram. This will greatly assist me in assisting you. Sorry for the extra workload, but otherwise this becomes much more difficult to work out.
@RamboJutter
.
Then again, I did emphasize the importance of syntax in this guide... Or it would be best if you were specific about what you wanted.
Gosh darn. Thick.
+2Holy mother of building. The screen is awesome.
+1@RamboJutter
.
First of all, are you familiar enough with normal XML modding? I've seen plenty of builders ask for help with FT even before they know how to use basic XML. Assuming that this is the case, then I'll address your question. Funky trees only works with funky trees. None else. The V>x type of input is the archaic system from 1.7 and while it still works, it solely exists for the purpose of not to break any older builds. The two types cannot be combined. I think this is the only misunderstanding you have, the rest of your logic is spot on. Using some boolean algebra, you can figure out that to produce the same effect as V>400 with funky trees, you should use the statement clamp01(IAS - A). Replace the letter A with the equivalent of 400mph in meters per second- funky trees work with SI units only. Your idea of using + as a logic OR gate is correct, and for further reading try reading the Wikipedia page on boolean algebra, particularly the section on operators. This is the primary method through which you will have to operate the funky trees system, so I strongly suggest gaining some basic knowledge of it.
@TheBoeingEngineer
+1.
No- the quality builds receive above 100 upvotes. It's just the oversaturated market that results in a more difficult rating.
Your phrasing is sort of unreadable, but regardless what use would anyone have for an oscillating turret? The very purpose of a turret is to be controllable.
+1Not sure if I'm not catching something, but:
Already in the game? The winch part? This was in from 1.8...
Also added in this update, 1.9? Am I the odd one out? This is under the view options button.
I'm not sure what you mean by height, but if it's altitude, it's already a Flight Data input added with 1.9...
Maybe you're a bit out of the loop.
+5@wonkapilot
.
Awesome, you figured it out! It's great to see that someone can understand my explanation.
@FlyingHueman
.
Target data is uninputable with the system- but have you thought of if the operator does it himself? That is, using other inputs like Trim, you can set a range to the target and whatnot. I've got the theoretical components mostly down, but relative velocity is somewhat easy to measure using trigonometry (although, it assumes 10 billion things and is not the best method) and it would result in a somewhat accurate firing solution for at the very least a short while. It's still a work-in-progress, but I can definitely see it work once I figure out the physics- I kind of need to relearn my vector arithmetic to do this one.
@typeZERO
.
Weapons can now be named (instead of Guardian, Inferno etc). Set name = whatever you want for this one. Multirole weapons can target both air and ground targets. Set function = multirole for this.
@wonkapilot
.
Of course. My salvo cannon wasn't designed with this system in mind, and is incompatible by 'default'- but if you can follow along, then you can very easily modify it to work together. My salvo cannon build has I think two hinge rotators to elevate the gun, hidden inside the turret. Click on each of those hinge rotators, and set the angle range to 90°, then also make sure through Overload that it contains the input statement for the gunnery system (written above in the description of this build) for input. Also make sure to change the other rotator that traverses the turret, hidden under the turret of the salvo cannon, into 90° angle range as well. You don't need to mess with the XML for this one. If you have trouble following along, then I'll post a version of the salvo cannon that works with this system for you should you require it.
@FlyingHueman
.
Thanks for the kind words- and yes, that's the first thing I thought of when I realized I could make this. I already have a version of my ranging system with these new digital displays, resulting in a much cleaner and straightforward interface, but it isn't functionally different from the original, which is why I don't want to do a reupload. However, when I do end up making the full on FCS system, a digital display would be of incredible utility to the user.
Nice reupload. Try not to do that.
+1Try not to reupload- if anything, delete the first version to reduce clutter.
+1.
Tough luck mate.
@phd614871
.
I think I understand, thanks for your help. I'll go try it out for my own!
@Sirstupid
.
XML is vanilla game.
No, even the new input system does not grant projectile tracking capability.
@Minecraftpoweer
.
I guess so, but it would also be annoying to not be able to write it out- if anything, having both would be best. I prefer the current state over a visual programming system.
@X4JB
.
Indeed, digital displays would make stuff a lot simpler.
@Minecraftpoweer
.
This system is really messy though. The following is code for just one, just one of the lights in a digital display for the thousands place: (formatting broken)
clamp01(ceil(floor(X/1000) + 0.01))clamp01(ceil(0.01 - floor(X/1000))) + clamp01(ceil(floor(X/1000) - 1.99))clamp01(ceil(2.01 - floor(X/1000))) + clamp01(ceil(floor(X/1000) - 2.99))clamp01(ceil(3.01 - floor(X/1000))) + clamp01(ceil(floor(X/1000) - 4.99))clamp01(ceil(5.01 - floor(X/1000))) + clamp01(ceil(floor(X/1000) - 4.99))clamp01(ceil(5.01 - floor(X/1000))) + clamp01(ceil(floor(X/1000) - 5.99))clamp01(ceil(6.01 - floor(X/1000))) + clamp01(ceil(floor(X/1000) - 6.99))clamp01(ceil(7.01 - floor(X/1000))) + clamp01(ceil(floor(X/1000) - 7.99))clamp01(ceil(8.01 - floor(X/1000))) + clamp01(ceil(floor(X/1000) - 8.99))*clamp01(ceil(9.01 - floor(X/1000)))
The lower places (hundreds, tens, ones) get even more messy. The above is merely one light though- I have basically 7 of those for each digit-display. Works fantastically, though.
+1@NirvashTec
+1.
Thank you Nirvash, very cool!
I've added subs- turn them on if you like those.
@Darjeelings183
.
I'll say 25km, because then each mil on the system will neatly become 2.5 km each. Or better yet, I'll create a digital display to do that for ya, how does that sound?
@spefyjerbf
+1.
I'll try that. Thanks for the help!
@spefyjerbf
.
This is what I wanted to use the exact returns for values of x. I'm having trouble with the code getting absurdly long, however.
@phd614871
.
I would greatly appreciate if you could help out with this! I saw your work with the LED displays, but I'm not sure about how they worked. Mind if you help me out?
Hey mate, I have a way different method of doing this, but I couldn't quite understand the way that this one works. Could you explain?
@Notaleopard
.
If you're on a mobile device, unfortunately you cannot use the mod version of DesignerSuite for blueprints because mod support is unavailable on mobile. This thumbnail alteration can only be done with PC users as of now.
@Notaleopard
.
DesignerSuite Blueprints. Plenty of guides on the subject already, use the search bar.
I wonder if it would work if I did something like:
a-0.01 < x < a+0.01, but with * to have multiple qualifiers.
So something like this:
clamp01(ceil(X - 1.99)) * clamp01(ceil(2.01 - X))In theory, this should mean that if X is both larger than 1.99 and smaller than 2.01, the function will evaluate to 1, thus letting for a pretty precise qualifier for a value of a = 2.