For some examples.

This is incorrect, all packs have moved to centering their crates at the bottom of the model.

Last I heard there was talk about changing how outboard boat motors are centered, and as such if that standard has change, it should be reflected in the immediately-visible wiki PDF.

This should be updated to reflect wheel parts themselves having rolling animations, be it done through animatedObjects rotations or a movementAnimation.


Neither of these pages go into depth as to how standard run-of-the-mill seats should ideally be centered.
This wouldn't be worth pointing out except that RoTM engines and wheels themselves have such definitions for when they aren't a special aircraft wheel, or wankel rotary engine.
Additionally, speaking of engines... We'll revisit the screenshot of the boat engine page, as that is left blank safe for this entry.
If the convention should go out of its way to define the difference between a "passenger aircraft" seat and a "pilot aircraft" seat, it ought to define the different between all standard variants of engines engine_x, engine_horizontal, engine_radial, etc. and electric motors. At minimum, an entry on automotive electric motors would fit in this blank space as its the most likely usecase of electric motors in MTS, and all pack authors have had more than long enough to decide on how these motors should be mounted.

(In my case, I've chosen to ignore part types entirely by defaulting to engine_car, as well as centering them mostly-similar to standard vee/inline engines. Until I see a mass adoption of engine_car_electric or a sufficing part type I will continue to use engine_car, and the only other electric model(s) I have seen so far center their models in the same manner.)

This PDF needs to be updated as new up-and-coming pack authors will be subject to an outdated convention definition, and Discord's message search function is never reliable enough to substitute for a .pdf file.

P.S for said newer pack authors, until (or dare I say, if ever) the part conventions .pdf is updated, remember that it's always ethical to crack open a cold .jar file of whichever pack you're piggybacking off of. If anything, I would encourage it at this point as it would be interesting to see what new innovations come about a shared pack-making environment rather than the current path I've seen so far, which seems to be "Every man for himself! Don't look at MY json! And if you do, you gotta make it exactly like mine! I won't compromise!"
This is a poor example for new pack authors, and may possibly result in more shovelware.

@DrprofLuigi gets pinged for this.

TBH, I don't know why the convention doesn't go wild with VMs at this point. You can assign custom animation variables that vehicles and other parts alike can pick up on. For example, my own engines with their engine_clutching variable, which sorta just combines both clutch_shiftup and clutch_shiftdown. However, my vehicles and Trin's also happen to use such variables to disable their throttle while the engine shifts. Not as realistic as rev matching but hey, it'll still make turbos do the stustustu, and it's great for emergency shifting!

Think of all the animations the convention could designate, the possibilities are literally endless! Or maybe it's worth more time to have windows you can roll down. 😜

The newest version of the convention handbook is available on the convention discord: https://discord.gg/SkzqcRfNEZ

Think of all the animations the convention could designate, the possibilities are literally endless!

VMs certainly can enhance a pack, but that goes beyond the scope of a basic parts pack convention, which is strictly focused on part placement, rather than performance (otherwise engine power would need to be regulated as well). Given that there can barely be consensus on how to center a wheel, I doubt larger cooperation is even possible.

A good example of this would be the V6 features coming to UNU. Wheels are sub-assemblies where the tires can be swapped around, but they are still consistent with the convention as a whole. Same with UNU engines that have the option to work with transmissions. However, they still comply with the convention since it is an option that must be enabled.

For future reference, the parts pack convention is externally managed, and is not part of MTS per se. So the proper place to suggest changes would be the discord linked above.

I updated the convention wiki link to go to the discord, that way the most up-to-date document can be accessed directly.

As long as the discord precisely covers how parts should be aligned, all good. 👍

P.S: Having tried the beta that does this, unnecessarily complicated IMO. At minimum, use those new lockingVariables or something to keep 'em from coming off when trying to remove a wheel. Like the idea however, and it'd probably work even better if the tire part itself deleted itself once popped, as there's also an option for that somewhere IIRC.

Link needs to be updated at the following locations.

https://github.com/DonBruce64/MinecraftTransportSimulator/wiki/Pack-Making-General-Conventions
https://github.com/DonBruce64/MinecraftTransportSimulator/wiki/Pack-Making-JSON-Parts
https://github.com/DonBruce64/MinecraftTransportSimulator/wiki/Pack-Making-JSON-Connections
https://github.com/DonBruce64/MinecraftTransportSimulator/wiki/Pack-Making-Models-Model-Requirements

https://images-ext-1.discordapp.net/external/DtBYkXWIQvMNW2D3wW0iCQk8hk57MHAy6UpxGjqTZss/%3Fsize%3D48/https/cdn.discordapp.com/emojis/818445586856017960.webp

See now, this trying to start shit by posting trollface emojis with someone youse got a beef with.... I don't have words, just disappointment. I though we were over this.

Closing this issue, as I doubt anything is going to happen with the conventions tab. I think we should just make the conventions stated in the wiki in the modeling section, which isn't external on a random Discord that's not linked in any documentation on Git nor the main Discord.