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.
Updated planes (via XML) will have their name include a Mk. modifier to function as a "version" system. Updates with lots of changes will receive a full number increment (ie Mk.II, Mk.III ... Mk.IX); minor changes (like bug fixes or label typos) will simply append a lowercase letter (ie Mk.IVa, Mk.IVb ... Mk.IVm)
Mk.II
Addressed a large change in Drag Points getting re-calculated that wasn't noticed before the original upload. (caused from removal of unattached 'spare parts' laying around in the designer; weird system is weird...); Top speed has increased to 572mph, up from ~566mph.
Removal of a Sphere in the left gear opening that I forgot to delete :}
Fixed an itty-bitty bug in my Low Fuel Warning causing the mighty big issue of... it not displaying at ALL. (whoops!)
Tweaked the PREV and NEXT Targets buttons back to where I had them originally.
Changed multiple Instrument Cluster Labels' font to Roboto, to match the other labels that were using it. (with the exception of Roll/Slip and the Clock, which remain Military, to preserve formatting)
Addition of a small Digital Display in the empty space under the "Throttle" gauge, which contains:
---Altitude - This will also readout based on whether the "Metric" button is toggled!
---Mach
---Gs
---RPM(a numerical display for RPM makes it easier to throttle back for fuel economy, but maintain max speed)
Added the Selectable Altitude readout from the digital display, to also switch the actual Altitude gauge; Default is Feet, "Metric" button converts to Meters (hurray for recycling of code!)
---Decided to change the color on the text for Altitude, to match the others (material is now 14,6,6 instead of 18,6,6)
---The [FEET] will change to read [METERS] when the Metric button is toggled
Fixed the Clock's Numbers label being too far away from the gauge face.
Fixed Rate of Climb gauge placement
Micro-adjustments to most of the gauges for symmetry
Changed Button color to be darker (fixes over-bright when selected)
---Also changed the Tooltips on Metric and Knots, from "Airspeed: ", to " Readouts", as those (well, Metric) now also modify other displays.
---And added some Transparency to all the Tooltips, to make them less visually intrusive. (If anyone feels their text should also get made smaller, let me know.)
Removed a superfluous fuselage part from the instrument panel
---Moved the Attachment Point of the "Retract Gear" warning label from that part, to the dash cowling
Changed color of Cockpit's "dash" and a piece of Fuselage under the point of the Canopy from the Silver, to the Midnight Blue
Tweaked <cspace> on the two invisible Warning labels, to help make them easier to read.
Minor: rotated the unused "Tsunami" label around so that it can be read from the "2D" images on the page (assuming they update when a new XML is uploaded)
@SilverStar It's only 2ft shorter than a P-51 :) (32.25' vs 29.6')
It's an optical illusion caused by moving the cockpit so far back.
However, I agree, it looks "off", as you described. I probably would've tapered its tail more, but with being limited by a fixed-dimension cockpit part (ie, can't make the front and back widths different sizes), I had to make due with how it is. Although, looking at that top-down image, I could possibly trim the pieces just behind the cockpit and in front of the tail. But I don't think it'd really help make it look any longer from the side.
Also *le gasp* Thanks to everyone for the spotlights (sorry @Clutch I had meant to thank you earlier!), AND even by Mr... mm I'll avoid a SouthPark reference... AndrewGarrison! <3 And it meeting the standards to get Curated makes me happy, as that was a personal goal I thought I'd miss out on! :D EDIT: Although, I'd forgotten that updating the XML would require it to be RE-curated. At least I saw it had been! heh
Updated XML with lots of changes: bug fixes, tweaks, and new instrumentation functionality.
I'll move that list to a stickied comment to act as the Change Log post for that specific update, including the updated name that the plane with those changes has, so anyone who already downloaded it at some other point, can reference the name to know which one they have. (Will use the Mk. system instead of version; this being Mk.II, whereas the original release lacked that.) EDIT: I'm not sure if the new plane is available through the main Download button, or if it's what's in the XML History? The 2D images do not appear to be based on the new XML though, as the Tsunami label still faces the other direction.
I corrected some drag that I didn't know had cropped up after my removal of "spare parts" I had laying around my designer. That, plus 9-bladed propeller @ 35,000FT = Mach 1.00 in level flight :) (35,188ft @ 668mph)
I was incrementally going up altitude levels, which combined with having no speed loss, was slowly lowering the Speed of Sound (thereby, increasing my Mach), and I finally ticked over 1.0..... with 1% fuel left :P
.
While I AM going to be updating the XML shortly, the 9-blade will be absent.
However, the corrected Drag points will be included. As well as:
- Removal of a Sphere in the left gear well that I forgot to delete
- Fixed an itty-bitty bug in my Low Fuel Warning causing the mighty big issue of... it not displaying at ALL. (whoops!)
- Tweaked the PREV and NEXT Targets buttons back to where I had them originally.
- Changed a number of Labels' font on the Instrument Cluster to Roboto, to match the other labels that were using it. (with the exception of Roll/Slip and the Clock, which remain Military, to preserve formatting)
- Decided to change the color on the text for Altitude, to match the rest (material is now 14,6,6 instead of 18,6,6)
- Addition of a small Digital Display in the empty space under the "Throttle" gauge, which contains:
---- Altitude - This will also readout based on whether the "Metric" button is toggled!
---- Mach
---- Gs
---- RPM (a numerical display for RPM makes it easier to throttle back for fuel economy, but maintain max speed)
- Also added the Selectable Altitude readout from the digital display, to also switch the actual Altitude gauge; Defaults to Feet, "Metric" button converts to Meters (hurray for recycling of code!)
- Fixed the Clock's Numbers label being too far away from the gauge face.
- Fixed Rate of Climb gauge placement
- Micro-adjustments to most of the gauges for symmetry
- Changed Button color to be darker (fixes over-bright when selected)
---- Also changed the Tooltips on Metric and Knots, from "Airspeed: " to " Readouts", as now those (well, Metric) also applies to other displays.
---- And added some Transparency to all the Tooltips, to make them less visually intrusive. (If anyone feels their text should also get made smaller, let me know.)
- Removed a superfluous fuselage part from the cockpit
---- Moved the Attachment Point of the "Retract Gear" warning label from that part, to the dash cowling
- Changed color of Cockpit's "dash" and a piece of Fuselage under the point of the Canopy from the Silver, to the Midnight Blue
- Tweaked <cspace> on the two invisible Warning labels, to help make them easier to read.
- Minor: spun the unused "Tsunami" label around so that it can be read from the "2D" images on the page (assuming they update when a new XML is uploaded)
edit: added additional entries to the Change Log
_edit2: sorry for epic delay in getting the XML uploaded; was under the weather yesterday.
@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
@ChiChiWerx Just to clarify, as there seemed to be a misunderstanding :}
Yes, lower altitude and thus higher air density is better for engine power output.
I suspect the mixup was in regard to where I said the "higher DA, the better", in which I only meant the calculated "DA" value that was being referenced for drag racing. Which even then, I could've mis-remembered. (and is quite likely!)
.
Either way, I didn't mean to convey that a "higher altitude" was better. :P Sorry for that confusion.
I'm going to hide my one huge embarassment down in here... lol
The Elevators racing-stripes, took me quite a bit to get them anal-retentively-perfect... only to have the damn things somehow not match the movements of the Wing Elevators they've wrapped overtop of!!! >_<
Just.... just please don't look at it! hahah You should be enjoying the flight from inside the cockpit anyhow! :}
.
If anyone knows how to fix that though, I'm not above accepting the help!
@ChiChiWerx Thanks for clarifying, AND, for divising that formula for us! :D
.
Having no idea what the values were, I started doing what I do, and just mucking with it further. Comparing back and forth between that NASA Calculator and the values my modifications were generating.
Again, I didn't know until just now, what it was all about, but I was coming here to follow up to say that I had managed to fine tune it further. Though, I only tested it at 33,000ft and 1,019ft: TAS/(341-clamp((Altitude*0.0041437),0,43))
.
However, at those two altitudes, it's:
@ 33,000ft - within a few-ten-thousandths off. (NASA Calc only returns to the thousandths 0.734, to my 0.7339)
@ 1,019ft - it's only roughly 2-thousandths off; 0.735 calced vs my 0.7339
.
I assume that the one oddity I noticed while changing the "per meter of altitude" number, was that up at 33,000ft, anything over 0.0042 (regardless of the initial divisor used) resulted in the same output value.... However, as I check now while it's paused at 1,019ft, all of those readings are now.
Am I correct in my presumption that the reasons is due to the "correction" was running into your imposed clamped maximum of 43?
In the end I think I see where a lot of my initial issue with wrapping my head around it all, was coming from...
I was erroneously pairing temperature with air density on account that at Sea Level, temperature DOES impact air density. A couple decades back I remember some folk who frequent the drag strip, mentioning "DA" (Density Altitude), and that it was was (somehow) determined based on the altitude the track was at, and the air temp of that day. If I recall correctly, the higher the DA the, better, since it meant denser air, which for them meant they could run inject more fuel (they were all easily able to change the programming on their ECU).
.
Fast forward to now, and while I'm sure that temperature is a factor, it no doubt is trivial in comparison to the altitude. Where the amount of atmosphere above that's weighing down is substantially less, causing less compression and thus a thinner atmosphere. (to put it crudely, as is all I'm capable of! lmao)
@edensk Well, bummer. Do we know why Jundroo didn't opt to have TAS factor in altitude (density)?
.
Also, out of curiosity, why does one want to use 340 instead of 343? Is it because of the inherent rounding error SP is prone to, where 340 accounts for that?
Or even a simpler reason: it's easier to remember and still "close enough"? lol
.
Either way, thank you for that! And for the fact that you've always been a great help to anyone with coding question :D
.
EDIT: Oh and then safe to assume that just removing /340 in order to have it output the Altitude-Adjusted-TAS speed?
@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*)
@marcox43 My problem is that if it IS True Air Speed, that only makes it far more likely to be a Bug, since for True Air Speed (emphasis mine):
The true airspeed is the speed that the aircraft travels relative to the air mass in which it is flying. The true airspeed is equal to the ground speed in cases where there is no wind, and is used mostly for flight planning and when quoting aircraft performance specifications. True airspeed can be calculated from either the equivalent airspeed, or the Mach number if the outside air temperature (OAT) is known.
(source: AeroToolbox)
.
Worthy of note is that the middle part, is definitely true with SP. GS == TAS when Wind is disabled.
Or is that Jundroo's intention for TAS in Simple Planes... that its sole function is to provide an accurate speed when, and ONLY when, the player has Wind enabled??
.
I was always under the assumption that it'd be tied to air density on account of the fact that clearly there is SOME density modeling included, since we experience it when passing through certain altitudes...
Around 11,000ft is the first density change I'm aware of.
Another I believe around 25,000ft
I think one around 39,000ft
I've not spend enough time in the 45,000-80,000 range
Pretty sure there's also one somewhere between 91,000-110,000ft
.
That 11,000ft one is the more easily experienced density, particularly in jet powered craft, and especially if it's a faster plane.
.......
Actually! It just dawned on me that the density is modeled MORE than just in that way!
In my current build, which is a Piston Prop, I have the engine RPM-Limited to 3200RPM [maxRpm at 3232]. It's power output is 3500HP, and that's unfortunately way more than needed for SP's physics, for my build (modeled after a Race plane), as just about anything >75% throttle at low altitudes is wasted since its already at Max RPM.
.
At 40,000ft, I can throttle down to about 18%, still achieving Max RPM and therefore suffer no performance loss. At various altitudes I have to use different throttle levels to balance that out, but the benefit of doing so is fuel economy -- legitimate in game economy, not just speaking to real life aircraft performance.
.
My point summarized in a question: if density is modeled to the degree that it is... why wouldn't they be utilizing it with TAS? 🤔
Ranting aside...
I made a post... as I'm sure many before me have... that requested a Copy-Paste like feature for Fine Tuner (using its MutliSelect ability), and letting us Store temporary Sub-Assemblies to the number-row of these Copied selections. For primarily this exact reason.
.
Which paired with my other request of Fine Tuner having a Mirror/Flip function, which ALSO works on what we've MultiSelected...
.
So we could copy and mirror specific portions that for-this-build-only we need to act as a collective part, but can't use Mirror tool because we'd lose our elaborate Attachments system -- or, didn't want to slog through every part to UNDO all the erroneous connections that get made, like when using Rotators.
.
The amount of QoL issues I run into that are present and have been present for years, that I don't see ever getting addressed, have me getting frustrated to the point of wanting to step away from SP again :(
However, it's not just MIrror that sucks at "mirroring" for part connections, or the rare instance that the part ""mirrors"" to the same side, OR the sort of rare instance where the rotations aren't right, that are frustrating.... but also the Drag system's inability to properly be "mirror"!! *sigh*
.
With my build centered -- or rather, what SP insists is the "center", which sometimes drifts to 0.000085 for example -- the SAME part on one side will generate 40-more Drag Points (on average) than the other.
.
But, it's not as simple as being a "bias" to one side or the other...
Nay, the thing will flip-flop between a part on the Left being more-draggy than the right, then another part on the Right that's more-draggy than its Left side counterpart.
.
So I get to play that super-awesome-funtime game of Whack-A-Mole by manually going over almost every damn part where I:
1) Get a Baseline Drag Points count
2) Zero it's dragScale on a part
3) Make a note of the new Drag Points value
4) Change its dragScale back to 1
5) Go to the part on the other side, change itsdragScale to 0
6) Make a note of the new Drag Points value
7) Return its dragScale to 1
8) Compare the results to determine which side's part is "draggier"
9) Go to that side's part, lower its dragScale by a rough guesstimate of an amount (based on how much drag the part creates overall, vs the difference between each side)
10) Note the new Drag Points value... does it now match what the other side alone generated?
---10a) IF YES: damn I'm good!!! Nailed it on the first try! (very very very unlikely) Proceed to Step 11
---10b) IF NO: go-to Step 9 until YES
11) Do all the colors match between Left and Right side parts?
---11a) IF YES: hurray you're done! GET BACK TO WORK!
---11b) IF NO: go-to Step 12
12) Select the next part whose drag clearly doesn't match the other side and go-to Step 1.... :(
.
So I repeat... *sigh*
Decided to make a second comment since I was about to run out of space in that one:
.
My tips:
Don't rely on using "Undo" (CTRL+Z on PC; the icon in the bottom left of the screen), becauase a LOT of the things you do in game are not "logged" like they should be and using Undo actually makes you permanently lose progress. I wish they'd address that, but... it's been ages. Use "Save" instead (CTRL+S). In the learning stages, it's fine to use, but once you start working with Text Labels and Override menu, that's when you want to avoid using it very often.
After you place a Primary Wing, select it, then open up the Override menu (bottom right, next to Play), and where it says Wing-3, change it to Wing-2. That makes it non-flexible (aka 'strong') like the "Structural Wing" but able to have control surfaces like the Primary Wing. If you're making a build that the main wing is made up of Primary Wing and Structural Wing parts, that flexibility is a nightmare, (Confusing I know, but trust me lol)
When it comes to wings, you want the big wings that make the plane fly to either have a "Semi-Symmetric" or "Flat Bottom" airfoil. For the tail fins, you want them to be "Symmetrical". Try to avoid using Symmetrical except for the tail fins (or "canards", which are on the nose).
A crude rule of thumb for the "Center of" Thrust, Mass, Lift (aka CoT-yellow, CoM-red, CoL-blue for spheres in the designer): Keep the CoM between the CoT and CoL; but closer to the CoL. There are exceptions, but that will get you started. When in doubt, look at how other people have balanced that out. (If theirs strays drastically from that, they might be employing Funky Trees magic)
.
Good luck, and may the Force (of Lift overcoming Gravity) be with you.
Everything has been summed up pretty well. My suggestion is, if you're not already a coder, to worry about learning or creating complex Funky Tree controlled vehicles LAST.
You can manage to accomplish a lot of stuff simply by knowing the "IF ? THAN : ELSE" statement.
Granted, you need to know the various different input names/values in order to make that statement "work", but you'd be surprised how easy things are with just that lol
.
Seriously, I can sort of read code snippets enough to follow along, but I'm a certifiable Coding Moron at the end of the day. Just knowing that single thing has let me accomplish some useful stuff (sadly I have no on-hand example for ya, wish I did).
.
Instead, focus on how to use the game interface, and the "quirks" of the system (there are a LOT of quirks unfortunately). Then familiarize yourself with the parts, their individual good and bad attributes. Next work on getting a handle on creating a simple, but functional plane -- by that I mean that it flies well with minimal effort, and doesn't want to enter into a death-spiral when maneuvering (in other words: the fine balancing act between Center of Lift, Center of Mass, and Center of Thrust).
.
Once you have it so you know those "basic" things involved to make a functional plane, learn how to manipulate the Fuselage part to make it look interesting ways, so that you can use it to create the curves your need.
Making "complex" looking builds will bring the challenge of your planes now not wanting to fly right, which will lead you to "XML Modding"; also know as "using the Override menu". As you'll need to turn off or decrease the amount of Drag parts make (as the game is nowhere near perfect in modeling airflow once you start making complex stuff), or lower the mass of others, even make others not physically interact with your plane so that they work as designed (ie landing gear).
.
By THEN you'll be at a point where you'll want to learn the Funky Trees coding. (It's called "Funky Trees" because it's a language special to Simple PLanes which when created, was used to make the Palm Trees react as you got closer, which looks rather.... funky in their behavior)
@parkrangerjerry God that's hilarious, only because it certainly feels that way every...damn...time... ahahah
.
LIGHTBULB!!
That's the next Mod we need!
Anytime the user invokes an action, be it applying a setting to a label, or using Override, or Fine Tuner (mod), the mod will then Add a part (randomly, far from your build) and delete it. (or, invoke two Nudges: one in any direction and the other in the opposite direction.) WHY? Because that does cause the game to write an event to the Undo History, allowing you to actually use it for what it was meant for ;) (I try to make a point of doing that before doing something major that I fear will have undesirable consequences, just so I can use CTR+Z)
UNFORESEEN BONUS!!
This just saved me a bit of time having to re-make something in a Label, due to using "Undo" and having forgotten that just about NOTHING gets applied to the Undo History now. As a result, using "Undo" not only rolled back all the work done in that label... but a ton more work done in ANOTHER label! T_T
.
Was able to pop into that backup folder, then simply copy over the most recent Backup from there over into the AircraftDesigns folder, and load that "backup########" build! :D
.
Literally The gift that keeps on giving...
*nods* The S in "hpgbproductions" stands for Santa
@MrGreen No problem and you're welcome :)
Thanks for helping spread the word with it.
.
(BTW I realized last night that the non-TextMesh Pro font system actually does support all the Unicode characters, as they all show up perfectly fine in Overload. That gave me a bit of reassurance that I may have correctly understood how TextMesh functions, as if it utilized the underlying UI's capabilities, then we wouldn't be seeing unsupported characters. Either way, good that at least it's not an underlying system that's lacking the support!)
@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...
@Stinkypinky, @Freerider2141, @SnoWFLakE0s, @FeatherWing, @ShiroNeko, @Sparky6004, @MrGreen, plus anyone else who happened to share it with friends:
I just wanted to say thank You for helping to pass around this knowledge with the community :)
@Bryan5 Under the images on the left where it says:
Downloads
Under it is a blue rectangular button that says "PC / Mac"
Click that.
It will take you to a small disclaimer page.
On this page, bottom right, is another big blue button that now says "Download"
Click that.
It will take you to DropBox and... that's as far as I went lol
@hpgbproductions Just saw, and grabbed, the mod.
Thank you!
.
I'm also here to make good on my offer to buy ya beer/coffee/lunch (ie $10USD). You can mention me or I can mention you in an Unlisted upload, to send me your PayPal address (which we can delete said upload afterwards to, ensure privacy).
Either way, I'm very grateful! :)
Woo!! HUGE thank you, for making this for me! ^_^ (And good thing I decided to check your recent posts to see if you'd finished it! lol)
@Bobyo WNP78 had replied in my Mod Request thread for this. So at the very least, they're aware of the desire for the function.
I suppose they'll now be able to sort of monitor how desirable this is (on Desktop SP) based on the Download Count, and if it ends up being a considerable portion of the active userbase... it's always possible :) *fingers crossed* (I had thought all along, that the game DID use a timed autosave, and that it was triggered by more things, but I was quite incorrect... heh)
@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.)
@AngularMomentum haha Touche (Although that'd flat out be a request for a different Font Style, as opposed to characters universal to all the included Fonts.)
@Bellcat @MrGreen The thing is, I don't think TextMesh Pro actually CARES about Unicode, UTF-8, or ASCII... Because, if I've followed their documentation correctly (source 1) all of the letters, numbers, and characters get converted into a single, giant 2D Texture (aka Atlas) which then gets referenced based on a coordinate system that corresponds to the particular character you want to have "typed" on the screen.
.
You run a Font through their conversion utility and it converts the fonts into textures, or more accurately I guess they're closer to ye-olde "Sprites". I believe this is also part of the reason behind the (third party) company's choice in naming the Unity plugin: TextMesh Pro, as it displays everything using Meshes?
.
Either way, the give-away for me, that these were being rendered is two fold:
1) The Update Notes they gave us for v1.11 in one of the blogs, indicated that the more text you have displayed, the more memory that's required by SP (I don't remember if they specified, but it'd be VRAM here, which is important since that's different from system memory in most cases)
2) If you pay attention in Designer when a Label is distanced from your build, it casts a Shadow. :P
Now... Even IF that's not the case (that they're not 'texture' assets), and encoding does matter here...
I won't pretend to know this for a fact, but, if I'm understanding this right then they DO currently support Unicode, or at least UTF-8 -- which would be sufficient to cover most of what I suggested. (Pretty sure the Undefined and Private Use would indeed require full, proper Unicode support.)
.
My 'evidence' here (using Arial font) is that these Arrows already work in the game: ←↑→↓
Yet, for their Character Code, CharMap only displays the Unicode option: U+2190, U+2191, U+2192, U+2192.
Where understanding is, if they were old-school ASCII they would _also _ offer an ALT Code; for example the "currency sign": ¤ is Alt+0164
.
My 2 cents at least...
Nice job on those!
And you're absolutely right about changing the size! lol
.
Which to anyone curious, they're referring to changing scale from 1,1,1 until you get the size you want.
You only have to change the first and last number, but make sure they are the same number (like 3,1,3) or it look strange. :P
@11qazxc Hmm interesting... All the Box Drawing characters I've pasted in (either from Arial or MS Gothic fonts) have all produced the "Unsupported Character Square of Doom" :\
.
If you figure out any details on that, please let me know!
@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 :)
@AndrewGarrison @WNP78
Sorry, but having spent quite the amount of time compiling and formatting that, I'm not risking it to chance that it gets seen... :}
@Falkenwut I'll try some additional fonts that I know have a multitude of stars, as I don't think Arial actually had. any! (MS Gothic and MS UI Gothic are one of my go-to fonts for extra characters like that) ---RESULTS: I tried these on the line below (in case they don't show up)
≛⋆★☆☪✡✦✧✩✪✫✬✭✮✯✰✴✵✶✷✸✹❂
Unfortunately, no luck :( But I included them just in case it works for others, like how that Greek Delta DID work for me, but suddenly stopped (I haven't updated since v1.11 was released), so it's worth giving it a try yourself.
I think I'm going to make a formal Request for them and a metric boatload of other characters, to be added to the game. Some would certainly make replica aircraft require a few less parts by having text symbols instead of joined small fuselage pieces... There's a Hammer-and-Sickle character, as well as a Swastika, which would be useful, too. (which I fully appreciate the latter being a touchy one to deal with, and I know it's permitted for strictly historical builds on here, but intentionally including it might not be something Jundroo is comfortable with; perfectly acceptable if not)
.
@X99STRIKER lmao You're.... welcome...?? :P
But srsly... You might change your mind when you see the sort of ways one could apply them as decals. Here's a Work In Progress of mine, to give you an example. The wing pattern was achieved by using only 1 label per wing (and only 2 characters per label)!
@MashMallow A few of the ones it likes to spawn that are user-made (or mine), like to do that on my game, too. I wasn't sure if that was as characteristic of the AI, or the Plane though. (sometimes the planes are borderline unstable just by design and the AI applies too much of counter-adjustment, causing it to really become unstable; thus, either behaving oddly or outright crashing)
.
It's good to hear it isn't just me seeing that.
@Datcha lmao Pretty much, yes! Though, I believe the technical term for that is: "totally shitfaced drunk"
(which now that I actually think about the word, "shitfaced" is definitely an odd choice to describe a level of inebriation... hahah)
@hardy57 Glad to help.
I like to think outside the box and could already see the potential for the ability to use unique characters for not just HUDs or actual Labels, but also styling decals... It just takes a little creative thinking on how to combine/overlay multiple characters together using the Rich Text code. :D
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)
@PioneerThe2nd They fly for me, don't get me wrong. Banking, turning, the occasional one getting stuck in and endless loop-de-loops session...
Some do fine landing at Wright Runway, too.
.
But the North Runway, I've yet to see one succeed, they all seem to nose dive straight into the drink right before the runway, as if their map coordinates for that runway is off lol
I don't know how often the others crash into land/ocean though, since they weren't configured to be indestructible like Twin Prop oddly was... so they 'splode or sink, getting rid of any trace of the crash since their transponder goes dark.
@SnoWFLakE0s This guide doesn't have that included because.......... I don't have the FT knowledge and hadn't gotten around to even looking at the code on that 1-Part Hud, to probe how it gets things done! lol (thanks for reminding me!)
.
As for having it hosted on your FT Guide site, that would be great! I'm sure everyone would greatly appreciate it in a static spot as well. :)
Which, secretly, that was what I was using my "Change Log" comments for... to keep the thread periodically bumped :}
Hmmm I probably should've tried the thing before I posted. heh
Applying that density variable to a Wing does NOT stick. It was probably removed from the game long ago and is a latent setting they forgot to remove.
@CovenantSlayer It's the same folder that our Planes get saved to.
If you're on PC, copy and paste this into a folder's "address box", or after opening Start Menu:
%USERPROFILE%\AppData\LocalLow\Jundroo\SimplePlanes
.
Mac/Linux I dunno, but it's wherever you install Mods to; Mobile, you're on you own lol.
.
Unfortunately, as I found out, we CANNOT modify it *sigh*
Or if we can it'll take doing something additional (I don't want ot make it Read-Only, but I will if I have to), but I went through the trouble of adding a whole bunch of "custom" parts to make my life easier, having pre-set XML options, but they didn't take because the file gets reset each game start. :(
.
There weren't any other juicy bits in there unfortunately. No disable (hidden) parts, or the like. heh
But if you do take a look and also happen to notice it, I think the Studio related stuff are referring to the image of the Part in the Parts Catalog inside the Designer. (I think internally, the designer is called or referred to as the Studio.)
The Unique Characters, as requested to be posted (which show up mostly as a ? in my main post). Note: Most of the Zero-Width characters do not seem to display here, at least in my browser they aren't.
EDIT: @AndrewGarrison Not sure if this is a known Website Bug, but the above characters when posted in the main body, do not display; However, as you can see, they do just fine down here in the comments for some reason. (I'm out of my element here, but my suspicion would be main posts are encoded as ANSI, whereas comments are UTF-8/Unicode?)
@Bellcat I don't think the website supports them... :\ At least, when I've tried in the past they haven't worked. (With the new site features they've added in the last couple weeks, it's possible things have changed...)
Albeit, while the Delta character, comically, does work, for example the 4 thin Up, Down, Left, Right arrows do not.
I'll gladly paste them below this sentence, but I am not expecting anything to show up... At least, they don't for ME (if they do for you, let me know):
▀ ▄ █ ▌ ▐ ▓ ▒ ░ ■ ▬
▲►▼◄← ↑ → ↓ ‹ › »
◊ ○ ◌ ● ◘ ◙ ◦ • ∙ ˑ
☺☻ ☼ ♀ ♂ ♪ ♫
♠ ♣ ♥ ♦ ™ ® ¼ ½ ¾
 Ⱡ ⱡ Ɫ Ᵽ Ɽ ₤ ₫ € ⱷ þ Þ Ø ø
⁞
⁄ ⸗ ꜗ ꜘ ꜙ ᷀ ᷂ ᷃ ᷊
ˈ ‘ ’ ‚ ‛ “ ” „ ‟ ′ ″ ‴ … ‰ ‼ ÷ ±
ᶠ ᶥ ⁿ ₐ ₑ ₒ ₓ ₔ ° ² ³ º † ‡
‖ ‗ − ‒ – — ― ¯ ‾ ˉ
Δ Greek 'Delta'
As I recall, they display when pasting them, but once I hit Submit they vanish. Though, there's a whole row of stuff that it seems even my browser's font lacks heh (The first row of the "Zero-Width Combining Characters", but could be that it's due to the nature of the character that they aren't displaying here.)
. EDIT: Well, color me totally surprise, they did show up :)
Either way, the entire objective of this as an Uploaded Part, was for people to download it and drag the Label over the Sub Assembly button (that displays while dragging stuff) and then create their own part.
Once on a build where you wanted to utilize the characters, you'd place the Label I made, then Edit it to copy out the text needed. As it's WAY faster than having to switch screens to your browser to copy the characters. (I'm on PC and that's still how I do it, keep it in the background of my build! lol)
November 29th Changelog:
- Added the "Font Asset Names", which lists the in-game font name to the internal "font asset" name for TextMesh Pro. (Useless info at the moment)
- Uploaded a Label containing all the thus-far supported Unique Characters I've accumulated. I decided to do this so that Mobile users can download that make it into a Sub-Assembly, then copy-paste from it.
---- REQUEST: If any mobile users happen to use their keyboards to type in the various extended characters they have access to and find something not included, please share. Note: I only included obscure or symmetrical characters that could be used to stylize builds or interfaces. The "A" I included was for it's symmetrical element, but tried to stay away from non-English languages as to not offend anyone; the others in that row are Currency symbols. Thanks!
Aaannd stumble across ANOTHER one, this time coming out of the DesignerParts.xml...
On the "Vertical Stabilizer" and "Horizontal Stabilizer", in their Wing category, resides this curiosity: density="5.6"
The Primary, Structural Wing, and Structural Panel all lack it. That would make me think they're using a default value; however, if a part uses a default value that means it does not save it to the plane's XML file.... meaning that this density should show up in them (or through Override).
.
At any rate, Googled "what is wing density" and:
Wing density is then simply the aircraft mass m over its wing volume VOLwing. This represents the mean density of the aircraft as if it were compressed into its wing.
(I had to fudge the formatting a bit since the forums doesn't support Subscript, but originally it was "VolWing" and Wing was subscript.)
From this journal/paper via Cambridge.org: "On the wing density and the inflation factor of aircraft"
.
Unfortunately that's way out of my league... but, it sounds like POSSIBLY changing it can (if it's still supported in the game) could effect the "Wing Loading" value. And/Or impact the amount of Wing Flex exhibited in Wing-1 (unused part) and Wing-3 parts?? (as a Wing-2 part doesn't exhibit any flexing)
@Gestour I thought, technically speaking, someone recently (maybe Kenneth) had figured out that they could still release them for Android by using older tools?
I seem to recall reading that in the comments on one of that person's mod's page.
.
Granted, this was during v1.10, and the switch to a newer built of Unity might've rendered their method unworkable...
That is, until you start to fly REALLY high, at which point you enter into another industry, all of which uses Metric... Even NASA. lol
I'm 'Murican though, so it's MPH, Feet, and degrees Farfignugen. I have noticed that Knots are preeeetty close to MPH, thanks to the Gauges, but it's a large enough discrepancy up around 240MPH that it's around 220Knots; not so bad really.
@ReturnOfJeffChandler Mmm You could start here maybe?? lol
But hard to trust the info there, because of how incorrect that top value provided is. That was only true (IMO at least) until the very early 2000s, before someone thew a hissyfit over the fact the fries were cooked in the same grease as some meat (and had some beef fat too I think, for flavor). For crying out loud, if you're going to an unhealthy-as-hell place such as McD's, your opinion on how they make their fries should be completely invalid! hahaha But nope, had to ruin it for the rest of us... *sobs*
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.
@V Can you please @ me when you post your findings? :)
Also, thanks for taking the time to do so!
CHANGE LOG:
Updated planes (via XML) will have their name include a
Mk.modifier to function as a "version" system. Updates with lots of changes will receive a full number increment(ie Mk.II, Mk.III ... Mk.IX); minor changes (like bug fixes or label typos) will simply append a lowercase letter(ie Mk.IVa, Mk.IVb ... Mk.IVm)Mk.II
Altitude- This will also readout based on whether the "Metric" button is toggled!MachGsRPM(a numerical display for RPM makes it easier to throttle back for fuel economy, but maintain max speed)materialis now14,6,6instead of18,6,6)[FEET]will change to read[METERS]when the Metric button is toggled@SilverStar It's only 2ft shorter than a P-51 :) (32.25' vs 29.6')
It's an optical illusion caused by moving the cockpit so far back.
However, I agree, it looks "off", as you described. I probably would've tapered its tail more, but with being limited by a fixed-dimension cockpit part (ie, can't make the front and back widths different sizes), I had to make due with how it is. Although, looking at that top-down image, I could possibly trim the pieces just behind the cockpit and in front of the tail. But I don't think it'd really help make it look any longer from the side.
Also *le gasp* Thanks to everyone for the spotlights (sorry @Clutch I had meant to thank you earlier!), AND even by Mr... mm I'll avoid a SouthPark reference... AndrewGarrison! <3 And it meeting the standards to get Curated makes me happy, as that was a personal goal I thought I'd miss out on! :D
EDIT: Although, I'd forgotten that updating the XML would require it to be RE-curated. At least I saw it had been! heh
Updated XML with lots of changes: bug fixes, tweaks, and new instrumentation functionality.
I'll move that list to a stickied comment to act as the Change Log post for that specific update, including the updated name that the plane with those changes has, so anyone who already downloaded it at some other point, can reference the name to know which one they have. (Will use the Mk. system instead of version; this being
Mk.II, whereas the original release lacked that.)EDIT: I'm not sure if the new plane is available through the main Download button, or if it's what's in the XML History? The 2D images do not appear to be based on the new XML though, as the Tsunami label still faces the other direction.
I corrected some drag that I didn't know had cropped up after my removal of "spare parts" I had laying around my designer. That, plus 9-bladed propeller @ 35,000FT = Mach 1.00 in level flight :) (35,188ft @ 668mph)
I was incrementally going up altitude levels, which combined with having no speed loss, was slowly lowering the Speed of Sound (thereby, increasing my Mach), and I finally ticked over 1.0..... with 1% fuel left :P
.
While I AM going to be updating the XML shortly, the 9-blade will be absent.
However, the corrected Drag points will be included. As well as:
- Removal of a Sphere in the left gear well that I forgot to delete
- Fixed an itty-bitty bug in my Low Fuel Warning causing the mighty big issue of... it not displaying at ALL. (whoops!)
- Tweaked the PREV and NEXT Targets buttons back to where I had them originally.
- Changed a number of Labels' font on the Instrument Cluster to Roboto, to match the other labels that were using it. (with the exception of Roll/Slip and the Clock, which remain Military, to preserve formatting)
- Decided to change the color on the text for Altitude, to match the rest (
materialis now14,6,6instead of18,6,6)- Addition of a small Digital Display in the empty space under the "Throttle" gauge, which contains:
---- Altitude - This will also readout based on whether the "Metric" button is toggled!
---- Mach
---- Gs
---- RPM (a numerical display for RPM makes it easier to throttle back for fuel economy, but maintain max speed)
- Also added the Selectable Altitude readout from the digital display, to also switch the actual Altitude gauge; Defaults to Feet, "Metric" button converts to Meters (hurray for recycling of code!)
- Fixed the Clock's Numbers label being too far away from the gauge face.
- Fixed Rate of Climb gauge placement
- Micro-adjustments to most of the gauges for symmetry
- Changed Button color to be darker (fixes over-bright when selected)
---- Also changed the Tooltips on Metric and Knots, from "Airspeed: " to " Readouts", as now those (well, Metric) also applies to other displays.
---- And added some Transparency to all the Tooltips, to make them less visually intrusive. (If anyone feels their text should also get made smaller, let me know.)
- Removed a superfluous fuselage part from the cockpit
---- Moved the Attachment Point of the "Retract Gear" warning label from that part, to the dash cowling
- Changed color of Cockpit's "dash" and a piece of Fuselage under the point of the Canopy from the Silver, to the Midnight Blue
- Tweaked <cspace> on the two invisible Warning labels, to help make them easier to read.
- Minor: spun the unused "Tsunami" label around so that it can be read from the "2D" images on the page (assuming they update when a new XML is uploaded)
edit: added additional entries to the Change Log
_edit2: sorry for epic delay in getting the XML uploaded; was under the weather yesterday.
@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
@ChiChiWerx Just to clarify, as there seemed to be a misunderstanding :}
Yes, lower altitude and thus higher air density is better for engine power output.
I suspect the mixup was in regard to where I said the "higher DA, the better", in which I only meant the calculated "DA" value that was being referenced for drag racing. Which even then, I could've mis-remembered. (and is quite likely!)
.
Either way, I didn't mean to convey that a "higher altitude" was better. :P Sorry for that confusion.
I'm going to hide my one huge embarassment down in here... lol
The Elevators racing-stripes, took me quite a bit to get them anal-retentively-perfect... only to have the damn things somehow not match the movements of the Wing Elevators they've wrapped overtop of!!! >_<
Just.... just please don't look at it! hahah You should be enjoying the flight from inside the cockpit anyhow! :}
.
If anyone knows how to fix that though, I'm not above accepting the help!
@ChiChiWerx Thanks for clarifying, AND, for divising that formula for us! :D
.
Having no idea what the values were, I started doing what I do, and just mucking with it further. Comparing back and forth between that NASA Calculator and the values my modifications were generating.
Again, I didn't know until just now, what it was all about, but I was coming here to follow up to say that I had managed to fine tune it further. Though, I only tested it at 33,000ft and 1,019ft:
TAS/(341-clamp((Altitude*0.0041437),0,43)).
However, at those two altitudes, it's:
@ 33,000ft - within a few-ten-thousandths off. (NASA Calc only returns to the thousandths 0.734, to my 0.7339)
@ 1,019ft - it's only roughly 2-thousandths off; 0.735 calced vs my 0.7339
.
I assume that the one oddity I noticed while changing the "per meter of altitude" number, was that up at 33,000ft, anything over
0.0042(regardless of the initial divisor used) resulted in the same output value.... However, as I check now while it's paused at 1,019ft, all of those readings are now.Am I correct in my presumption that the reasons is due to the "correction" was running into your imposed clamped maximum of 43?
In the end I think I see where a lot of my initial issue with wrapping my head around it all, was coming from...
I was erroneously pairing temperature with air density on account that at Sea Level, temperature DOES impact air density. A couple decades back I remember some folk who frequent the drag strip, mentioning "DA" (Density Altitude), and that it was was (somehow) determined based on the altitude the track was at, and the air temp of that day. If I recall correctly, the higher the DA the, better, since it meant denser air, which for them meant they could run inject more fuel (they were all easily able to change the programming on their ECU).
.
Fast forward to now, and while I'm sure that temperature is a factor, it no doubt is trivial in comparison to the altitude. Where the amount of atmosphere above that's weighing down is substantially less, causing less compression and thus a thinner atmosphere. (to put it crudely, as is all I'm capable of! lmao)
@edensk Well, bummer. Do we know why Jundroo didn't opt to have TAS factor in altitude (density)?
.
Also, out of curiosity, why does one want to use 340 instead of 343? Is it because of the inherent rounding error SP is prone to, where 340 accounts for that?
Or even a simpler reason: it's easier to remember and still "close enough"? lol
.
Either way, thank you for that! And for the fact that you've always been a great help to anyone with coding question :D
.
EDIT: Oh and then safe to assume that just removing
/340in order to have it output the Altitude-Adjusted-TAS speed?@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*)
@X99STRIKER
If my post is really long, take your phone with to the john!
When you're going #2, read it while you're on the loo!
:P
@marcox43 My problem is that if it IS True Air Speed, that only makes it far more likely to be a Bug, since for True Air Speed (emphasis mine):
(source: AeroToolbox)
.
Worthy of note is that the middle part, is definitely true with SP.
GS==TASwhen Wind is disabled.Or is that Jundroo's intention for
TASin Simple Planes... that its sole function is to provide an accurate speed when, and ONLY when, the player has Wind enabled??.
I was always under the assumption that it'd be tied to air density on account of the fact that clearly there is SOME density modeling included, since we experience it when passing through certain altitudes...
Around 11,000ft is the first density change I'm aware of.
Another I believe around 25,000ft
I think one around 39,000ft
I've not spend enough time in the 45,000-80,000 range
Pretty sure there's also one somewhere between 91,000-110,000ft
.
That 11,000ft one is the more easily experienced density, particularly in jet powered craft, and especially if it's a faster plane.
.......
Actually! It just dawned on me that the density is modeled MORE than just in that way!
In my current build, which is a Piston Prop, I have the engine RPM-Limited to 3200RPM [
maxRpmat3232]. It's power output is 3500HP, and that's unfortunately way more than needed for SP's physics, for my build (modeled after a Race plane), as just about anything >75% throttle at low altitudes is wasted since its already at Max RPM..
At 40,000ft, I can throttle down to about 18%, still achieving Max RPM and therefore suffer no performance loss. At various altitudes I have to use different throttle levels to balance that out, but the benefit of doing so is fuel economy -- legitimate in game economy, not just speaking to real life aircraft performance.
.
My point summarized in a question: if density is modeled to the degree that it is... why wouldn't they be utilizing it with
TAS? 🤔Ranting aside...
+2I made a post... as I'm sure many before me have... that requested a Copy-Paste like feature for Fine Tuner (using its MutliSelect ability), and letting us Store temporary Sub-Assemblies to the number-row of these Copied selections. For primarily this exact reason.
.
Which paired with my other request of Fine Tuner having a Mirror/Flip function, which ALSO works on what we've MultiSelected...
.
So we could copy and mirror specific portions that for-this-build-only we need to act as a collective part, but can't use Mirror tool because we'd lose our elaborate Attachments system -- or, didn't want to slog through every part to UNDO all the erroneous connections that get made, like when using Rotators.
.
The amount of QoL issues I run into that are present and have been present for years, that I don't see ever getting addressed, have me getting frustrated to the point of wanting to step away from SP again :(
YES! So much this!
However, it's not just MIrror that sucks at "mirroring" for part connections, or the rare instance that the part ""mirrors"" to the same side, OR the sort of rare instance where the rotations aren't right, that are frustrating.... but also the Drag system's inability to properly be "mirror"!! *sigh*
+2.
With my build centered -- or rather, what SP insists is the "center", which sometimes drifts to 0.000085 for example -- the SAME part on one side will generate 40-more Drag Points (on average) than the other.
.
But, it's not as simple as being a "bias" to one side or the other...
Nay, the thing will flip-flop between a part on the Left being more-draggy than the right, then another part on the Right that's more-draggy than its Left side counterpart.
.
So I get to play that super-awesome-funtime game of Whack-A-Mole by manually going over almost every damn part where I:
1) Get a Baseline Drag Points count
2) Zero it's
dragScaleon a part3) Make a note of the new Drag Points value
4) Change its
dragScaleback to 15) Go to the part on the other side, change its
dragScaleto 06) Make a note of the new Drag Points value
7) Return its
dragScaleto 18) Compare the results to determine which side's part is "draggier"
9) Go to that side's part, lower its
dragScaleby a rough guesstimate of an amount (based on how much drag the part creates overall, vs the difference between each side)10) Note the new Drag Points value... does it now match what the other side alone generated?
---10a) IF YES: damn I'm good!!! Nailed it on the first try! (very very very unlikely) Proceed to Step 11
---10b) IF NO: go-to Step 9 until YES
11) Do all the colors match between Left and Right side parts?
---11a) IF YES: hurray you're done! GET BACK TO WORK!
---11b) IF NO: go-to Step 12
12) Select the next part whose drag clearly doesn't match the other side and go-to Step 1.... :(
.
So I repeat... *sigh*
Decided to make a second comment since I was about to run out of space in that one:
.
My tips:
.
Good luck, and may the Force (of Lift overcoming Gravity) be with you.
Everything has been summed up pretty well. My suggestion is, if you're not already a coder, to worry about learning or creating complex Funky Tree controlled vehicles LAST.
You can manage to accomplish a lot of stuff simply by knowing the "IF ? THAN : ELSE" statement.
Granted, you need to know the various different input names/values in order to make that statement "work", but you'd be surprised how easy things are with just that lol
.
Seriously, I can sort of read code snippets enough to follow along, but I'm a certifiable Coding Moron at the end of the day. Just knowing that single thing has let me accomplish some useful stuff (sadly I have no on-hand example for ya, wish I did).
.
Instead, focus on how to use the game interface, and the "quirks" of the system (there are a LOT of quirks unfortunately). Then familiarize yourself with the parts, their individual good and bad attributes. Next work on getting a handle on creating a simple, but functional plane -- by that I mean that it flies well with minimal effort, and doesn't want to enter into a death-spiral when maneuvering (in other words: the fine balancing act between Center of Lift, Center of Mass, and Center of Thrust).
.
Once you have it so you know those "basic" things involved to make a functional plane, learn how to manipulate the Fuselage part to make it look interesting ways, so that you can use it to create the curves your need.
Making "complex" looking builds will bring the challenge of your planes now not wanting to fly right, which will lead you to "XML Modding"; also know as "using the Override menu". As you'll need to turn off or decrease the amount of Drag parts make (as the game is nowhere near perfect in modeling airflow once you start making complex stuff), or lower the mass of others, even make others not physically interact with your plane so that they work as designed (ie landing gear).
.
By THEN you'll be at a point where you'll want to learn the Funky Trees coding. (It's called "Funky Trees" because it's a language special to Simple PLanes which when created, was used to make the Palm Trees react as you got closer, which looks rather.... funky in their behavior)
@parkrangerjerry God that's hilarious, only because it certainly feels that way every...damn...time... ahahah
.
LIGHTBULB!!
That's the next Mod we need!
Anytime the user invokes an action, be it applying a setting to a label, or using Override, or Fine Tuner (mod), the mod will then Add a part (randomly, far from your build) and delete it. (or, invoke two Nudges: one in any direction and the other in the opposite direction.)
WHY? Because that does cause the game to write an event to the Undo History, allowing you to actually use it for what it was meant for ;)
(I try to make a point of doing that before doing something major that I fear will have undesirable consequences, just so I can use CTR+Z)
UNFORESEEN BONUS!!
This just saved me a bit of time having to re-make something in a Label, due to using "Undo" and having forgotten that just about NOTHING gets applied to the Undo History now. As a result, using "Undo" not only rolled back all the work done in that label... but a ton more work done in ANOTHER label! T_T
.
Was able to pop into that backup folder, then simply copy over the most recent Backup from there over into the AircraftDesigns folder, and load that "backup########" build! :D
.
Literally
The gift that keeps on giving...*nods* The S in "hpgbproductions" stands for Santa
@MrGreen No problem and you're welcome :)
Thanks for helping spread the word with it.
.
(BTW I realized last night that the non-TextMesh Pro font system actually does support all the Unicode characters, as they all show up perfectly fine in Overload. That gave me a bit of reassurance that I may have correctly understood how TextMesh functions, as if it utilized the underlying UI's capabilities, then we wouldn't be seeing unsupported characters. Either way, good that at least it's not an underlying system that's lacking the support!)
@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...
@Stinkypinky, @Freerider2141, @SnoWFLakE0s, @FeatherWing, @ShiroNeko, @Sparky6004, @MrGreen, plus anyone else who happened to share it with friends:
I just wanted to say thank You for helping to pass around this knowledge with the community :)
@11qazxc Added it to the post :)
+1@Bryan5 Under the images on the left where it says:
Downloads
Under it is a blue rectangular button that says "PC / Mac"
+6Click that.
It will take you to a small disclaimer page.
On this page, bottom right, is another big blue button that now says "Download"
Click that.
It will take you to DropBox and... that's as far as I went lol
@hpgbproductions Just saw, and grabbed, the mod.
Thank you!
.
I'm also here to make good on my offer to buy ya beer/coffee/lunch (ie $10USD). You can mention me or I can mention you in an Unlisted upload, to send me your PayPal address (which we can delete said upload afterwards to, ensure privacy).
Either way, I'm very grateful! :)
Woo!! HUGE thank you, for making this for me! ^_^
(And good thing I decided to check your recent posts to see if you'd finished it! lol)
@Bobyo WNP78 had replied in my Mod Request thread for this. So at the very least, they're aware of the desire for the function.
+5I suppose they'll now be able to sort of monitor how desirable this is (on Desktop SP) based on the Download Count, and if it ends up being a considerable portion of the active userbase... it's always possible :) *fingers crossed*
(I had thought all along, that the game DID use a timed autosave, and that it was triggered by more things, but I was quite incorrect... heh)
@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.)
@AngularMomentum haha Touche
(Although that'd flat out be a request for a different Font Style, as opposed to characters universal to all the included Fonts.)
@Bellcat @MrGreen The thing is, I don't think TextMesh Pro actually CARES about Unicode, UTF-8, or ASCII... Because, if I've followed their documentation correctly (source 1) all of the letters, numbers, and characters get converted into a single, giant 2D Texture (aka Atlas) which then gets referenced based on a coordinate system that corresponds to the particular character you want to have "typed" on the screen.
.
You run a Font through their conversion utility and it converts the fonts into textures, or more accurately I guess they're closer to ye-olde "Sprites". I believe this is also part of the reason behind the (third party) company's choice in naming the Unity plugin: TextMesh Pro, as it displays everything using Meshes?
.
Either way, the give-away for me, that these were being rendered is two fold:
1) The Update Notes they gave us for v1.11 in one of the blogs, indicated that the more text you have displayed, the more memory that's required by SP (I don't remember if they specified, but it'd be VRAM here, which is important since that's different from system memory in most cases)
2) If you pay attention in Designer when a Label is distanced from your build, it casts a Shadow. :P
Now... Even IF that's not the case (that they're not 'texture' assets), and encoding does matter here...
I won't pretend to know this for a fact, but, if I'm understanding this right then they DO currently support Unicode, or at least UTF-8 -- which would be sufficient to cover most of what I suggested. (Pretty sure the Undefined and Private Use would indeed require full, proper Unicode support.)
.
My 'evidence' here (using Arial font) is that these Arrows already work in the game: ←↑→↓
Yet, for their Character Code, CharMap only displays the Unicode option:
U+2190,U+2191,U+2192,U+2192.Where understanding is, if they were old-school ASCII they would _also _ offer an ALT Code; for example the "currency sign": ¤ is
Alt+0164.
My 2 cents at least...
Nice job on those!
+5And you're absolutely right about changing the size! lol
.
Which to anyone curious, they're referring to changing
scalefrom1,1,1until you get the size you want.You only have to change the first and last number, but make sure they are the same number (like
3,1,3) or it look strange. :P@11qazxc Hmm interesting... All the Box Drawing characters I've pasted in (either from Arial or MS Gothic fonts) have all produced the "Unsupported Character Square of Doom" :\
.
If you figure out any details on that, please let me know!
@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 :)
@AndrewGarrison @WNP78
+3Sorry, but having spent quite the amount of time compiling and formatting that, I'm not risking it to chance that it gets seen... :}
@Falkenwut I'll try some additional fonts that I know have a multitude of stars, as I don't think Arial actually had. any! (
MS GothicandMS UI Gothicare one of my go-to fonts for extra characters like that)---RESULTS: I tried these on the line below (in case they don't show up)
≛⋆★☆☪✡✦✧✩✪✫✬✭✮✯✰✴✵✶✷✸✹❂
Unfortunately, no luck :( But I included them just in case it works for others, like how that Greek Delta DID work for me, but suddenly stopped (I haven't updated since v1.11 was released), so it's worth giving it a try yourself.
I think I'm going to make a formal Request for them and a metric boatload of other characters, to be added to the game. Some would certainly make replica aircraft require a few less parts by having text symbols instead of joined small fuselage pieces... There's a Hammer-and-Sickle character, as well as a Swastika, which would be useful, too. (which I fully appreciate the latter being a touchy one to deal with, and I know it's permitted for strictly historical builds on here, but intentionally including it might not be something Jundroo is comfortable with; perfectly acceptable if not)
.
@X99STRIKER lmao You're.... welcome...?? :P
But srsly... You might change your mind when you see the sort of ways one could apply them as decals. Here's a Work In Progress of mine, to give you an example. The wing pattern was achieved by using only 1 label per wing (and only 2 characters per label)!
@MashMallow A few of the ones it likes to spawn that are user-made (or mine), like to do that on my game, too. I wasn't sure if that was as characteristic of the AI, or the Plane though.
(sometimes the planes are borderline unstable just by design and the AI applies too much of counter-adjustment, causing it to really become unstable; thus, either behaving oddly or outright crashing)
.
It's good to hear it isn't just me seeing that.
@Datcha lmao Pretty much, yes! Though, I believe the technical term for that is: "totally shitfaced drunk"
(which now that I actually think about the word, "shitfaced" is definitely an odd choice to describe a level of inebriation... hahah)
@hardy57 Glad to help.
I like to think outside the box and could already see the potential for the ability to use unique characters for not just HUDs or actual Labels, but also styling decals... It just takes a little creative thinking on how to combine/overlay multiple characters together using the Rich Text code. :D
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)@PioneerThe2nd They fly for me, don't get me wrong. Banking, turning, the occasional one getting stuck in and endless loop-de-loops session...
Some do fine landing at Wright Runway, too.
.
But the North Runway, I've yet to see one succeed, they all seem to nose dive straight into the drink right before the runway, as if their map coordinates for that runway is off lol
I don't know how often the others crash into land/ocean though, since they weren't configured to be indestructible like Twin Prop oddly was... so they 'splode or sink, getting rid of any trace of the crash since their transponder goes dark.
@SnoWFLakE0s This guide doesn't have that included because.......... I don't have the FT knowledge and hadn't gotten around to even looking at the code on that 1-Part Hud, to probe how it gets things done! lol (thanks for reminding me!)
.
As for having it hosted on your FT Guide site, that would be great! I'm sure everyone would greatly appreciate it in a static spot as well. :)
Which, secretly, that was what I was using my "Change Log" comments for... to keep the thread periodically bumped :}
Hmmm I probably should've tried the thing before I posted. heh
Applying that
densityvariable to a Wing does NOT stick. It was probably removed from the game long ago and is a latent setting they forgot to remove.@CovenantSlayer It's the same folder that our Planes get saved to.
If you're on PC, copy and paste this into a folder's "address box", or after opening Start Menu:
%USERPROFILE%\AppData\LocalLow\Jundroo\SimplePlanes
.
Mac/Linux I dunno, but it's wherever you install Mods to; Mobile, you're on you own lol.
.
Unfortunately, as I found out, we CANNOT modify it *sigh*
Or if we can it'll take doing something additional (I don't want ot make it Read-Only, but I will if I have to), but I went through the trouble of adding a whole bunch of "custom" parts to make my life easier, having pre-set XML options, but they didn't take because the file gets reset each game start. :(
.
There weren't any other juicy bits in there unfortunately. No disable (hidden) parts, or the like. heh
But if you do take a look and also happen to notice it, I think the
Studiorelated stuff are referring to the image of the Part in the Parts Catalog inside the Designer. (I think internally, the designer is called or referred to as the Studio.)The Unique Characters, as requested to be posted (which show up mostly as a ? in my main post). Note: Most of the Zero-Width characters do not seem to display here, at least in my browser they aren't.
EDIT: @AndrewGarrison Not sure if this is a known Website Bug, but the above characters when posted in the main body, do not display; However, as you can see, they do just fine down here in the comments for some reason. (I'm out of my element here, but my suspicion would be main posts are encoded as ANSI, whereas comments are UTF-8/Unicode?)
Just realized I also had forgotten to link to my Resource post in the description... oops.
I'll put it here, too:
Rich Text Code resources
@Bellcat I don't think the website supports them... :\ At least, when I've tried in the past they haven't worked. (With the new site features they've added in the last couple weeks, it's possible things have changed...)
Albeit, while the Delta character, comically, does work, for example the 4 thin Up, Down, Left, Right arrows do not.
I'll gladly paste them below this sentence, but I am not expecting anything to show up... At least, they don't for ME (if they do for you, let me know):
▀ ▄ █ ▌ ▐ ▓ ▒ ░ ■ ▬
▲►▼◄← ↑ → ↓ ‹ › »
◊ ○ ◌ ● ◘ ◙ ◦ • ∙ ˑ
☺☻ ☼ ♀ ♂ ♪ ♫
♠ ♣ ♥ ♦ ™ ® ¼ ½ ¾
 Ⱡ ⱡ Ɫ Ᵽ Ɽ ₤ ₫ € ⱷ þ Þ Ø ø
⁞
⁄ ⸗ ꜗ ꜘ ꜙ ᷀ ᷂ ᷃ ᷊
ˈ ‘ ’ ‚ ‛ “ ” „ ‟ ′ ″ ‴ … ‰ ‼ ÷ ±
ᶠ ᶥ ⁿ ₐ ₑ ₒ ₓ ₔ ° ² ³ º † ‡
‖ ‗ − ‒ – — ― ¯ ‾ ˉ
Δ Greek 'Delta'
As I recall, they display when pasting them, but once I hit Submit they vanish. Though, there's a whole row of stuff that it seems even my browser's font lacks heh (The first row of the "Zero-Width Combining Characters", but could be that it's due to the nature of the character that they aren't displaying here.)
.
EDIT: Well, color me totally surprise, they did show up :)
Either way, the entire objective of this as an Uploaded Part, was for people to download it and drag the Label over the Sub Assembly button (that displays while dragging stuff) and then create their own part.
Once on a build where you wanted to utilize the characters, you'd place the Label I made, then Edit it to copy out the text needed. As it's WAY faster than having to switch screens to your browser to copy the characters.
(I'm on PC and that's still how I do it, keep it in the background of my build! lol)
November 29th Changelog:
- Added the "Font Asset Names", which lists the in-game font name to the internal "font asset" name for TextMesh Pro. (Useless info at the moment)
- Uploaded a Label containing all the thus-far supported Unique Characters I've accumulated. I decided to do this so that Mobile users can download that make it into a Sub-Assembly, then copy-paste from it.
---- REQUEST: If any mobile users happen to use their keyboards to type in the various extended characters they have access to and find something not included, please share. Note: I only included obscure or symmetrical characters that could be used to stylize builds or interfaces. The "A" I included was for it's symmetrical element, but tried to stay away from non-English languages as to not offend anyone; the others in that row are Currency symbols. Thanks!
lol
+1#TASMasterRace
amirite, @Griffon1? :P
Aaannd stumble across ANOTHER one, this time coming out of the DesignerParts.xml...
On the "Vertical Stabilizer" and "Horizontal Stabilizer", in their
Wingcategory, resides this curiosity:density="5.6"
The Primary, Structural Wing, and Structural Panel all lack it. That would make me think they're using a default value; however, if a part uses a default value that means it does not save it to the plane's XML file.... meaning that this
densityshould show up in them (or through Override)..
At any rate, Googled "what is wing density" and:
(I had to fudge the formatting a bit since the forums doesn't support Subscript, but originally it was "VolWing" and Wing was subscript.)
From this journal/paper via Cambridge.org: "On the wing density and the inflation factor of aircraft"
.
Unfortunately that's way out of my league... but, it sounds like POSSIBLY changing it can (if it's still supported in the game) could effect the "Wing Loading" value. And/Or impact the amount of Wing Flex exhibited in
Wing-1(unused part) andWing-3parts?? (as aWing-2part doesn't exhibit any flexing)@Gestour I thought, technically speaking, someone recently (maybe Kenneth) had figured out that they could still release them for Android by using older tools?
I seem to recall reading that in the comments on one of that person's mod's page.
.
Granted, this was during v1.10, and the switch to a newer built of Unity might've rendered their method unworkable...
@hpgbproductions YAY
Am many exite!
Now to wait patiently :D
That is, until you start to fly REALLY high, at which point you enter into another industry, all of which uses Metric... Even NASA. lol
I'm 'Murican though, so it's MPH, Feet, and degrees Farfignugen. I have noticed that Knots are preeeetty close to MPH, thanks to the Gauges, but it's a large enough discrepancy up around 240MPH that it's around 220Knots; not so bad really.
@ReturnOfJeffChandler Mmm You could start here maybe?? lol
+2But hard to trust the info there, because of how incorrect that top value provided is. That was only true (IMO at least) until the very early 2000s, before someone thew a hissyfit over the fact the fries were cooked in the same grease as some meat (and had some beef fat too I think, for flavor). For crying out loud, if you're going to an unhealthy-as-hell place such as McD's, your opinion on how they make their fries should be completely invalid! hahaha But nope, had to ruin it for the rest of us... *sobs*