NNnnooooo LMAO
I just made one of these, too! :P
Of course, yours is legitimately way more involved than mine, since you went full custom and I just strapped 2 prop-hubs to a JE90 (I think).
.
Then again, we might've went for slightly different systems? Mine's the Ultra-High Bypass Fan variant which doesn't have (as far as I know) adjustable blade pitch and so I set my props to have a high fixed pitch.
Either way, you'll see it here in a few minutes after I upload my "Alternate Reality" plane I equipped with mine... :} EDIT: Oh, nice, I'm your first updoot! High five... o/⁺\o
I wonder if someone could make a 3D Plotter using Winches, connected to powered Resizable Wheel trollies which are mounted on a giant Fuselage box. Then have the Winch cables connected to a comparatively muuuch smaller box in the middle, which houses various different guns, configured that way, but with their own Tracer colors, each set to an Action Group to be toggled as needed.
.
Then, through control inputs like Pitch and Roll, control the winches, thereby moving the plotter around on a huge X/Y grid. As you move, to a new point, you fire a shot with whatever color you've configured, and.... now you're drawing pixel art! :P
.
May need to set the bullets to zero velocity, so they stay where they are shot from, and make this entire contraption (the frame) able to move, so that once you're done drawing, you can relocate the plotter and see what you've made.... :} [/batcrapcrazy-idea]
@Sadboye12 "setting it to -100 transparency will make the glass glow"
Brilliant... I don't know enough about the finer details (ie: value limits) relating to XML modding. Clearly I just need to go back to my roots: Trial and Error, throwing caution to the wind! :P
.
Huge thanks for sharing that secret! I would probably never have figure it out to set it to a negative value haha [Also, as someone who is also a "Sadboye", I suggest not giving it any more control over you than it already has, or any more recognition through means like making it your username... Nay, instead I think you should try to spite it, say by changing it to something like Gladboye12! Of course.... that's all predicated on it not being your actual name... lol :}
Which, if it is then, uh... ignore this and hey-look-there's-a-squirrel!
_*smoke-bomb*_]
The nose is interesting heh
On the schematic shots the website provides, the cross between a Predator drone and an SR-71, your nose looks like how I'd envision that mashup to appear like :P
.
I dig the entire design though, nice job!
I wish I knew more to contribute. However, currently, there are most definitely lots of missing stuff, such as that the bombs/missiles/rockets can have their explosive power changed. Cannons have various bullet types, and also can themselves be set to explosive or not.
.
Though I was coming here, hoping to find some info on Action Groups, so I could assign a weapon to be Air-to-Air only (thereby not showing up in the Air-to-Ground hud...)
Oh well heh
I still can't upvote, so... Thanks for having originally made the guide!
Request: An option to configure a "Purge" time, which deletes backups that are older than the defined amount of time. Said-time would be on a scale of Days, although if it supported w or m after the number in order to define "Week(s)" or "Month(s)", that'd be nice, too; default being in days (if no letter modifier added).
.
I just looked at my folder and realized it's at 283MB lol
It may not need to be an actively monitored thing, either, to keep down overhead, but perhaps simply a run-time check.
@Technodium
lol Glad you liked it (and found it!)
.
Though I don't know what he's screaming about, as we're only pulling 15Gs during extreme loop-de-loops! (which I don't have G included as a readout but maybe should? heh). Plus, when squeezing through the bridge structure near Yaeger or the opening in the Pyramid, I've only crashed two or three times... I mean, come on, right?! :}
</s> haha
@LieutenantSOT Thanks for the info :)
Hmm, IAS sort of is, but if that were true -- and honestly, it might be, but my ignorance is getting in the way, so I won't pretend it can't be an option lol -- then everything I thought I had understood about airspeeds was WAY way off! O_O
Which, again, is indeed possible. As only recently did I discover that Ground Speed is not a measure of your horizontal speed across the ground, where changing your AoA would impact your reported GS. Or to put it another way, I thought GS was more or less calculated by the amount of distance you traveled horizontally in a given time. (Thus why I thought if you, say in a hypothetical scenario, where you had >1:1 T:WR and were pitched up at say 30deg, your GS would drop due to not covering the same distance as quickly from now going upwards too, even though your plane maintained the same velocity)
.
But if you read the quote at the beginning of my comment down below, that definition for True Air Speed really does match what I was expecting OURTAS ,in game, to be reporting to us. Obviously leading to this surprise that the calculated Mach results were off, and that error rate only grew as Altitude increased.
.
In the end, though I hope not, it may indeed be a case where an elaborate script (FT equation) is going to be needed in order to factor in air density in the same way that NASA tool does..... If only I understood coding better, and wasn't absolute-trash at math, that might not be so hard! hahaha
On the plus side, I have an ulterior motive to figure that out, too, as it would (I think at least) provide the basis for allowing me to add another 'feature' to a plane I really wanted to.... So fingers crossed I can figure something out! (I'm not hopeful I'll be able to though, as my ""AG Toggled, Multi-Readout, Configurable Measurement System Air Speed Gauge"" [lol what a name] that uses FT, isn't working how it should. *sobs*)
@EnzoDiazUnofficial I completely 100% agree. I'm actually surprised that the base language characters weren't supported, given we do have players from around the globe. (Though admittedly, CJK subset alone has almost 21,000 characters*gulp*)
.
Now... That is not an excuse, or even a claim that it's "too many", because Minecraft supports all of those any many more, which at one point was also using an character-image system. I spent lots of time for my server, coming up with cool and beautiful user tags with the various exotic languages it supported. (The African Languages characters [font "Ebrima"] holds a special significance for me as I portrayed the Greek primordial "Khaos" on my server, and fashioned a name out of characters from those languages: ꗣⶋꗇⵙꗟ )
,
But, I digress :P
It'd indeed be great for those to also be given support. I think I have an idea perhaps on why they are be causing performance loss in SP, but I'm out of my element in that regard to know for certain...
Either way, I think it might be due to the placement in the rendering chain, and maybe moving it up higher so that it doesn't have Post-Processing applied, could help? The fact they cast shadows seems to mean they are having extra processing applied to them, but whether the extra processing is necessary for them to look right, is the unknown for me...
@11qazxc
Alright... How about this...?
Helpful?
Or too complicated? (I didn't really type the post to need a pic, but instead have all the needed instructions to copy-paste their code and replicate it in game. So trying to make what's shown also make sense, was tough.)
@KingHandspider I'm working on getting it formatted and added to Snowflakeos' Funky Trees Guide, where it'll have its own Labels section!
All of the above will be included, and eventually someone with knowledge about FT coding will add the further capabilities that can be done with Labels with FT code :)
Something I'd find super handy for Guns/Cannons, would be a simple "delay" in their projectiles being activated (able to "interact" with builds; can remain ground interactable for all I care).
That way we can hide guns inside the fuselage, or have a Gun Turret on a bomber, and NOT HAVE TO WORRY WE'LL SHOOT OURSELVES... -_-
Or if Jundroo doesn't want to deal with delays...
Could be a variable that uses the "Connected Parts" system to define what constitutes "Ourself" in the game's eyes. A possible variable, albeit a poor example, could be: weaponCollisionSelf with default being True (how it is now) or False where it's like having disableCollisionDamage to False. (I don't know whether it'd be better to have this on a single part, like the Cockpits or Flight Computer, so that it doesn't have to be toggled on EVERYTHING? Or if it should be specific to weapons and can be decided on a per-weapon basis, which ones need to process this?)
.
So in this case, a cannon, machinegun, gatling gun projectiles, or any of the rockets and missiles, when fired they would know NOT to collide with their Parent, Grandparent, etc parts.
However, since all other spawned objects would not be connected to our build, that all those aforementioned projectiles would be able to still collide with them, doing what they were intended to do.
.
In other words, it gives us the benefit of disableCollisionDamage true or defaultCollisionResponse None where we don't blow ourselves up, but avoids the issue of those projectiles being unable to collide with anything else that is spawned in. (other planes, ships, land vehicles, or players in Multiplayer matches)
@MintLynx That's what I (try to) do, it's just, sometimes you get in the zone, ya know? :( heh
.
I call it "Builder's Vision" for sandbox games like this. Happened to plenty of us, back when I ran a Minecraft server, and we'd be constructing new areas for the players, but would totally forget to monitor the kiddos in chat... :} (The aqua-blue admin chat thankfully became a visual trigger, most of the time, as even then I'd be too zoned in to notice it! lol)
Admittedly, this become longer than originally intended, so... I slapped a TL;DR to the top that delivers the meat and taters' of it.
@meteorbook345 Just out of curiosity...
By "sound" are you meaning like audible sounds?
Or
Sound as in "accurate" or "plausible"; ie making more true-to-life builds?
@BeastHunter You upvote a lot of my threads, but you might've missed the on on Label Resource. In it, I linked to this person's 1-part HUD, and you might be able to reverse-engineer it to be better suited to a wheeled-vehicle :D (ie no need for all those Attitude lines)
@Kangy *grumbles* lol
To really do it proper justice that'd need a lot of images, and, ideally they'd have to be also GIF to show the transition from original to modified. And while a few static images would be doable, I don't have the monthly bandwidth to tackle uploading a bunch of GIFs :( (Blame corporate America's crappy rural internet infrastructure)
.
That's why I opted to provide the two pieces of code in each example.
As with that, all you have to do is select the piece of Fuselage you've just placed out of the Parts Menu, open up Overload, select Fuselage from the drop-down menu, and add the lines.
.
If adding new entries is new to you, that's Ok! It's easy:
1] At the bottom of Overload is a subtle darker-gray box with a + in it. Clicking that adds a new line.
2] Click on it twice (2x), to make two new empty lines
3] In the first new line's "Name" box, paste or type in fillFront, and in the "Value" box type or paste any of the number sequences I provided in an Example above. ie 1,1,0.25,1
4] In the second new line, put in fillBack and the second number sequence from that same Example. ie 1,1,-5,1
5] Click on Checkmark in Overload (bottom-right) to accept the changes, and you'll see the Fuselage immediately change.
.
But yea, I just figured it was easier to appreciate the changes first hand, by being able to first play with the Fill sliders through the Parts Setting menu in real time to see the limits of the default 0-to-1 (0% to 100%)... Then be able to contrast it against what I've shown. I didn't think that pics would've actually illustrated what it's doing compared to what was possible via the menu.
Alas, I'm still happy to oblige, so I'll add some basic pics for each example, in case that's all anyone really wanted; give me a bit.
@Bobyo NY... Yep, weird indeed for a 'nado!
Oh and that reminded me of ANOTHER contrast between MN and TN... You mentioned basements, and that was common in MN, but for whatever reason they don't have them in TN. At least not in the same way. Down here, when they do have them, they're walk-out basements where the basement is built into a hill, but one wall is fully exposed with windows and a door.
.
With how much different a basement's temperature can be, you'd think that in the south where it's warmer, they'd want to leverage that cooler underground aspect... but... nope... lol *shrug*
@Wibbley Ah yes, Russia, you certainly have a good relationship and understanding of Winter, then, just as I do.
One could even say that growing up where we have, Winter is like a third parent! -- and depending on where Bobyo lives in NY, for him as well! As a parent does, Winter also teaches us what to, or not to do, and the (literally) cold, harsh lessons it presents us each year by living with it for those 4 to 6 months. :D\
.
.... Hmm ok, maybe less like a parent and more like a dysfunctional and mentally unstable Uncle, who bounces between living with family members for various periods of time... lol (thankfully, I am not speaking from experience, but that just feels rather accurate; I imagine it'd be fun having them around for some days, but other days, wishing they would go away... like how it can be with winter!)
@BeastHunter The beauty of the game, at least with shared builds (in case you lose the local save), is we can easily go back and modify stuff to improve it as our knowledge grows. (Or in this case, as new updates add new parts and capabilities!)
@CrimsonOnigiri Exactly. The Wings can do this sort of already, so it's not a stretch (pardon the pun) to have similar capability on basic Fuselage ends.
.
This would also let us slim down a single corner of a Fuselage part. Similar to what Slice does, but at a / instead of the + that Slice currently does.
.
Although, my new Slice discovery I just posted a new thread about could aid with this a little bit, but it wouldn't be nearly as user-friendly as just letting us move the corners visually.
@ZeroWithSlashedO @IceCraftGaming Aah ok, so it's just the "Firing Delay" on Rockets, but for the Missiles. Strange that it wasn't in the menu, like it is with Rockets. (Then again, the decision for a LOT of things not being in the menu I've found to be strange, so this is par for the course... lol)
.
If I ever decide to make a successor Derpship rocket build, that may come in handy. Though even in my original, I just used the Detatcher to handle all of the timing and staging (ie ignition of the rockets).
.
liftScale will be fun, though, and just so happens I threw together a Blended Wing design these last few days which I'm thinking are going to benefit from this, given it's reluctance to stay aloft under 250MPH lol
,
Anywho, thanks for the explanations!
I very much enjoy this sort of What-If with aircraft :) Not only "backwards", propelling modern with props, but also with modernizing the old with more modern parts!
.
Back almost two decades ago when I learned about "Turbo Props", my immediate thought was "How cool would it be to shoehorn one of them into something like a P-51?!". Wouldn't be until much later that I'd learn people have done such things :D
.
.
@F104Deathtrap Makes me wonder what the top speed potential is on Ultra-High Bypass Fans.
On that note: SHAMELESS PLUG TIME lol
Here's my Alternate Reality ""SR-71"" with said Ultra-High Bypass Fans
Also a 1917 de Bruyere. "C.1" that I ran with his design and updated into what I dubbed the "xC.2".
(I have a much larger "C.3" in the works too, but the recent update sidetracked me... considerably... haha)
@Prince1747 Cross your fingers and *hope @BigBushy updates it for SP v1.11 (that came out a couple weeks ago), as it apparently broke any mod that added parts, like this one. :\
Ran out of message space lmao C'est la vie....
.
Was going to end with this:
(Note: there are lots of vanilla actions you can perform which will not trigger the auto-save/creation of an undo point, but using Nudge is the quickest way to initiate it. I either nudge, or just clone a part to a random empty area, and delete it. Still, not fool proof.)
Also, @exosuit thankfully you only need to use the "period" trick in these comments. Forum posts and Shared builds allow you to use conventional line-breaks with the Return key. Though I suspect maybe this had been a comment that you decided to transform into a dedicated post, and thus had Cut-and-Pasted it here. :P
I'm the same. I prefer the Fine Tuner mod over the in-built variant; however, after I only recently found out the in-built version lets you "Nudge Selected+Connected", that's pretty handy...... when it works....... It's hard to know what Grand-Parent", "Parent", and "Child" parts are, and which one you need to have selected in order for all the other ones to nudge with it. As a result, I often end up having to REMOVE connections from the main build in order to make it so whatever I have selected will move everything no matter which is the actual parent. (Unless there's a "next connected part" cycler hotkey I don't know about that works similar to going "Forward" or "Backwards" along fuselage pieces...)
I mean it saves a lot of time from having to manually select every part of a section, but that's only when it works as you want/need! lol
.
I've never used the DesignerSuite connection editor though, but it sounds like I really ought to give it a go...
.
As mentioned, the Scale feature on Fine Tuner is one of the reasons I can't drop using the mod. The other is "Multi-Select". That is just too powerful to do without, and I simply don't understand why either of those didn't make it in.
Another big reason that keeps me using it, is the much better and smaller interface. The vanilla menu is way too big, and without the ability to... well lol "Fine Tune" the UI to suit our own personal desires and screen size, it ends up being too scrolly for me.
. HOWEVER I do still use the vanilla Nudge! In actuality, I love that I have TWO nudges now. I leave vanilla set to 0.01, and then Fine Tuner mod set to 0.001 for defaults. :P Now if only using vanilla Rotate-by-90 didn't randomly Auto-Connect nearby parts, I'd be able to use that more, too!
.
But yea, I made a similar post, albeit about things to add into the mods, to skip the red-tape of adding it right into the game. Similar community support, but didn't gain any traction with WNP (and HellFire didn't chime in). :(
.
The biggest UGH of all, is that not even the "Now Vanilla" features apply their actions to the Undo History... -_-
Change a connection point, only to have it removed at a later Undo.
Adjust a part's rotation, only to have it reverted at a later Undo.
Make a bunch of changes to a Text Label... (or Input; anything that uses the underlying TextMesh Pro Unity plugin)
I'm sure adding/changing Variables result in their changes being deleted as well, if you happen to Undo later.
Well most devices support 10-Point Touch, as of probably the last 5 years or more. So there's no reason they couldn't add a whole bunch of other features like that for mobile.
ie Assign it to 4-touch, where you could use the Thumb of your off-hand as Input#1, then a 3-finger touch on the primary hand to do the rest.
Although, since I suspect you would need to do all of that within a very quick span of time for it to register as 4-fingers... maybe just a simple button in the corner on mobile, that when it's held-down it toggles "Alt" functions for 1, 2, 3 finger touching. Akin to what Shift and Ctrl do on PC.
@CC1010 If you ever feel like making something, and uploading it as an Unlisted "rough draft" that is in need of tedious fine-tuning of part locations... Feel free to ping me. I'd actually considered making a post to offer that, as I for some reason enjoy that sort of thing. (I often end up doing it on builds I've downloaded anyhow, but don't feel right uploading them often times...)
Indeed, all engines definitely need to have the same volume XML option that the Cannon does!
Engines can get insanely loud in Contra-Rotating builds :( Particularly the Turbo Props...
I had been contemplating making this suggestion for awhile myself! :)
@rfostoria I totally agree!
.
That being said: there currently is a way... though sadly it's not the best solution, but you can edit the scale in XML to make it shorter. However, you also need to change its Length value by the same amount, otherwise it will be an oval shaped wheel <_> lol
The downside to this, is the wheel's physical size gets smaller, hence why it's "not the best solution". Still, a solution.
.
Alternatively, making your own by 'hand' with a Rotator. Fuselage, and Resizable Wheel would be a roughly *thinks....* 5-part solution. 6, if you want a 'fancy wheel cover' lol
Yea, I have a slight issue with being unable to type short posts... lmao Sorry :(
I also now realize that I may have misunderstood you originally... :}
I was under the impression that the "issue" you were presenting was solely that it vanishes during IDLE.
However, I now think I understand what you're saying, in that compared to other prop engines, when they change from the modeled-to-2D visual, their 2D "blurred propeller" texture is MUCH darker (has more contrast) compared to what your Demonstrator/Video show off. Yes?
If interested, since I was getting so many Overspeeding situations when throttling down, I was curious if the reported RPM in the Warning Text was accurate, so I went about adding an RPM gauge (Tachometer) to watch.
.
2 things of note:
1) was that setting up the gauge, using the input code provided by the gauge that the Twin Prop plane uses, was a pain in the butt! Foremost, because after having already presumably "fixed" the gauge in that plane, I've come to find out I have actually NOT. Long story short, I went into this using abs(Rpm1/1200) with the Gauge's "Input Multiplier" set at 70. (and "Zero" indication at 110)
After roughly 45minutes I've narrowed down the CORRECT code, at least for the Turbo Prop engine: Rpm1/28, with -no- "Input Multiplier". (and "zero" set at 108, but that might be[?] irrelevant)
I reach that by first having DebugExpression Rpm1 displayed, and then by watching that as I increased the engine's throttle to make it sweep around the dial (quite hard with this setup!). All the numbers now matched up correctly based on the typical """x1000""" values used in Tachs... Which despite this Turbo Prop never really exceeding 1000RPM in normal operation, is actually required to be x1000 because...
.
2) The on-screen Overspeed Warning does not show the Max RPM the blades are hitting. It's also not the "Shaft" speed, either, because... well first off, it doesn't look to be a gearbox equipped Turbo Prop so I figured must be 1:1 Shaft:Prop (I could be wrong, if torque converters can have differential outputs?). Secondly, because the Debug readout DOES match with the Overspeeed Warning text; however, the text will eventually 'settle' on a reported RPM, and yet the Prop's RPMs are still increasing!
.
In my configuration, using "Almost-blurring" code, and a slightly tweaked Propeller Pitch code, the Warning displays an RPM settling at ~2950RPM... whereas the Debug (and my Gauge) reach a PEAK of 3550RPM!
Thankfully, the "blow-your-engine-up" Overspeed RPM seems to be around 5000RPM... So even with that disparity in what the Warning shows, it's quite a ways off from blowing up. Alas, that's in the ground-test rig at sea-level, so thinner high altitude air might cause all sorts of different results!
. [Hurray for long posts... Continues below]
Want to make an Tachometer for your plane? Use this for the Gauge's Input: Rpm1/28 and replace 1 with the engine's RPM you want to read -- which is trial and error unfortunately, but seems to base it on Engines furthest forward (higher Z coordinate) come first, and then those along the same X-axis are from Left to Right. At least in my one case I'm basing this on. I had 4 props, 2 front-center (contra), 2 on wing.
Front-front was Rpm1, Front-back was Rpm2, Left Wing was Rpm3, and Right Wing was Rpm4. EVEN THOUGH the two Wing engines were there first, which meant some troubleshooting later, when that engine's gauge was reading 0 despite rotating.
(Also lastly, the engine being off doesn't matter, if your plane is moving and prop is spinning, it generates an RPM because it's not the engine's speed *sigh*)
@OtakuNekoToT No no, I get that it's due to how your FT code is. My point was that the way it's setup is:
1) applying too much throttle at Idle, which means...
2) the engine produces too much power, which...
3) causes the blades to spin too fast (ie RPM) because...
4) at Neutral Pitch there is not enough drag to slow the blades down
.
I totally get that it's all setup with the Neutral Pitch to act correctly, in that at idle it won't move the plane. I only included that in my original explanation in order to point out the chain of events that lead to the issue you're experiencing.
.
That being said, the solution is to lower the RPM (via Throttle applied at idle). The question is, how slow or fast are you wanting it to spin?
JUST slow enough not to blur?
or
Quite a bit slower?
Here's what I managed to work out for ya either way (this code is [obviously] only for engine's Throttle, not Pitch, since we don't want to touch that any): Almost-burring
(smooth(Engine2*0.01,0.1)+(smooth(Engine2*0.01,0.1)?Throttle:0)*0.99 Medium-speed
(smooth(Engine2*0.007,0.1)+(smooth(Engine2*0.007,0.1)?Throttle:0)*0.993 Windmill-speed (ie slow rotation)
(smooth(Engine2*0.002,0.1)+(smooth(Engine2*0.002,0.1)?Throttle:0)*0.998
NOTE:
You might want to add a smooth to that final "ELSE" output, because in my testing, quickly throttling down (or using Brake, which instantly throttles to 0%) can cause the Blade Pitch to flatten out too much and produce an Over-rev warning. (3648RPM, 2x the "safe" limit)
I don't know if that'll cause a similar situation when in flight, but thought it at least merited mentioning.
@CenturyAerospace True, yes, that too. I just figured that the models would've inherently blurred on our screens by spinning faster. So the end result would've (presumably) been the same, and as a result I figured they swapped it out with a 2D blurring image just to save CPU & GPU cycles. (Same reason we use 1 part when we can, instead of 6, as less total part count means it can run better for lower-end systems/mobile.)
.
Grant I only have limited knowledge in rendering, being only a gamer and not a dev of any kind :} Thus, I could easily be wrong, which is ok! heh
@FairFireFlight
lol *dja-djan-djun* big trucc *dja-djan-djun* BIG TRUCC *dja-djan-djun* big trucc *dja-djan-djun* BIG TRUCC!!!
.
(Although I do suggest listening to the entire song, too lol And for anyone interested, while that band is no more, some members [lead singer for sure] did form back up to become Devil Driver, whose first album at least was great and worth checking out... subsequent ones, eeeh...)
@AeroAeroTheMen You can make your "proximity" currently, assuming you're referring to them not exploding on contact with water. Someone made that already, though unfortunately I don't have the link :\
.
I kinda-sorta made a remotely-detonated nuke... although it's a flying nuke, that you pilot remotely (with the new Flight Computer, I can officially make it a drone in that sense). The triggering mechanism was a Cannon that I scaled to being pancake size, placed at the bomb's nose. You just armed its AG, set it to either Air-to-Air or Air-to-Ground, and fired it when you wanted it to explode. (Which, coincidentally, is almost exactly how a nuke goes nuclear! Just not man-triggered, like mine)
.
I think you'd want to use the AltitudeAgl in whatever it is you make that triggers the bomb, since that's the FunkyTrees code for "Above ground level". Setting it to AltitudeAgl = 1 then would make it detonate at exactly 1 meter(?) above ground-level; or if over water, at exactly that height above sea-level. :) And I believe with the new Variables system, you could even set it up to fire the cannon attached to it (though I can't say that with certainty). Otherwise perhaps a very-fast-moving Piston extending into the bomb's nose may be enough force to trigger it into exploding...
@jamesPLANESii Sn0w updated his site to include a small guide to PID: https://snowflake0s.github.io/funkyguide/pidtuning/
It's of limited use for someone like me unfortunately, as I'm a huge FT (and coding) ignoramus, but maybe you may have better luck? :)
. [Fun Fact: When the FT guide mentioned PIDs, I had actually thought that was referring to PartID, like some GUID that you could make powerful scripts by having a part control another part, or something to that effect. Comically, all these months later, that seems to kinda be what the new Variables system is capable of doing! heh)
@Duckw0rthplanes do it by placing the [INSERT PART] on the [INSERT LOCATION] and nudging [SAID PART] to wherever you want it to be
"This is the way..." Creed of Clan Death Watch; a long time ago in a galaxy far-far away.
lol But yea, that really IS the "way" with Simple Planes, and honestly my only 'grief' with that fact is that it technically contradicts the game's name and that it's not "Simple" at that point.
NOW... don't get me wrong! I have no qualms with manually doing all that sort of stuff, but if you have to jump through too many hoops in order to get there, it just becomes another eye-roll aspect for long time players heh For new players who lack that know, of how to make stuff work like you need it, then it's frustrating.
.
In other words...
Games like this with lots of capability need to, first and foremost, have parts that Just Work. and don't need futzing with or leave you fumbling around to get it to do what's needed (see: what's expected); things must be intuitive for base level/new players.
.
The v1.11 update IS awesome, and while it may seem like I'm doing lots of "complaining", that's only because there's no contrasting statements from me that praise it. Such is the case with most stuff, sadly. We oft do not share the "good", because we're too busy enjoying doing it to want to take time to come and leave that feedback. Alas, when there is a hiccup -- aka the "bad" -- then we almost feel obligated to share that, not just in the hopes it can be fixed/changed, but also to let others know so they can know what to expect. :P
So I do sincerely apologize to the Devs, and also the community (since you have to deal with my posts too lol) for what may seem like "constant complaining" from me.
Yes, but what I've experience isn't anything severe (yet), and it only happens during specific things.
I chalked it up to the fact my game had been running for over 36hrs (minimizing it and sleeping computer).
.
For me it happened when playing with Sliders for changing Dead Weight on a Fuselage part. As I'd slide that setting around, the game would have a curious micro-stutter. and that build only has 483 parts, and my computer has more than enough horsepower for SP.
@AWESOMENESS360 Wasn't it the "Physics" calculations WNP disabled in Designer? (since the Drag system still has to function in thye designer in order for parts to have their Drag Points updated, though I suppose they could make it 'Conditional' to save even more CPU cycles, by having it only calc it when the Drag visual is enabled...)
@IceCraftGaming For me, all three behave the same. In my screenshot above, the itty-bitty line to the left of the one under "Front View" is the CoL.
.
If your CoL/CoM/CoT aren't centered (X=0.000) then it means something in your build is further to one side than the rest. For CoT that's not too bad, you just have to check your engines, as I presume you have 2 of them?
HOWEVER.... It just occurred to me that what you're describing MIGHT be something I also experienced a couple days ago...
.
Did you by chance use the Mirror tool on some parts?
Because I did, and my CoM was favoring one side (even though both sides were identical), which this is what had been causing my plane to taxi and fly towards the Right.
.
Turned out that for whatever reason, the parts I mirrored came from the LEFT side, meaning that some of them on the right weren't registering their weight properly. I determined that when I started changing the "Dead Weight" I had applied to the parts. When I adjusted the Left side, the parts made CoM moved very little (due to having XML modified their mass scale). When I adjusted the SAME parts on the Right side, the CoM moved a ton and everything returned to normal.
.
I had figured it was just because I hadn't shut down Simple Planes for a couple days -- yes, days, as I would minimize the game and put the computer to sleep. But, if you also noticed the odd shift after mirroring parts, it might be a legitimate (and different?) bug we've stumbled on. :)
Even if only having it so you can color the face, that'd work, too.
Granted, in most professional (ie a governing body oversee with standards), I'm sure black face with white text is mandatory for gauges....
However, more private/civilian stuff, and even things like non-transportation related gauges, there are different colors. Mostly white, but with aftermarket vehicle gauges for older cars, you can get all manner of colors for the faces.
.
So I'd suggest a case of having a preset list of color ranges that if the Face gets colored to it, the Text is forced to be something else. Bright Red face = Bright White text. White face = Black text. Navy Blue face = Bright Gray text, etc etc.
Or, simpler and lest labor intensive (to determine which colors get which text): Just make the text color become the literal inversed color of the face! SP already is capable of this with Glass, when you set the transparency to -100. Black glass becomes white, Red becomes Blue, and so on. ($10 says I've reached the post character limit... lmao) (EDIT: Yep! Reposting to solve that...)
@TheSeventh I don't use Notepad++ either, I just had used it out of frustration to confirm (or try to), that I had modified every part to 0 mass.
TL;DR- I had somehow missed checking around 6 parts while manually going through all 175+ of them using Overload, which one of them alone made up 92lbs of the 101lbs.
In the end I managed to get it to 0lbs as expected, so by the time you had commented I had already solved my "issue". lol
(that feeling when you have a reply typed out but wanted to check the rest of the message in case someone else already said it.... but "load more messages" refreshes the stupid page and clears everything you typed... :thumbs_up:)
You can use Bluetooth mouse, too. Works nice if you don't have the USB-A -> USB-C adapter (either lost, or your phone/tablet didnt' come with one).
I've hooked my Razer up to my Galaxy S8 before, just for kicks.
.
Similarly, the Wii Nunchucks pair effortlessly with Android, or at least they did with my Galaxy S1 back in the day... (Playstation and Xbox need more effort, though)
@BaconEggs check out my comment here. I don't know whether it's functional like I'm hoping, but someone with more FT knowledge may be able to figure that out. :}
.
However, I agree, it'd be quite nice to be able to either effortlessly bind (through perhaps special [new] ""Input"" Attachment Points on parts) the switches/dials/lights/whizbangs to parts to control them.
Admittedly, something would indeed need to be worked out to make it easy for the mobile userbase... but we the SP community are aptly suited to tackle such a creative task! My initial thought would have it where the AG panel would have arrorws to change "pages". Granted, that's a little cumbersome, but it'd at least do the job and not leave them out. (since expecting them to physically interact with switches/etc in Cockpit view, on such a tiny screen, would be mean)
UPDATE: So I was actually serious about making a sky-crane to hoist El Tortuginator skywards...
I have designed the craft, in its Mk.I form. Mainly it's testing the concept I had for how to definably make it "Stealth", and, a Claw mechanism.
No idea if the claw part will actually be able to pick up something as intended, nor whether my craft currently has enough lifting capability to tackle the beast (though I gave it a dummy weight of 27,000 lbs and it's doing MORE than fine).
.
HOWEVER, my testing has involved using USS Tiny, and what I think I have managed to determine, is that I do have enough power to manipulate its speed!
I first was tugging it forward and it went up to 24MPH.
Wondering if perhaps that was just part of its script (as usually the boats seem to travel at 18MPH), I decided to pitch backwards and tug on it to slow it down... I've left it go in the background as I type this, and as of right now I've gotten USS Tiny down to 3MPH... correction, 2MPH!
.
Hopefully this isn't part of a scripted scenario it plays out lol
(it's down to 1MPH now...)
So for what it's worth, this is what I ended up with which finally worked -- again, this was on a NON-AI build, and is for an INVERSE-MOUNTED turret (under-body): AG 1 = Turn Off/On Auto-Aim (locks turret to default forward-facing, guns-leveled positions); even when On, requires a Target selected to actually orient it. AG 1 Enabled = Auto-Aim Off; therefore, is On by default when you spawn. Machinegun:rotation: 0,0,0
. . . . . . . . . . . . . Gun:
. . . . . . . . . . . . . . . . .muzzleVelocity: 1200 JointRotator-1:rotation: 0,0,180
. . . . . . . . . . . . . ControllerInput:
. . . . . . . . . . . . . . . . .activationGroup: -Activate1 & TargetSelected = 1& = & (because our comment system here sucks)
. . . . . . . . . . . . . . . . .invert: true
. . . . . . . . . . . . . . . . .min: -1
. . . . . . . . . . . . . . . . .max: 1
. . . . . . . . . . . . . . . . .input: ((TargetHeading - Heading + rate(TargetHeading)*(((1200 * sin(asin((TargetDistance * 9.81)/(pow(1200, 2)))/2))/9.81) * 2))/180) * -1
. . . . . . . . . . . . . JointRotator:
. . . . . . . . . . . . . . . . .range: 180
. . . . . . . . . . . . . . . . .speed: 0.5
. . . . . . . . . . . . . . . . .damperMultiplier: 0 HingeRotator-1:rotation: 0,0,90
. . . . . . . . . . . . . InputController:
. . . . . . . . . . . . . . . . .activationGroup: -Activate1 & TargetSelected = 1& = &
. . . . . . . . . . . . . . . . .invert: false
. . . . . . . . . . . . . . . . .min: -0.15 - - - - (depressing/elevation, prevents clipping into fuselage)
. . . . . . . . . . . . . . . . .max: 1
. . . . . . . . . . . . . . . . .input: clamp(((TargetElevation + rate(TargetElevation)*(((1000 * sin(asin(TargetDistance / (pow(1000, 2)))/2))) * 2)) * -1) + (asin((((TargetDistance + rate(TargetDistance)*(((1000 * sin(asin(TargetDistance / (pow(1000, 2)))/2))) * 2)))/(pow(1000, 2)))/2) * -1),-10,45)/45
. . . . . . . . . . . . . JointRotator:
. . . . . . . . . . . . . . . . .range: 65 - - - - (your gun's max elevation)
. . . . . . . . . . . . . . . . .speed: 0.4 [NOTE: The "input" code goes off screen because there's no word-wrap, and I haven't figure out how to do Code-Blocks with our system's Markdown... If you copy my whole post into notepad that should work. Otherwise, it's just the code pulled from this build:Three-Five-Zero Division's TFZ-9UFF Twin-Prop Fighter]
Also, while looking at my notes in my txt doc, it seems that even the auto-aiming device's _location_ in respect to the Cockpit, may impact the aiming code... As my note ends by saying that the "aiming is too low", which I presume implies that even if there was no ballistic trajectory to calculate, it'd have been off... but that's only a presumption. At least when using Cannons, since my understanding is they have bullet dro
NNnnooooo LMAO
+2I just made one of these, too! :P
Of course, yours is legitimately way more involved than mine, since you went full custom and I just strapped 2 prop-hubs to a JE90 (I think).
.
Then again, we might've went for slightly different systems? Mine's the Ultra-High Bypass Fan variant which doesn't have (as far as I know) adjustable blade pitch and so I set my props to have a high fixed pitch.
Either way, you'll see it here in a few minutes after I upload my "Alternate Reality" plane I equipped with mine... :}
EDIT: Oh, nice, I'm your first updoot! High five... o/⁺\o
I wonder if someone could make a 3D Plotter using Winches, connected to powered Resizable Wheel trollies which are mounted on a giant Fuselage box. Then have the Winch cables connected to a comparatively muuuch smaller box in the middle, which houses various different guns, configured that way, but with their own Tracer colors, each set to an Action Group to be toggled as needed.
+2.
Then, through control inputs like Pitch and Roll, control the winches, thereby moving the plotter around on a huge X/Y grid. As you move, to a new point, you fire a shot with whatever color you've configured, and.... now you're drawing pixel art! :P
.
May need to set the bullets to zero velocity, so they stay where they are shot from, and make this entire contraption (the frame) able to move, so that once you're done drawing, you can relocate the plotter and see what you've made.... :}
[/batcrapcrazy-idea]
@Sadboye12 "
+2setting it to -100 transparency will make the glass glow"Brilliant... I don't know enough about the finer details (ie: value limits) relating to XML modding. Clearly I just need to go back to my roots: Trial and Error, throwing caution to the wind! :P
.
Huge thanks for sharing that secret! I would probably never have figure it out to set it to a negative value haha
[Also, as someone who is also a "Sadboye", I suggest not giving it any more control over you than it already has, or any more recognition through means like making it your username... Nay, instead I think you should try to spite it, say by changing it to something like Gladboye12! Of course.... that's all predicated on it not being your actual name... lol :}
Which, if it is then, uh... ignore this and hey-look-there's-a-squirrel!
_*smoke-bomb*_]
The nose is interesting heh
+2On the schematic shots the website provides, the cross between a Predator drone and an SR-71, your nose looks like how I'd envision that mashup to appear like :P
.
I dig the entire design though, nice job!
Now that I can FINALLY upvote stuff, 3 years after I downloaded this beautiful space-bird....
+2.... clicks
I wish I knew more to contribute. However, currently, there are most definitely lots of missing stuff, such as that the bombs/missiles/rockets can have their explosive power changed. Cannons have various bullet types, and also can themselves be set to explosive or not.
+2.
Though I was coming here, hoping to find some info on Action Groups, so I could assign a weapon to be Air-to-Air only (thereby not showing up in the Air-to-Ground hud...)
Oh well heh
I still can't upvote, so... Thanks for having originally made the guide!
Request: An option to configure a "Purge" time, which deletes backups that are older than the defined amount of time. Said-time would be on a scale of
+1Days, although if it supportedwormafter the number in order to define "Week(s)" or "Month(s)", that'd be nice, too; default being in days (if no letter modifier added)..
I just looked at my folder and realized it's at 283MB lol
It may not need to be an actively monitored thing, either, to keep down overhead, but perhaps simply a run-time check.
@Technodium
+1lol Glad you liked it (and found it!)
.
Though I don't know what he's screaming about, as we're only pulling 15Gs during extreme loop-de-loops! (which I don't have G included as a readout but maybe should? heh). Plus, when squeezing through the bridge structure near Yaeger or the opening in the Pyramid, I've only crashed two or three times... I mean, come on, right?! :}
</s> haha
@LieutenantSOT Thanks for the info :)
+1Hmm, IAS sort of is, but if that were true -- and honestly, it might be, but my ignorance is getting in the way, so I won't pretend it can't be an option lol -- then everything I thought I had understood about airspeeds was WAY way off! O_O
Which, again, is indeed possible. As only recently did I discover that Ground Speed is not a measure of your horizontal speed across the ground, where changing your AoA would impact your reported GS. Or to put it another way, I thought GS was more or less calculated by the amount of distance you traveled horizontally in a given time.
(Thus why I thought if you, say in a hypothetical scenario, where you had >1:1 T:WR and were pitched up at say 30deg, your GS would drop due to not covering the same distance as quickly from now going upwards too, even though your plane maintained the same velocity)
.
But if you read the quote at the beginning of my comment down below, that definition for True Air Speed really does match what I was expecting OUR
TAS,in game, to be reporting to us. Obviously leading to this surprise that the calculated Mach results were off, and that error rate only grew as Altitude increased..
In the end, though I hope not, it may indeed be a case where an elaborate script (FT equation) is going to be needed in order to factor in air density in the same way that NASA tool does..... If only I understood coding better, and wasn't absolute-trash at math, that might not be so hard! hahaha
On the plus side, I have an ulterior motive to figure that out, too, as it would (I think at least) provide the basis for allowing me to add another 'feature' to a plane I really wanted to.... So fingers crossed I can figure something out! (I'm not hopeful I'll be able to though, as my ""AG Toggled, Multi-Readout, Configurable Measurement System Air Speed Gauge"" [lol what a name] that uses FT, isn't working how it should. *sobs*)
@EnzoDiazUnofficial I completely 100% agree. I'm actually surprised that the base language characters weren't supported, given we do have players from around the globe. (Though admittedly, CJK subset alone has almost 21,000 characters *gulp*)
+1.
Now... That is not an excuse, or even a claim that it's "too many", because Minecraft supports all of those any many more, which at one point was also using an character-image system. I spent lots of time for my server, coming up with cool and beautiful user tags with the various exotic languages it supported. (The African Languages characters [font "Ebrima"] holds a special significance for me as I portrayed the Greek primordial "Khaos" on my server, and fashioned a name out of characters from those languages: ꗣⶋꗇⵙꗟ )
,
But, I digress :P
It'd indeed be great for those to also be given support. I think I have an idea perhaps on why they are be causing performance loss in SP, but I'm out of my element in that regard to know for certain...
Either way, I think it might be due to the placement in the rendering chain, and maybe moving it up higher so that it doesn't have Post-Processing applied, could help? The fact they cast shadows seems to mean they are having extra processing applied to them, but whether the extra processing is necessary for them to look right, is the unknown for me...
@11qazxc Added it to the post :)
+1@11qazxc
+1Alright... How about this...?
Helpful?
Or too complicated?
(I didn't really type the post to need a pic, but instead have all the needed instructions to copy-paste their code and replicate it in game. So trying to make what's shown also make sense, was tough.)
@KingHandspider I'm working on getting it formatted and added to Snowflakeos' Funky Trees Guide, where it'll have its own Labels section!
+1All of the above will be included, and eventually someone with knowledge about FT coding will add the further capabilities that can be done with Labels with FT code :)
Something I'd find super handy for Guns/Cannons, would be a simple "delay" in their projectiles being activated (able to "interact" with builds; can remain ground interactable for all I care).
That way we can hide guns inside the fuselage, or have a Gun Turret on a bomber, and NOT HAVE TO WORRY WE'LL SHOOT OURSELVES... -_-
Or if Jundroo doesn't want to deal with delays...
Could be a variable that uses the "Connected Parts" system to define what constitutes "Ourself" in the game's eyes. A possible variable, albeit a poor example, could be:
weaponCollisionSelfwith default beingTrue(how it is now) orFalsewhere it's like having disableCollisionDamage to False.(I don't know whether it'd be better to have this on a single part, like the Cockpits or Flight Computer, so that it doesn't have to be toggled on EVERYTHING? Or if it should be specific to weapons and can be decided on a per-weapon basis, which ones need to process this?)
.
So in this case, a cannon, machinegun, gatling gun projectiles, or any of the rockets and missiles, when fired they would know NOT to collide with their Parent, Grandparent, etc parts.
However, since all other spawned objects would not be connected to our build, that all those aforementioned projectiles would be able to still collide with them, doing what they were intended to do.
+1.
In other words, it gives us the benefit of
disableCollisionDamage trueordefaultCollisionResponse Nonewhere we don't blow ourselves up, but avoids the issue of those projectiles being unable to collide with anything else that is spawned in. (other planes, ships, land vehicles, or players in Multiplayer matches)lol
+1#TASMasterRace
amirite, @Griffon1? :P
@MintLynx That's what I (try to) do, it's just, sometimes you get in the zone, ya know? :( heh
+1.
I call it "Builder's Vision" for sandbox games like this. Happened to plenty of us, back when I ran a Minecraft server, and we'd be constructing new areas for the players, but would totally forget to monitor the kiddos in chat... :} (The aqua-blue admin chat thankfully became a visual trigger, most of the time, as even then I'd be too zoned in to notice it! lol)
Admittedly, this become longer than originally intended, so... I slapped a TL;DR to the top that delivers the meat and taters' of it.
@meteorbook345 Just out of curiosity...
+1By "sound" are you meaning like audible sounds?
Or
Sound as in "accurate" or "plausible"; ie making more true-to-life builds?
@BeastHunter You upvote a lot of my threads, but you might've missed the on on Label Resource. In it, I linked to this person's 1-part HUD, and you might be able to reverse-engineer it to be better suited to a wheeled-vehicle :D (ie no need for all those Attitude lines)
+1@Kangy *grumbles* lol
+1To really do it proper justice that'd need a lot of images, and, ideally they'd have to be also GIF to show the transition from original to modified. And while a few static images would be doable, I don't have the monthly bandwidth to tackle uploading a bunch of GIFs :( (Blame corporate America's crappy rural internet infrastructure)
.
That's why I opted to provide the two pieces of code in each example.
As with that, all you have to do is select the piece of Fuselage you've just placed out of the Parts Menu, open up Overload, select Fuselage from the drop-down menu, and add the lines.
.
If adding new entries is new to you, that's Ok! It's easy:
1] At the bottom of Overload is a subtle darker-gray box with a + in it. Clicking that adds a new line.
2] Click on it twice (2x), to make two new empty lines
3] In the first new line's "Name" box, paste or type in
fillFront, and in the "Value" box type or paste any of the number sequences I provided in an Example above. ie1,1,0.25,14] In the second new line, put in
fillBackand the second number sequence from that same Example. ie1,1,-5,15] Click on Checkmark in Overload (bottom-right) to accept the changes, and you'll see the Fuselage immediately change.
.
But yea, I just figured it was easier to appreciate the changes first hand, by being able to first play with the Fill sliders through the Parts Setting menu in real time to see the limits of the default 0-to-1 (0% to 100%)... Then be able to contrast it against what I've shown. I didn't think that pics would've actually illustrated what it's doing compared to what was possible via the menu.
Alas, I'm still happy to oblige, so I'll add some basic pics for each example, in case that's all anyone really wanted; give me a bit.
@Bobyo NY... Yep, weird indeed for a 'nado!
Oh and that reminded me of ANOTHER contrast between MN and TN... You mentioned basements, and that was common in MN, but for whatever reason they don't have them in TN. At least not in the same way. Down here, when they do have them, they're walk-out basements where the basement is built into a hill, but one wall is fully exposed with windows and a door.
.
With how much different a basement's temperature can be, you'd think that in the south where it's warmer, they'd want to leverage that cooler underground aspect... but... nope... lol *shrug*
@Wibbley Ah yes, Russia, you certainly have a good relationship and understanding of Winter, then, just as I do.
+1One could even say that growing up where we have, Winter is like a third parent! -- and depending on where Bobyo lives in NY, for him as well! As a parent does, Winter also teaches us what to, or not to do, and the (literally) cold, harsh lessons it presents us each year by living with it for those 4 to 6 months. :D\
.
.... Hmm ok, maybe less like a parent and more like a dysfunctional and mentally unstable Uncle, who bounces between living with family members for various periods of time... lol (thankfully, I am not speaking from experience, but that just feels rather accurate; I imagine it'd be fun having them around for some days, but other days, wishing they would go away... like how it can be with winter!)
@BeastHunter The beauty of the game, at least with shared builds (in case you lose the local save), is we can easily go back and modify stuff to improve it as our knowledge grows. (Or in this case, as new updates add new parts and capabilities!)
+1@CrimsonOnigiri Exactly. The Wings can do this sort of already, so it's not a stretch (pardon the pun) to have similar capability on basic Fuselage ends.
+1.
This would also let us slim down a single corner of a Fuselage part. Similar to what Slice does, but at a / instead of the + that Slice currently does.
.
Although, my new Slice discovery I just posted a new thread about could aid with this a little bit, but it wouldn't be nearly as user-friendly as just letting us move the corners visually.
Love the "thinking outside the box" with the Chaff part! I had not considered to use it like that, for creating 'smoke'... :D
+1@ZeroWithSlashedO @IceCraftGaming Aah ok, so it's just the "Firing Delay" on Rockets, but for the Missiles. Strange that it wasn't in the menu, like it is with Rockets. (Then again, the decision for a LOT of things not being in the menu I've found to be strange, so this is par for the course... lol)
+1.
If I ever decide to make a successor Derpship rocket build, that may come in handy. Though even in my original, I just used the Detatcher to handle all of the timing and staging (ie ignition of the rockets).
.
liftScale will be fun, though, and just so happens I threw together a Blended Wing design these last few days which I'm thinking are going to benefit from this, given it's reluctance to stay aloft under 250MPH lol
,
Anywho, thanks for the explanations!
I very much enjoy this sort of What-If with aircraft :) Not only "backwards", propelling modern with props, but also with modernizing the old with more modern parts!
.
Back almost two decades ago when I learned about "Turbo Props", my immediate thought was "How cool would it be to shoehorn one of them into something like a P-51?!". Wouldn't be until much later that I'd learn people have done such things :D
.
.
@F104Deathtrap Makes me wonder what the top speed potential is on Ultra-High Bypass Fans.
On that note: SHAMELESS PLUG TIME lol
+1Here's my Alternate Reality ""SR-71"" with said Ultra-High Bypass Fans
Also a 1917 de Bruyere. "C.1" that I ran with his design and updated into what I dubbed the "xC.2".
(I have a much larger "C.3" in the works too, but the recent update sidetracked me... considerably... haha)
@Prince1747 Cross your fingers and *hope @BigBushy updates it for SP v1.11 (that came out a couple weeks ago), as it apparently broke any mod that added parts, like this one. :\
+1Ran out of message space lmao C'est la vie....
.
Was going to end with this:
(Note: there are lots of vanilla actions you can perform which will not trigger the auto-save/creation of an undo point, but using Nudge is the quickest way to initiate it. I either nudge, or just clone a part to a random empty area, and delete it. Still, not fool proof.)
Also, @exosuit thankfully you only need to use the "period" trick in these comments. Forum posts and Shared builds allow you to use conventional line-breaks with the Return key. Though I suspect maybe this had been a comment that you decided to transform into a dedicated post, and thus had Cut-and-Pasted it here. :P
+1I'm the same. I prefer the Fine Tuner mod over the in-built variant; however, after I only recently found out the in-built version lets you "Nudge Selected+Connected", that's pretty handy...... when it works....... It's hard to know what Grand-Parent", "Parent", and "Child" parts are, and which one you need to have selected in order for all the other ones to nudge with it. As a result, I often end up having to REMOVE connections from the main build in order to make it so whatever I have selected will move everything no matter which is the actual parent. (Unless there's a "next connected part" cycler hotkey I don't know about that works similar to going "Forward" or "Backwards" along fuselage pieces...)
+1I mean it saves a lot of time from having to manually select every part of a section, but that's only when it works as you want/need! lol
.
I've never used the DesignerSuite connection editor though, but it sounds like I really ought to give it a go...
.
As mentioned, the Scale feature on Fine Tuner is one of the reasons I can't drop using the mod. The other is "Multi-Select". That is just too powerful to do without, and I simply don't understand why either of those didn't make it in.
Another big reason that keeps me using it, is the much better and smaller interface. The vanilla menu is way too big, and without the ability to... well lol "Fine Tune" the UI to suit our own personal desires and screen size, it ends up being too scrolly for me.
.
HOWEVER I do still use the vanilla Nudge! In actuality, I love that I have TWO nudges now. I leave vanilla set to 0.01, and then Fine Tuner mod set to 0.001 for defaults. :P Now if only using vanilla Rotate-by-90 didn't randomly Auto-Connect nearby parts, I'd be able to use that more, too!
.
But yea, I made a similar post, albeit about things to add into the mods, to skip the red-tape of adding it right into the game. Similar community support, but didn't gain any traction with WNP (and HellFire didn't chime in). :(
.
The biggest UGH of all, is that not even the "Now Vanilla" features apply their actions to the Undo History... -_-
Change a connection point, only to have it removed at a later Undo.
Adjust a part's rotation, only to have it reverted at a later Undo.
Make a bunch of changes to a Text Label... (or Input; anything that uses the underlying TextMesh Pro Unity plugin)
I'm sure adding/changing Variables result in their changes being deleted as well, if you happen to Undo later.
Well most devices support 10-Point Touch, as of probably the last 5 years or more. So there's no reason they couldn't add a whole bunch of other features like that for mobile.
ie Assign it to 4-touch, where you could use the Thumb of your off-hand as Input#1, then a 3-finger touch on the primary hand to do the rest.
Although, since I suspect you would need to do all of that within a very quick span of time for it to register as 4-fingers... maybe just a simple button in the corner on mobile, that when it's held-down it toggles "Alt" functions for 1, 2, 3 finger touching. Akin to what Shift and Ctrl do on PC.
@CC1010 If you ever feel like making something, and uploading it as an Unlisted "rough draft" that is in need of tedious fine-tuning of part locations... Feel free to ping me. I'd actually considered making a post to offer that, as I for some reason enjoy that sort of thing. (I often end up doing it on builds I've downloaded anyhow, but don't feel right uploading them often times...)
+1Indeed, all engines definitely need to have the same
volumeXML option that the Cannon does!Engines can get insanely loud in Contra-Rotating builds :( Particularly the Turbo Props...
I had been contemplating making this suggestion for awhile myself! :)
@rfostoria I totally agree!
+1.
That being said: there currently is a way... though sadly it's not the best solution, but you can edit the
scalein XML to make it shorter. However, you also need to change its Length value by the same amount, otherwise it will be an oval shaped wheel <_> lolThe downside to this, is the wheel's physical size gets smaller, hence why it's "not the best solution". Still, a solution.
.
Alternatively, making your own by 'hand' with a Rotator. Fuselage, and Resizable Wheel would be a roughly *thinks....* 5-part solution. 6, if you want a 'fancy wheel cover' lol
Yea, I have a slight issue with being unable to type short posts... lmao Sorry :(
I also now realize that I may have misunderstood you originally... :}
I was under the impression that the "issue" you were presenting was solely that it vanishes during IDLE.
However, I now think I understand what you're saying, in that compared to other prop engines, when they change from the modeled-to-2D visual, their 2D "blurred propeller" texture is MUCH darker (has more contrast) compared to what your Demonstrator/Video show off. Yes?
As for the gauge, yea I can share that for ya. :)
+1If interested, since I was getting so many Overspeeding situations when throttling down, I was curious if the reported RPM in the Warning Text was accurate, so I went about adding an RPM gauge (Tachometer) to watch.
+1.
2 things of note:
1) was that setting up the gauge, using the
inputcode provided by the gauge that theTwin Propplane uses, was a pain in the butt! Foremost, because after having already presumably "fixed" the gauge in that plane, I've come to find out I have actually NOT. Long story short, I went into this usingabs(Rpm1/1200)with the Gauge's "Input Multiplier" set at70. (and "Zero" indication at110)After roughly 45minutes I've narrowed down the CORRECT code, at least for the Turbo Prop engine:
Rpm1/28, with -no- "Input Multiplier". (and "zero" set at108, but that might be[?] irrelevant)I reach that by first having
DebugExpression Rpm1displayed, and then by watching that as I increased the engine's throttle to make it sweep around the dial (quite hard with this setup!). All the numbers now matched up correctly based on the typical """x1000""" values used in Tachs... Which despite this Turbo Prop never really exceeding 1000RPM in normal operation, is actually required to be x1000 because....
2) The on-screen Overspeed Warning does not show the Max RPM the blades are hitting. It's also not the "Shaft" speed, either, because... well first off, it doesn't look to be a gearbox equipped Turbo Prop so I figured must be 1:1 Shaft:Prop (I could be wrong, if torque converters can have differential outputs?). Secondly, because the Debug readout DOES match with the Overspeeed Warning text; however, the text will eventually 'settle' on a reported RPM, and yet the Prop's RPMs are still increasing!
.
In my configuration, using "Almost-blurring" code, and a slightly tweaked Propeller Pitch code, the Warning displays an RPM settling at ~2950RPM... whereas the Debug (and my Gauge) reach a PEAK of 3550RPM!
Thankfully, the "blow-your-engine-up" Overspeed RPM seems to be around 5000RPM... So even with that disparity in what the Warning shows, it's quite a ways off from blowing up. Alas, that's in the ground-test rig at sea-level, so thinner high altitude air might cause all sorts of different results!
.
[Hurray for long posts... Continues below]
TL;DR -
Want to make an Tachometer for your plane? Use this for the Gauge's Input:
+1Rpm1/28and replace 1 with the engine's RPM you want to read -- which is trial and error unfortunately, but seems to base it on Engines furthest forward (higher Z coordinate) come first, and then those along the same X-axis are from Left to Right. At least in my one case I'm basing this on. I had 4 props, 2 front-center (contra), 2 on wing.Front-front was
Rpm1, Front-back wasRpm2, Left Wing wasRpm3, and Right Wing wasRpm4. EVEN THOUGH the two Wing engines were there first, which meant some troubleshooting later, when that engine's gauge was reading 0 despite rotating.(Also lastly, the engine being off doesn't matter, if your plane is moving and prop is spinning, it generates an RPM because it's not the engine's speed *sigh*)
@OtakuNekoToT No no, I get that it's due to how your FT code is. My point was that the way it's setup is:
1) applying too much throttle at Idle, which means...
2) the engine produces too much power, which...
3) causes the blades to spin too fast (ie RPM) because...
4) at Neutral Pitch there is not enough drag to slow the blades down
.
I totally get that it's all setup with the Neutral Pitch to act correctly, in that at idle it won't move the plane. I only included that in my original explanation in order to point out the chain of events that lead to the issue you're experiencing.
.
That being said, the solution is to lower the RPM (via Throttle applied at idle). The question is, how slow or fast are you wanting it to spin?
JUST slow enough not to blur?
or
Quite a bit slower?
Here's what I managed to work out for ya either way (this code is [obviously] only for engine's Throttle, not Pitch, since we don't want to touch that any):
Almost-burring
(smooth(Engine2*0.01,0.1)+(smooth(Engine2*0.01,0.1)?Throttle:0)*0.99
Medium-speed
(smooth(Engine2*0.007,0.1)+(smooth(Engine2*0.007,0.1)?Throttle:0)*0.993
Windmill-speed (ie slow rotation)
(smooth(Engine2*0.002,0.1)+(smooth(Engine2*0.002,0.1)?Throttle:0)*0.998
NOTE:
You might want to add a
smoothto that final "ELSE" output, because in my testing, quickly throttling down (or using Brake, which instantly throttles to 0%) can cause the Blade Pitch to flatten out too much and produce an Over-rev warning. (3648RPM, 2x the "safe" limit)I don't know if that'll cause a similar situation when in flight, but thought it at least merited mentioning.
@CenturyAerospace True, yes, that too. I just figured that the models would've inherently blurred on our screens by spinning faster. So the end result would've (presumably) been the same, and as a result I figured they swapped it out with a 2D blurring image just to save CPU & GPU cycles.
+1(Same reason we use 1 part when we can, instead of 6, as less total part count means it can run better for lower-end systems/mobile.)
.
Grant I only have limited knowledge in rendering, being only a gamer and not a dev of any kind :} Thus, I could easily be wrong, which is ok! heh
@FlyingPatriot "Great minds think alike" is, I believe, how the saying goes! ;)
+1@FairFireFlight
+1lol
*dja-djan-djun* big trucc
*dja-djan-djun* BIG TRUCC
*dja-djan-djun* big trucc
*dja-djan-djun* BIG TRUCC!!!
.
(Although I do suggest listening to the entire song, too lol And for anyone interested, while that band is no more, some members [lead singer for sure] did form back up to become Devil Driver, whose first album at least was great and worth checking out... subsequent ones, eeeh...)
@AeroAeroTheMen You can make your "proximity" currently, assuming you're referring to them not exploding on contact with water. Someone made that already, though unfortunately I don't have the link :\
+1.
I kinda-sorta made a remotely-detonated nuke... although it's a flying nuke, that you pilot remotely (with the new Flight Computer, I can officially make it a drone in that sense). The triggering mechanism was a Cannon that I scaled to being pancake size, placed at the bomb's nose. You just armed its AG, set it to either Air-to-Air or Air-to-Ground, and fired it when you wanted it to explode. (Which, coincidentally, is almost exactly how a nuke goes nuclear! Just not man-triggered, like mine)
.
I think you'd want to use the
AltitudeAglin whatever it is you make that triggers the bomb, since that's the FunkyTrees code for "Above ground level". Setting it toAltitudeAgl = 1then would make it detonate at exactly 1 meter(?) above ground-level; or if over water, at exactly that height above sea-level. :) And I believe with the new Variables system, you could even set it up to fire the cannon attached to it (though I can't say that with certainty). Otherwise perhaps a very-fast-moving Piston extending into the bomb's nose may be enough force to trigger it into exploding...@jamesPLANESii Sn0w updated his site to include a small guide to PID:
+1https://snowflake0s.github.io/funkyguide/pidtuning/
It's of limited use for someone like me unfortunately, as I'm a huge FT (and coding) ignoramus, but maybe you may have better luck? :)
.
[Fun Fact: When the FT guide mentioned PIDs, I had actually thought that was referring to
PartID, like some GUID that you could make powerful scripts by having a part control another part, or something to that effect. Comically, all these months later, that seems to kinda be what the newVariablessystem is capable of doing! heh)"This is the way..." Creed of Clan Death Watch; a long time ago in a galaxy far-far away.
lol But yea, that really IS the "way" with Simple Planes, and honestly my only 'grief' with that fact is that it technically contradicts the game's name and that it's not "Simple" at that point.
+1NOW... don't get me wrong! I have no qualms with manually doing all that sort of stuff, but if you have to jump through too many hoops in order to get there, it just becomes another eye-roll aspect for long time players heh For new players who lack that know, of how to make stuff work like you need it, then it's frustrating.
.
In other words...
Games like this with lots of capability need to, first and foremost, have parts that
Just Work.and don't need futzing with or leave you fumbling around to get it to do what's needed (see: what's expected); things must be intuitive for base level/new players..
The v1.11 update IS awesome, and while it may seem like I'm doing lots of "complaining", that's only because there's no contrasting statements from me that praise it. Such is the case with most stuff, sadly. We oft do not share the "good", because we're too busy enjoying doing it to want to take time to come and leave that feedback. Alas, when there is a hiccup -- aka the "bad" -- then we almost feel obligated to share that, not just in the hopes it can be fixed/changed, but also to let others know so they can know what to expect. :P
So I do sincerely apologize to the Devs, and also the community (since you have to deal with my posts too lol) for what may seem like "constant complaining" from me.
Yes, but what I've experience isn't anything severe (yet), and it only happens during specific things.
I chalked it up to the fact my game had been running for over 36hrs (minimizing it and sleeping computer).
.
For me it happened when playing with Sliders for changing Dead Weight on a Fuselage part. As I'd slide that setting around, the game would have a curious micro-stutter. and that build only has 483 parts, and my computer has more than enough horsepower for SP.
@AWESOMENESS360 Wasn't it the "Physics" calculations WNP disabled in Designer?
+1(since the Drag system still has to function in thye designer in order for parts to have their Drag Points updated, though I suppose they could make it 'Conditional' to save even more CPU cycles, by having it only calc it when the Drag visual is enabled...)
@IceCraftGaming For me, all three behave the same. In my screenshot above, the itty-bitty line to the left of the one under "Front View" is the CoL.
.
If your CoL/CoM/CoT aren't centered (X=0.000) then it means something in your build is further to one side than the rest. For CoT that's not too bad, you just have to check your engines, as I presume you have 2 of them?
HOWEVER.... It just occurred to me that what you're describing MIGHT be something I also experienced a couple days ago...
+1.
Did you by chance use the Mirror tool on some parts?
Because I did, and my CoM was favoring one side (even though both sides were identical), which this is what had been causing my plane to taxi and fly towards the Right.
.
Turned out that for whatever reason, the parts I mirrored came from the LEFT side, meaning that some of them on the right weren't registering their weight properly. I determined that when I started changing the "Dead Weight" I had applied to the parts. When I adjusted the Left side, the parts made CoM moved very little (due to having XML modified their mass scale). When I adjusted the SAME parts on the Right side, the CoM moved a ton and everything returned to normal.
.
I had figured it was just because I hadn't shut down Simple Planes for a couple days -- yes, days, as I would minimize the game and put the computer to sleep. But, if you also noticed the odd shift after mirroring parts, it might be a legitimate (and different?) bug we've stumbled on. :)
Gauge Faces
Even if only having it so you can color the face, that'd work, too.
+1Granted, in most professional (ie a governing body oversee with standards), I'm sure black face with white text is mandatory for gauges....
However, more private/civilian stuff, and even things like non-transportation related gauges, there are different colors. Mostly white, but with aftermarket vehicle gauges for older cars, you can get all manner of colors for the faces.
.
So I'd suggest a case of having a preset list of color ranges that if the Face gets colored to it, the Text is forced to be something else. Bright Red face = Bright White text. White face = Black text. Navy Blue face = Bright Gray text, etc etc.
Or, simpler and lest labor intensive (to determine which colors get which text): Just make the text color become the literal inversed color of the face! SP already is capable of this with Glass, when you set the transparency to -100. Black glass becomes white, Red becomes Blue, and so on.
($10 says I've reached the post character limit... lmao)
(EDIT: Yep! Reposting to solve that...)
I keep forgetting it doesn't tag in-post... :\
+1@JuanNotAnAlt
@TheSeventh I don't use Notepad++ either, I just had used it out of frustration to confirm (or try to), that I had modified every part to 0 mass.
TL;DR- I had somehow missed checking around 6 parts while manually going through all 175+ of them using Overload, which one of them alone made up 92lbs of the 101lbs.
+1In the end I managed to get it to 0lbs as expected, so by the time you had commented I had already solved my "issue". lol
@TheSeventh See top line and last 2 "EDIT" entries lol
+1Also, are we SURE this is Japanese?
+1It honestly looks strikingly like something German WWII by 'Junkers'...
(that feeling when you have a reply typed out but wanted to check the rest of the message in case someone else already said it.... but "load more messages" refreshes the stupid page and clears everything you typed... :thumbs_up:)
You can use Bluetooth mouse, too. Works nice if you don't have the USB-A -> USB-C adapter (either lost, or your phone/tablet didnt' come with one).
I've hooked my Razer up to my Galaxy S8 before, just for kicks.
.
Similarly, the Wii Nunchucks pair effortlessly with Android, or at least they did with my Galaxy S1 back in the day... (Playstation and Xbox need more effort, though)
@BaconEggs check out my comment here. I don't know whether it's functional like I'm hoping, but someone with more FT knowledge may be able to figure that out. :}
+1.
However, I agree, it'd be quite nice to be able to either effortlessly bind (through perhaps special [new] ""Input"" Attachment Points on parts) the switches/dials/lights/whizbangs to parts to control them.
Admittedly, something would indeed need to be worked out to make it easy for the mobile userbase... but we the SP community are aptly suited to tackle such a creative task! My initial thought would have it where the AG panel would have arrorws to change "pages". Granted, that's a little cumbersome, but it'd at least do the job and not leave them out. (since expecting them to physically interact with switches/etc in Cockpit view, on such a tiny screen, would be mean)
UPDATE: So I was actually serious about making a sky-crane to hoist El Tortuginator skywards...
I have designed the craft, in its Mk.I form. Mainly it's testing the concept I had for how to definably make it "Stealth", and, a Claw mechanism.
No idea if the claw part will actually be able to pick up something as intended, nor whether my craft currently has enough lifting capability to tackle the beast (though I gave it a dummy weight of 27,000 lbs and it's doing MORE than fine).
.
HOWEVER, my testing has involved using USS Tiny, and what I think I have managed to determine, is that I do have enough power to manipulate its speed!
I first was tugging it forward and it went up to 24MPH.
Wondering if perhaps that was just part of its script (as usually the boats seem to travel at 18MPH), I decided to pitch backwards and tug on it to slow it down... I've left it go in the background as I type this, and as of right now I've gotten USS Tiny down to 3MPH... correction, 2MPH!
.
Hopefully this isn't part of a scripted scenario it plays out lol
(it's down to 1MPH now...)
EDIT:
Capability of lifting the Turtle into the air: QUESTIONABLE
Capability of ruining a Naval Captain's day: ABSOLUTELY UNDENIABLE
Internet Rule #32: Pics, or it didn't happen.
I think it's time I introduce the Turtle to my Skill Crane on Steroids. :}
+1[msg 2 of 2]
So for what it's worth, this is what I ended up with which finally worked -- again, this was on a NON-AI build, and is for an INVERSE-MOUNTED turret (under-body):
AG 1= Turn Off/On Auto-Aim (locks turret to default forward-facing, guns-leveled positions); even when On, requires a Target selected to actually orient it. AG 1 Enabled = Auto-Aim Off; therefore, is On by default when you spawn.Machinegun:
rotation: 0,0,0. . . . . . . . . . . . . Gun:
. . . . . . . . . . . . . . . . .
muzzleVelocity: 1200JointRotator-1:
rotation: 0,0,180. . . . . . . . . . . . . ControllerInput:
. . . . . . . . . . . . . . . . .
activationGroup: -Activate1 & TargetSelected = 1& = & (because our comment system here sucks). . . . . . . . . . . . . . . . .
invert: true. . . . . . . . . . . . . . . . .
min: -1. . . . . . . . . . . . . . . . .
max: 1. . . . . . . . . . . . . . . . .
input: ((TargetHeading - Heading + rate(TargetHeading)*(((1200 * sin(asin((TargetDistance * 9.81)/(pow(1200, 2)))/2))/9.81) * 2))/180) * -1. . . . . . . . . . . . . JointRotator:
. . . . . . . . . . . . . . . . .
range: 180. . . . . . . . . . . . . . . . .
speed: 0.5. . . . . . . . . . . . . . . . .
damperMultiplier: 0HingeRotator-1:
rotation: 0,0,90. . . . . . . . . . . . . InputController:
. . . . . . . . . . . . . . . . .
activationGroup: -Activate1 & TargetSelected = 1& = &. . . . . . . . . . . . . . . . .
invert: false. . . . . . . . . . . . . . . . .
min: -0.15- - - - (depressing/elevation, prevents clipping into fuselage). . . . . . . . . . . . . . . . .
max: 1. . . . . . . . . . . . . . . . .
input: clamp(((TargetElevation + rate(TargetElevation)*(((1000 * sin(asin(TargetDistance / (pow(1000, 2)))/2))) * 2)) * -1) + (asin((((TargetDistance + rate(TargetDistance)*(((1000 * sin(asin(TargetDistance / (pow(1000, 2)))/2))) * 2)))/(pow(1000, 2)))/2) * -1),-10,45)/45. . . . . . . . . . . . . JointRotator:
. . . . . . . . . . . . . . . . .
range: 65- - - - (your gun's max elevation). . . . . . . . . . . . . . . . .
speed: 0.4[NOTE: The "input" code goes off screen because there's no word-wrap, and I haven't figure out how to do Code-Blocks with our system's Markdown... If you copy my whole post into notepad that should work. Otherwise, it's just the code pulled from this build: Three-Five-Zero Division's TFZ-9UFF Twin-Prop Fighter]
Also, while looking at my notes in my txt doc, it seems that even the auto-aiming device's _location_ in respect to the Cockpit, may impact the aiming code... As my note ends by saying that the "aiming is too low", which I presume implies that even if there was no ballistic trajectory to calculate, it'd have been off... but that's only a presumption. At least when using Cannons, since my understanding is they have bullet dro
+1That feeling when...
You have a good computer, particularly by SP standards, but:
SimplePlanes.exe has stopped working.
T_T
+1Don't get me wrong, I totally expected that to happen, but it's still a shame lol