Couple new mods brewing; features requirements

[chuck_starchaser]

Ryder is working on his mod, and I'm working on mine. Both pretty similar in many ways, seems to me; except I want mine ultra-realistic, so a merger isn't likely, but cooperation is. His mod will have a small number of systems, and FTL, afaik, for example; whereas my mod will be FTL-less, and only feature two systems because of the (not too) unusual setting of two stars passing each other uncomfortably close.

Anyways, I'm taking the liberty to reprint here part of an email I just got from Ryder, because a) I don't have the answers, and b) because the features of his inquiry are features my mod will need, just as well.

They relate to modules out of which space stations will be built. For background, what Ryder first thought of is creating a set of connectable modules out of which space-stations can be assembled. This way, we could have virtually infinite variety in space stations by reusing the same basic modules in different ways. Here's the email text:

One thing I was thinking of- and maybe you could help me on this since
you have more of a handle on the whole coding thing- was setting up a
relation between the mod-station's physical design and its game
properties- so that, say, each storage unit the displayed model has
translates to fifty or a hundred units of cargo that the station can
hold, where maybe there's different storage unit types linked to
different general categories of cargo (i.e. pressurized structures for
biomatter, big tanks for fuels and liquids, etc.), that having a "bar"
module or a "shipyard" module determines whether one can access a bar or
shipyard when docked to that station, etc., that ultimately if mining
and exploration and all get implemented certain stations will have
specialized modules necessary for such specialized activities.

Ideally, ultimately I'd like to have a setup where not only does the
station's visual appearance and layout tell you a lot about its internal
composition and traits, but where environmental factors come into play;
where stations might slowly add on modules and get bigger the longer
that system is at peace and occupied by the same faction and the closer
it is to the factional homeworld, and where the kinds of modules
incorporating the station varies depending on what the environment of
that particular system calls for most- a lot of defense pods for a
system under regular raids, a station that stocks mostly raw materials
when most of the nearby worlds are mining-centric barren planets, etc.

Should give the stations a more 'real' feel as well as futher improving
the sense of variety the whole modular station thing is supposed to
introduce. What do you think, too farfetched?

Not farfetched at all, I say:

Modules, I believe, would be sub-units; but they'd lack some properties of general units, and have some unique ones. A bit of polymorphism to deal with...
So, for example, a clinic/first-aid module has "storage volume?" which, to the extent that it is filled with respirators, surgical tables and whatnot, it rises in healing potential; not that you cannot store llamas in it, but llamas won't increase its healing potential.

One feature we'd need for this is a way to script unit types on a per system or per-gravitational well region, to avoid having a 50 megabyte units.csv, which can call for sub-units (modules) from a master units.csv. This local .csv should be run-time writable, so that modules could be added, moved, removed, damaged, destroyed, fixed, filled, emptied or repainted during the timespan of the game

Another feature it would need is integration of functional behavior in a unit (space station) of the services and outputs and capacities of sub-units. So, like in Ryder's example, if a station has a bar module, you can find a way to it; otherwise you don't. To dock to it, it must have a docking subunit with hatch type compatible with the docking hatches of your ship; otherwise you need to pull a connecting tube kind of docking. AI and economics should also be sub-unit aware.

Another feature needed is integrating inheritance in physics: A space station's mass and moment of inertia should be the sum of the masses and a three axis integration of the masses of sub-units, and change whenever a new subunit is added, or an old one removed, respectively.

I thought of posting this to Features Requests; but I'm not sure whether that forum is for engine feature requests, or VS mod features requests.
Just to clarify, at least speaking for myself, I'm putting these features requests here as a safe place in which to store them; no immediate need, and probably I'll let the features accumulate and then put them all together into a full specification, rather than suggest a piece-meal approach. IOW, food for thought, for now.

[klauss]

There is a way in which you could achieve almost all you say... and possibly more.

The new Model specification I'm working on is modular as well. I'm working on attaching some modular physics properties as well, out of need, because a model's physics is directly tied to its shape and "graphical" appearance. So, the model spec will include both graphic, graphic behavioral, physics and physics behavioral properties.

Among them are a few you mentioned:

• Graphic: the models themselves, in a variety of formats, might I add: each module may be a mesh, sprite or particle system.
• Graphic behavioral: each module may be automatically tied to AI/physics properties. For instance, engine exhaust meshes will be tied to accel/velocity/torque.
• Physics: mass of each module, and perhaps some similar properties as well. Basically, you'll be able to have "weak" modules (as in solar sails) that you can detach by simple collision, and strong modules (as structural modules) that well... should you collide, it won't be pretty. This is needed on a per-module basis both because it's neat, but also because I intend to make possible runtime splitting of models in two (for instance, when you blow up a "fuse" - a kind of structural module that joints parts of the model together). Of course, before this realizes its full potential, a lot of physics-side work must be done... so don't expect this in the short term.
• Physics behavioral: fuses, mainly. Certain modules will have certain physical behavior properties, as being structural ties between hierarchical groups, or things like that. I'm actually now thinking of a graph-like structure (yesterday, it was a tree-like structure... but graphs aren't much harder, and are indeed much more general). Another example is "rigid links" as oposed to "articulated links"... rigid links link together the masses and inertia of connected modules, while articulated links break this kind of linkage in some way.

Of course... the model won't enforce the sum/integral of masses to be the mass of a unit, although physics behavior would be really odd if it wasn't the case. But models can easily be constructed so that it is the case.

All this I had been working on already (thinking). The simple solution to your problem, IMO, is just exposing all this interface to Python.
That way, you can (not so easily) write python modules to dynamically create units, and put them in the local units.csv. Another interface for reloading units.csv (or adding rows) would be handy.
Notice that you don't have to modify the engine (further from adding the new model specifications) to do that - python can handle the manufacture of custom unit.csv rows.

[chuck_starchaser]

Allright, looks like I'll have to learn Python pretty soon.
That framework sounds great!