Page 2 of 2

Re: Attack on Trinity: Expanding weapons size classes

Posted: Wed May 19, 2010 12:42 am
by klauss
Ok, you have your CSV with your hex numbers.

Now I want to add another energy type. X.

For some reason (say, in order to not require reimplementation of a lot of stuff - believe me, this happens a lot with bitfields, say I converted the bits into an index into an array to fetch something that depends on the exact combination of bits), the bit has to be stored in a specific place: next to the other type bits.

Ie: if I have <size class bits><type><capapbilities>, then X has to be right next to type: <size class bits><type>X<capapbilities>

What would you need to do in order to just add the possibility of such a gun type without modifying any behavior in the game?

Hint: you'd have to modify the CSV at least.

If you attempt to add X where it doesn't require CSV modifications, our previous assumption means we have to modify the rest of the engine to account for the new bit locations. Macros or careful interface design can do this painless, but you should begin to see the problem of tying in-memory representation with persistent representation.

Take a look at the "tractorability" flags in the units.csv: there's a more flexible approach, which is readable (provided some documentation - which is lacking of course - it's VS), and not hard at all to maintain.

"tractorability" takes the road of "flags are flags". You type a series of characters, and each character turns on a specific flag. Simple to decode. Simple to read. Dissociated from internal representation. Adding a flags is easy: just adjust the units.csv parsing code to ADD the mapping to the switch that loads the unit at load time - at load time, ie, not all the time, so performance isn't critical.

In fact, if you ever want to refactor the internal representation, you can always code translation procedures in the code that loads that flags representation.

In essence, any change needed to the flags takes as much work to implement as it needs - no more. There's no massive unbounded amount of changes involved. If you tie the CSV to the internal representation, there might.

Add to the fact that changes in code aren't monitored by dataset authors (modders) as closely as to realize the need to adjust the CSV (or perform the change promptly). It's a worthwhile pursuit in the pursuit of maintainability that programmers should be able to affect as many implementation changes as possible without requiring extra work from dataset maintainers, because the teams are separate and communication is costly.

Re: Attack on Trinity: Expanding weapons size classes

Posted: Wed May 19, 2010 2:41 am
by Neskiairti
I'm not sure if this exactly responds to what you're saying (having trouble following) but..

you would probably want the units.csv to be broken in to two files:
objects.csv
keys.csv

keys would be where you define what each value is within the base mechanics allowed.. such as
category,weapon,bool(BEAM) ,string(WEAPONNAME),list(DAMAGE)
category,ship,bool(SHIELDS), string(SHIPNAME), string(SHIPDESCRIPTION)
category,debris
inheritance,space_objects,ships->debris

while objects would be the ships and objects themselves
debris,SHIPNAME("cargo pod"),!SHIELDS
weapon,WEAPONNAME("Immachargin"),BEAM,DAMAGE(energy,200,500)

you get the idea :p that would also free up the worry about misstyping the units file.. it would throw an error right away saying you were missing a value.. when you tried to optimize it. and things dont need to be in a specific order really.. everything says on the cover what it is.. (mostly)

Re: Attack on Trinity: Expanding weapons size classes

Posted: Thu Aug 12, 2010 8:47 am
by TBeholder
klauss wrote:Reasons to NOT optimize: ease of maintainance.
That's ALWAYS the reason not to optimize.
If not optimizing doesn't ease maintainance, then it's not worth not optimizing.
(nice word puzzle ;) )
Of course, you're wrong. "ease of maintainance" is a part of optimization criteria. :wink:

I don't see why "plain text tags" vs "binary" is seen as a big dilemma here. Want flexibility, don't want lug extra data around cache and spill it all over CPU cache? Use a laughably simple and straightforward way, auto-enumeration.
Read in a current item-to-load (slots list) text tags, check them with tag dictionary array, add if necessary. Then you'll end up with anything ever used anywhere that was loaded present in the tag list once, and each slot instance stored internally is just a string - (N_elements_in_list)[tag_index_1][tag_index_2]...[tag_index_N] - and if you'll discover 255 isn't enough, you just change declarations of two data structures and variables used to cycle through them, and it's not visible for ruleset in any way except "300 tags ruleset works".
The beauty is that it's universal and can pull not just weapons', but uni-slots this way, but if you need to use some special tags in the engine (AUTOTRACKING), you can just pre-add them internally and use their known indexes (until you get rid of them), and ruleset still haven't know what's going on except that some known tags have special effects.

Re: Attack on Trinity: Expanding weapons size classes

Posted: Thu Aug 12, 2010 3:36 pm
by klauss
@Turbo Beholder: yep, I had already proposed something like that. We were discussing engine internals, not necessarily file formats.

There's no need to pollute units.csv (or whatever units database) with internals, as I was saying earlier in the thread.

Re: Attack on Trinity: Expanding weapons size classes

Posted: Tue May 21, 2013 8:29 pm
by TBeholder
Engine internals should look forward to what they may implement, no?
Anyway, what fields an unified "slot" needs?
  • tag list (whether separated text or flag set) for and suchlike. "Light weapon"/"Heavy weapon" or "PD turret"/"huge capship turret" and suchlike ruleset-level distinctions go here.
  • type - general type of what can be attached, for hardcoded handling and AI purpose. Weapon/missile/thruster/sensor/radiator/hull part/dock/turret/decoration... - this can be done via hardcoded tags, though.
  • xyz (vector) - position on the ship
  • P, Q (vector) - orientation of the installed item
  • cone - limit for turning turrets, sensors, autotracking weapons, vector thrust
  • installed_itrem - what was put into the slot, if any. The model, repair screen pictogram (as in WC), weapon properties, etc are up to the installed item.
  • number - for simple installed items bundled together (e.g. ammo)
  • volume - restriction on the installed item's volume.
  • linked (bool? pointer?) - more than one slot is bundled together. E.g.: banked weapons; but may be used for setups like "scanner + lock" radar or "weapon + capacitor + magazine (choose your ammo)" hardpoint.
  • functionality
  • functionality_max
  • functionality_set - for thrusters, shields set to 1/2 power, etc.
  • status - off/active/waiting/turretAI state/...
  • status_timer - time limit of the next status switch (e.g. stability/refire for mounts)

Re: Attack on Trinity: Expanding weapons size classes

Posted: Tue May 21, 2013 9:01 pm
by klauss
TBeholder wrote: tag list (whether separated text or flag set) for and suchlike. "Light weapon"/"Heavy weapon" or "PD turret"/"huge capship turret" and suchlike ruleset-level distinctions go here.
I think the "flexible tags" thing could work if the tag list is fleshed out in the .config. Otherwise, having auto-enumeration as mentioned before could lead to savegame compatibility issues (just OTOMH). Anyway, it could work, but not without some extensive refactoring, removing all the current hardcoded behavior related to tags.
TBeholder wrote:type - general type of what can be attached, for hardcoded handling and AI purpose. Weapon/missile/thruster/sensor/radiator/hull part/dock/turret/decoration... - this can be done via hardcoded tags, though.
If you're going with flexible tags, I'd remove this. Make each weapon require a set of tags, and you can encode type information in tags.
TBeholder wrote:cone - limit for turning turrets, sensors, autotracking weapons, vector thrust
Must be an anisometric cone. Different limits in both P and Q, think of a 2 DoF joint.
TBeholder wrote: [*] functionality
[*] functionality_max
[*] functionality_set - for thrusters, shields set to 1/2 power, etc.
Lets expand here. What about overheating, jamming, catastrophic failures?
This is halfway between internal engine state and serializable mount description. It's state, but that must be persisted. Grey area.
TBeholder wrote:[*] status - off/active/waiting/turretAI state/...
[*] status_timer - time limit of the next status switch (e.g. stability/refire for mounts)
But this is purely internal state.

Re: Attack on Trinity: Expanding weapons size classes

Posted: Wed May 22, 2013 7:32 am
by TBeholder
klauss wrote:
TBeholder wrote: tag list (whether separated text or flag set) for and suchlike. "Light weapon"/"Heavy weapon" or "PD turret"/"huge capship turret" and suchlike ruleset-level distinctions go here.
I think the "flexible tags" thing could work if the tag list is fleshed out in the .config. Otherwise, having auto-enumeration as mentioned before could lead to savegame compatibility issues (just OTOMH). Anyway, it could work, but not without some extensive refactoring, removing all the current hardcoded behavior related to tags.
I don't see how this could lead to any issues other than "save doesn't fit ruleset" the same way as 200 m^3 of equipment put in a bay reduced to 180 m^3.
As to the current hardcoded behaviour, there are two.
Separate "weapon" vs. "missile" lists (display and switch) - this perhaps should stay, under hardcoded type (below).
Alternate locking sound for SPECIAL-MISSILE - a hack made for one specific ruleset. If there's no point to make it a generic option, it can be handled in a simple and already used way: text list filters (like AutoLandingExcludeList, etc).
klauss wrote:
TBeholder wrote:type - general type of what can be attached, for hardcoded handling and AI purpose. Weapon/missile/thruster/sensor/radiator/hull part/dock/turret/decoration... - this can be done via hardcoded tags, though.
If you're going with flexible tags, I'd remove this. Make each weapon require a set of tags, and you can encode type information in tags.
Functional separation on "weapon" vs. "thruster" vs. "generic upgrade" level have to be hardcoded anyway, so why not just make it clear. I added "weapon" vs. "missile" because these typically are 2 sets, separately switched, indicated and handled by AI. May call it otherwise, but in itself it makes sense.
klauss wrote:
TBeholder wrote:cone - limit for turning turrets, sensors, autotracking weapons, vector thrust
Must be an anisometric cone. Different limits in both P and Q, think of a 2 DoF joint.
Or that. Perhaps it would be more transparent to spell it explicitly than to handle 1DoF turrets only via zeroed governor like now.
klauss wrote:Lets expand here. What about overheating, jamming, catastrophic failures?
Most should go into status, just like "reloading..." IMO. Also, maybe there should be status_set too - e.g. a mount can be triggered/not triggered/not enabled, thrusters may be on/off/afterburn, ECM on/off, radars on/passive mode only, shields auto-disabled (SPEC) - which is not quite the same as functionality_set?
As to heat and heat capacity, yeah, we'd have to count separately for everything that matters - once it's handled at all, that is.
klauss wrote:This is halfway between internal engine state and serializable mount description. It's state, but that must be persisted. Grey area.
It is mostly a list of fields from Mount class, minus the abomination of two scaling multipliers and plus a few obviously necessary fields.
And of course, yes, while this isn't supposed to be in ruleset, it should go into save files.
klauss wrote:
TBeholder wrote:[*] status - off/active/waiting/turretAI state/...
[*] status_timer - time limit of the next status switch (e.g. stability/refire for mounts)
But this is purely internal state.
You said we're discussing internals... :) Anyway, while these normally have no place in a ruleset, they should be save-able.

Re: Attack on Trinity: Expanding weapons size classes

Posted: Wed May 22, 2013 4:55 pm
by klauss
TBeholder wrote: Alternate locking sound for SPECIAL-MISSILE - a hack made for one specific ruleset. If there's no point to make it a generic option, it can be handled in a simple and already used way: text list filters (like AutoLandingExcludeList, etc).
No, no... we should use and expand the new "cockpit event sounds" facility. It's far more flexible, and it can be customized cockpit by cockpit.
TBeholder wrote:
klauss wrote:Lets expand here. What about overheating, jamming, catastrophic failures?
Most should go into status, just like "reloading..." IMO. Also, maybe there should be status_set too - e.g. a mount can be triggered/not triggered/not enabled, thrusters may be on/off/afterburn, ECM on/off, radars on/passive mode only, shields auto-disabled (SPEC) - which is not quite the same as functionality_set?
As to heat and heat capacity, yeah, we'd have to count separately for everything that matters - once it's handled at all, that is.
I was more thinking about the weapons' inherent tendency to become jammed or whatever. Surely, the "currently jammed" things will be internal state.
TBeholder wrote:
klauss wrote:
TBeholder wrote:[*] status - off/active/waiting/turretAI state/...
[*] status_timer - time limit of the next status switch (e.g. stability/refire for mounts)
But this is purely internal state.
You said we're discussing internals... :) Anyway, while these normally have no place in a ruleset, they should be save-able.
Not sure why you'd save them.

Re: Attack on Trinity: Expanding weapons size classes

Posted: Wed May 22, 2013 7:08 pm
by TBeholder
klauss wrote:
TBeholder wrote:Alternate locking sound for SPECIAL-MISSILE - a hack made for one specific ruleset. If there's no point to make it a generic option, it can be handled in a simple and already used way: text list filters (like AutoLandingExcludeList, etc).
No, no... we should use and expand the new "cockpit event sounds" facility. It's far more flexible, and it can be customized cockpit by cockpit.
I'm not saying all this should be put into the global config... :twisted: If capships may get "interceptor launched!" sound, etc, it's cool too.
klauss wrote:
TBeholder wrote: Most should go into status, just like "reloading..." IMO. Also, maybe there should be status_set too - e.g. a mount can be triggered/not triggered/not enabled, thrusters may be on/off/afterburn, ECM on/off, radars on/passive mode only, shields auto-disabled (SPEC) - which is not quite the same as functionality_set?
I was more thinking about the weapons' inherent tendency to become jammed or whatever. Surely, the "currently jammed" things will be internal state.
TBeholder wrote: Anyway, while these normally have no place in a ruleset, they should be save-able.
Not sure why you'd save them.
Because if not, on load jammed weapons will unjam, while near-complete lock and freshly started refire timers will be initialized? Then there are even longer repairs...

Re: Attack on Trinity: Expanding weapons size classes

Posted: Wed May 22, 2013 7:26 pm
by klauss
TBeholder wrote:
Not sure why you'd save them.
Because if not, on load jammed weapons will unjam, while near-complete lock and freshly started refire timers will be initialized? Then there are even longer repairs...
Ok, yeah. And cherry-picking which states to save and which states not to would be more work rather than less.