|
|
Post by AtomHeartDragon on Aug 16, 2018 17:43:39 GMT
The main problem with user created content for CoADE is that everything resides in a shared namespace like a one, big, incestuous, deeply dysfunctional family. This means that everything, be it a workshop file or a manually imported one, will happily override everything else if it has the same name - and names are auto-generated.
This also means that maintaining any sort of reasonably sized mod collection in working order is an impossible task, because the game doesn't provide any tools for determining what was overwritten by what and is actually one of the main reasons why I stick to stock modules most of the time.
Until the single namespace issue gets sorted out, the only way out is manually naming components in such way that they don't conflict with anything else. This can be achieved by either: - Agreeing on an unambiguous naming scheme detailing all critical parameters of a component in such way that identically named component is actually going to be physically identical (good luck with that!)
- Coming up with a unique signature on workshop, collection or individual ship level and adding it to all component names.
Please, do that, I'm tired of trying to sort out all manners of broken stuff (and rummaging around steam's oh-so-helpfully-named directories with grep, then trying to fix stuff by hand only takes you so far before you start fantasizing about murdering people horribly).
Also, do list dependencies for your blueprints, and try to abstain from using diamond for high temperature applications - I would love to see a day when I won't have to choose between breaking half of my downloaded designs with Community Materials Pack, and not being able to use the other half relying on it.
Seriously, at least until CoADE starts doing it for you, do your housekeeping!
|
|
|
|
Post by bigbombr on Aug 16, 2018 18:58:56 GMT
- Agreeing on an unambiguous naming scheme detailing all critical parameters of a component in such way that identically named component is actually going to be physically identical (good luck with that!)
- Coming up with a unique signature on workshop, collection or individual ship level and adding it to all component names.
This illustrates how I name my modules. For drives/engines, it is [exhaust velocity] [thrust] [propellant] [engine type]. Engine type is either CR (combustion rocket), RJ (resistojet), NTR (nuclear thermal rocket) or MPDT (magnetoplasmadynamic thruster). -G gets added for gimballed engines. In combustion rockets, it's [oxidiser]/[fuel] in the place of [propellant]. This illustrates how I name propellant tanks. [mass] [propellant] (Drop) Tank. Conventional cannons are named [muzzle velocity] [bore diameter] [slug mass] EG. EG means explosive gun. -T gets added for turreted conventional guns, -ET for extruded guns and -I for internal guns. If turreted, armor gets added at the end like this [thickness in mm] [abreviation for armor material, typically AmCa for amorphous carbon] Railguns are named [power required] [muzzle velocity] [bore diameter] [slug mass] RG with the same rules for turrets as conventional cannons. Coilguns are named the same way as railguns, except RG is replaced by CG. Lasers are named like this: [output power]/[input power] [wavelength] [aperture diameter in mm] L. Same turret rules apply. Carrier modules are named: [input power] [reload time] [payload] [armor thickness in mm] [abreviation for armor]. Blast launcher are named like this: 
The distinction between VLS and Blaster is that VLS is for launching something at low velocities (both often in large volume) while Blasters eject their payload at higher velocity.
Munition modules are called like this: [number of rounds]rds[number of layers] [weapon name]. Except for carrier modules, where it is [number of rounds]x [name payload].
I started marking all my components and ships with _BigBombR in front. |
|
|
|
Post by apophys on Aug 16, 2018 18:59:21 GMT
I agree, everyone should tag all their stuff with some identifier, like I do using [AE] in front. Granted, I'm probably going to have to replace the square brackets due to the recent update, which will break anything currently using my stuff (thanks qswitched...), but the system is generally a good one.
The community modpack really shouldn't be replacing stock diamond with temp-fixed diamond; it should add the fixed diamond separately as to avoid breaking things. You can't blame people for not taking the modpack into account when doing their stuff; you should be blaming the modpack for being too aggressive.
|
|
|
|
Post by jtyotjotjipaefvj on Aug 16, 2018 19:50:23 GMT
You don't need tags if you never publish anything.
Although I'm half-tempted to start using a [jtyotJOTJIPAEFVJ] tag.
|
|
|
|
Post by AtomHeartDragon on Aug 16, 2018 22:24:26 GMT
bigbombr Assuming similar base characteristics (like propellant, power, etc.) the most important aspects of component naming are actually physical dimensions and mass. If those match, even if components alias, they will be unlikely to break blueprints using them.
I'm actually planning to build a collection of components matching stock dimensions to form a quick conversion kit - you take a [Core] version of a ship, swap out components, add some bells and whistles such as non-analogous armaments and NTR RCS, and voila, you can roll it out.
apophys I use _DCA prefix followed by 1x whitespace. It's nice to be able to use CoADE's subscript/superscript capability and it's relatively nonintrusive as the prefix is clearly separated visually.
|
|
|
|
Post by AdmiralObvious on Aug 17, 2018 0:23:52 GMT
I've learned to avoid anything that could represent a file structure in basically any workshop item I've over made. So you aren't allowed to use most symbols most of the time.
As I mentioned before, if it were possible for files to tie in steam ID to the modded item, it'd probably help alleviate some of the issues with duplicate items. I don't see why items aren't allowed to share the same name, assuming the mod author is differentiated.
We got a split for core/mod/self items, now I think one more fix would be able to split the mod folder by author.
|
|
|
|
Post by AtomHeartDragon on Aug 17, 2018 0:29:10 GMT
I've learned to avoid anything that could represent a file structure in basically any workshop item I've over made. So you aren't allowed to use most symbols most of the time. As I mentioned before, if it were possible for files to tie in steam ID to the modded item, it'd probably help alleviate some of the issues with duplicate items. I don't see why items aren't allowed to share the same name, assuming the mod author is differentiated. We got a split for core/mod/self items, now I think one more fix would be able to split the mod folder by author. That *should* be how it worked, but it isn't.
Since we have to work with what we have, not with what we should have, I propose prefixing stuff with underscore and some short alphanumeric identifier - both should be safe to use.
|
|
|
|
Post by doctorsquared on Aug 17, 2018 1:24:59 GMT
My Nomenclature Guidelines: Manufacturer:
- Ships: Squaeronautics [SQ]
- Engines/Tankage/Command: SquareOne [SquareOne]
- Weapons: SquareCo [SquareCo]
Weapons:
- Conventional: [Bore Size] ChemCannon-[Ammunition Type]
- Electromagnetic: [Energy Consumption] CoilCannon/RailCannon-[Ammunition Type]
- Missile: PicoMissile/MicroMissile/MacroMissile-[Ammunition Type]-[Range]
- Laser: [Energy Consumption] Laser-[Emission Wavelength]
Weapons Suffixes:
- -K = Kinetic
- -F = Flak
- -N = Nuclear
Ex: A 250 MW flak railgun would be a [SquareCo] 250 MW RailCannon-F
Might need refinement to deal with multiple weapons that have similar power consumptions and payloads. |
|
|
|
Post by The Astronomer on Aug 17, 2018 12:20:56 GMT
I guess if ever join the part sharing community, mine would be just '[AS]', for Astronomer Starmaker. My naming scheme is quite unique anyways.
|
|
|
|
Post by anotherfirefox on Aug 18, 2018 0:03:37 GMT
I agree, everyone should tag all their stuff with some identifier, like I do using [AE] in front. Granted, I'm probably going to have to replace the square brackets due to the recent update, which will break anything currently using my stuff (thanks qswitched...), but the system is generally a good one. The community modpack really shouldn't be replacing stock diamond with temp-fixed diamond; it should add the fixed diamond separately as to avoid breaking things. You can't blame people for not taking the modpack into account when doing their stuff; you should be blaming the modpack for being too aggressive. How could this be aggressive? It's the matter of choice that would you stick with stock for compatibility or go for stinky reality. I choosed latter, totally happy with borked stocks(have no value if it wasn't correct), would be unhappy if I have to see brokeunrealisticstockmaterial still alive in ingame. |
|
|
|
Post by treptoplax on Aug 18, 2018 20:33:17 GMT
I've learned to avoid anything that could represent a file structure in basically any workshop item I've over made. So you aren't allowed to use most symbols most of the time. As I mentioned before, if it were possible for files to tie in steam ID to the modded item, it'd probably help alleviate some of the issues with duplicate items. I don't see why items aren't allowed to share the same name, assuming the mod author is differentiated. We got a split for core/mod/self items, now I think one more fix would be able to split the mod folder by author. Really all we need is for the engine to separate part names into a human-readable label and a unique ID (I'd suggest just a md5 hash of the design itself, but it hardly matters what it is as long as it's sure to be unique in practice). Until then prefixes are likely the best we can do. They could be added to exports with some (trickier than it should be) scripting but it's a real nusciance for workshop designs. |
|
|
|
Post by AtomHeartDragon on Aug 18, 2018 23:42:24 GMT
I've learned to avoid anything that could represent a file structure in basically any workshop item I've over made. So you aren't allowed to use most symbols most of the time. As I mentioned before, if it were possible for files to tie in steam ID to the modded item, it'd probably help alleviate some of the issues with duplicate items. I don't see why items aren't allowed to share the same name, assuming the mod author is differentiated. We got a split for core/mod/self items, now I think one more fix would be able to split the mod folder by author. Really all we need is for the engine to separate part names into a human-readable label and a unique ID (I'd suggest just a md5 hash of the design itself, but it hardly matters what it is as long as it's sure to be unique in practice). Until then prefixes are likely the best we can do. They could be added to exports with some (trickier than it should be) scripting but it's a real nusciance for workshop designs. I would rather use a combination of human readable label and mod/workshop user ID as unique ID. Hashes do collide sometimes. |
|
|
|
Post by The Astronomer on Aug 19, 2018 2:50:37 GMT
Apophys Electrics, heh. I can still remember my Prosperous Project. Lots of company names in there. If people start signing their stuff I think I might set up a thread that lists people's signatures and maybe their fictional companies' details, if available.
|
|
|
|
Post by treptoplax on Aug 19, 2018 12:46:54 GMT
Really all we need is for the engine to separate part names into a human-readable label and a unique ID (I'd suggest just a md5 hash of the design itself, but it hardly matters what it is as long as it's sure to be unique in practice). Until then prefixes are likely the best we can do. They could be added to exports with some (trickier than it should be) scripting but it's a real nusciance for workshop designs. I would rather use a combination of human readable label and mod/workshop user ID as unique ID. Hashes do collide sometimes. Technically, but not really. The nice thing about hashing is that no central coordinator is needed. In practice assigned ID systems are far more likely to produce duplicates due to some glitch or bug than the infinitesimal chance of an accidental hash collision - no sha256 collision has ever been found, and the odds of CoaDE randomly hitting one are less than the odds that you, I, and qswitched are all struck by independent meteorites tomorrow. This is arguing about what color frosting to put on a cake we don't have, of course.  |
|
|
|
Post by AtomHeartDragon on Aug 19, 2018 14:27:17 GMT
I would rather use a combination of human readable label and mod/workshop user ID as unique ID. Hashes do collide sometimes. Technically, but not really. The nice thing about hashing is that no central coordinator is needed. But we do have central coordinator - workshop authors have unique IDs, so do individual workshop mods. When importing locally, source files are also uniquely identified.
If we're stuck with Steam (and we seem to be, not that I'd complain if CoADE appeared on GOG), let's make the best of it.
|
|
