Action-based data format expansion idea #9025
Comments
tibetiroka
changed the title
|
Great idea! I especially like the values based on other variables idea, the action checker ( |
Hecter94
added
enhancement
|
So I've been working on a proof-of-concept implementation for this, and with some tweaking, I got this list of attributes/tokens that could (hopefully) be supported in a simple manner: listshields These are the old-style, flattened names, generated from the action-effect model, and they should be compatible with all existing attributes that fit in this model. Also, that's nearly 1200 attributes. |
Problem Description
Why is there no
cloaking discharge?shield ion?thrusting cooling?We have a whole lot of mechanics that move ships, fire weapons, collect fuel. And we also have another set of mechanics that apply buffs/debuffs when the first set of mechanics is used. But, for whatever reason, most of these don't work together.
Why? Is it because every single one has to be parsed and checked individually in the engine? There is a solution for that.
Related Issue Links
#6321 and its linked issues definitely come to mind.
My solution tackles the problem generally, both in terms of engine and data format support.
Desired Solution
With some tweaking in the data parser, we could add a new way to define the effects of an action.
Let's take an engine as an example. This is how it would be defined with the current format:
This could be redefined like:
(We could also use something like
energy -= 2.2. Also, we might want to add support for more complex expressions in the future, such as allowing mass-based energy consumption for thrusters, in which case, that might look better ("energy" -= 0.01 * mass).)As can be seen here, this new format can be mapped one-to-one to the old format, and also the other way around. Why do we need it, then?
Because this avoids defining new keywords. There is no longer a special "thrusting heat", "thrusting scramble", "cloaking heat", "cloaking scramble" etc., only "thrust", "cloak", "heat", "scramble".
In the engine, instead of having to check for all thrusting attributes independently, we can essentially just pass the map of attributes through all outfits that modify it. (Okay, it's a bit more complicated, especially with multipliers.) We can keep all current precalculation-based optimizations as well.
This would, in theory, make it pretty much trivial to add support for every effect on every action. Cloak could generate slowing, generators could create ion, active cooling could cause leakage, whatever you want.
Of course, we still need to somehow display these new attributes in the UI. However, most of the display names can be generated and, since they are no longer data format keywords, we can change them at any point without having to worry about broken data files and compatibility issues.
Alternative Approaches
In theory, anything that the new format can do can also be done in the current one, it just requires a lot more work and maintenance.
There are also many ways to define extensions like the one I suggested. Take this, for example:
Or this:
Additional Context
No response
The text was updated successfully, but these errors were encountered: