stationary variationaries

[strangelet]

would it be possible to have a system in VS whereby a station model has a number of nodes, at which a random selection from a set of submodels can be placed.. maybe even a number of sets... they would look like different models of the same line...

this would exponentially increase the variation of stations...

expanding on this idea, why not a complete random station building algorhythm.. a set of core hulls, a set of large modules and a set of small modules...

it's high time we looked forward past the single-model-per-unit convention. with this kind of tool, all ships could have multiple, random "models" ... an extra hull section here, an intake there, an extra fin or two and the data for the generation would only be a few bytes...

this would also lead to greater characterisation of personality vessels for single player missions, and provide a a distinctive sense of evolution to ship design....

another way of implementing this in a more organised fashion might be to have a ship age for eash vessel, corresponding to a pre-generated look-up table of submodel configurations representing different ship "models"

[zaydana]

Thats a great, it erally should be done sometime as it would help a lot with the amount of art that needs to be done and the depth of the universe.

Perhaps another way to do it would be to have many different station 'cores'... which house the main systems (i.e. life support, reactor) and then for each of the upgrades on a station to add a model in a certain place on the core. Combined with having many different models for each of the upgrades, one of which is randomly chosen, and perhaps even having random modules for the upgrades that are just for appearence (like the fins and intakes that you mentioned) this would make an endless variety of stations, and give so much depth to the univverse.

The advantage of doing something like this is that once you have been playing for a while you would be able to look at a station, and altho it would look different to all the rest of the stations with the same stats, it would still have some resembelance to them, and experienced players could ptrobably tell roughly the stats of a station for each new station they see.

A way to do this would be to have different types of station components, and a few different models for each different station type.

i.e. there would be a fair few models for both 'Core Type A' and 'Core Type B'... and then the subunits of a Core would need to specify what type of core they need to be connected to for the model to fit together.

[charlieg]

And whilst your at it, why not extend the concept to fighters and capital ships as well as stations.

I did suggest this a long time ago (on these forums I think) although I think I was a little more radical, but the concept was similar.

[wewewewewe]

Like if player owned station was to happen in multiplayer, it could be possible.

[wewewewewe]

And whilst your at it, why not extend the concept to fighters and capital ships as well as stations.

I did suggest this a long time ago (on these forums I think) although I think I was a little more radical, but the concept was similar.

I don't think you can add anymore meshes to a small object or a capital ship when it comes to add on modules like what a station does.

[charlieg]

I don't think you can add anymore meshes to a small object or a capital ship when it comes to add on modules like what a station does.

Rubbish, of course you can. It's just on a different scale.

[pincushionman]

For smaller ships, it is more a matter of "why would we do it" than "can we do it." Most of the ship concepts I've seen from this community are quite stylized, and in order to look good, we would have to design the ships and parts from the ground up to be interchangeable. Which would severely limit our creativity on small ships.

That's not to say there isn't a place for ships like that -- if you look at the model slated to replace the Ox, you'll notice it is very modular. Once the texture is done, I intend to model up a variety of external cargo pods for it, as well as work on different models for the ship itself -- for instance, different yoke and reactor models for four-, twelve-, and sixteen-pod variants, so there could be a plethora of different Ox ships flying around the universe.

For believability concerns, we would also have to justify it by explaining why manufacturers would build ships in that manner. If you look at most vehicles today, you'll notice that while they may share many parts on the inside, the outside is generally specific to that vehicle model. That's because structural joints == bad; they cause stress concentrations and generally make the vehicle heavier. Both of which we want to avoid, especially in structures that are to take high g-loads. So we'd have to come up with a good fiction reason to do it that way.

[hurleybird]

Starange: Thats an awesome idea that has been actually brought up once or twice a long, long, time ago.

However, It never got implemented because of two problems.

1. it was too early in game development.

2. Lack of artwork.

If you wanted to make the artwork for it, Im sure that Ace, hellcat, shezerade, or someone would be able to code it very easily.

It's the same basic principle as VWEPS, just used for a different purpose, I dont think it would be overly hard to adapt VWEPS to your idea.

If we were to implement this then the technology most likely would eventually lead to 'detail modeling' which would mean that as you got closer to the model, different sub-models (with the ability to use lods for the sub-models) would be rendered. Things like grevels, attena, and little inatke or outake vents would be rendered if you were close enough to the part of the model that the subunit was apart of. This of course would work best for absolutley huge models, but couple it with the idea of having interchangable parts and you could have a station (or cap-ship) literally hundreds of miles long, and detailed at near CG quality while still having good performance.

Once again, if you gave the programmes a few test models to work with... a core module, a hangar, crew compartments, storage compartments, and connecting modules, then i wouldnt be surprised to see some programming happen.

Another cool feature that would stem off of this would be the ability to destroy different modules

[jackS]

We already have support for arbitrary hierarchies of subunits. They do, however have to be hierarchies - that is, destroying a subunit KOs all of its dependants. Thus, for stations, so long as the core unit is sufficiently stand-alone that it makes sense that it could continue to exist sans extra modules, this isn't a big issue - if you make some sort of catterpillarlike structure, but then blow out the middle, you get much wierdness.

There would need to be a couple things done to accomodate adding randomized sub-modules -

one (vital) - alter the specification of units to denote allowable sets of attachments rather than the presence or absence of a fixed attachment.

two (convenient) - allow for a subunit to add to the capabilites of higher level units. If you're just strapping on self-contained modules, it might get a bit odd after a while to notice that it hasn't really done anything to the unit that posesses them - this would be the more difficult task.

three (awareness) - whatever models were constructed to allow the agglomeration of parts would have to be designed with the "how's he walk with a hole in him" problem in mind, thus putting some limit on what and where this is a useful technique - stations should have a field day with this - capships rather less so, probably benefitting primarily from a few limited accessory options (stick pod of type X here, gain K guns or ability Y), fighters - I don't really see why you'd want an incredibly modularizable fighter hull - seems like it'd be prone to being smashed into its constituent pieces.

[hurleybird]

I don't really see why you'd want an incredibly modularizable fighter hull - seems like it'd be prone to being smashed into its constituent pieces.

You want it because its cool and adds variety

PS - You think too much

[strangelet]

wow. what a great response. i hope this idea goes through...

modelling different parts - not EVERY ship will have had a long service history... and i have an idea that Many ships in the game are to be replaced anyway...

the ox is a good example, that will have been chopped and rebuilt countless times for dif purposes, wheras things like the aera fighters will all be pretty samey

also maybe you could group the subunits to add consistency -

confed fighters might have similar structures in common across a broad range of ships...

the ideal of course would be to have subunit configuration accurately represent the modifications made to a vessel (although alot of these are internal, stuff like bigger engines, heavy armour, shield generators and ecm "humps" would definately modify the appearance.

if one was cunning, all the subunits for a ship or group of ships would use one common texture "swatch" for economy

[hurleybird]

the ideal of course would be to have subunit configuration accurately represent the modifications made to a vessel (although alot of these are internal, stuff like bigger engines, heavy armour, shield generators and ecm "humps" would definately modify the appearance.

if one was cunning, all the subunits for a ship or group of ships would use one common texture "swatch" for economy

Having the apperance of your ship change with external upgrades would be awesome. Im sure it would require a heck of a lot of art though.

If this goes through, one idea would be to tie it in to the dynamic universe, so as a ship goes through its service history and its revisions its appearance changes, but so would its specs. You could also dynamically generate 'special edition' ships with enhanced features at a price.

[charlieg]

Having the apperance of your ship change with external upgrades would be awesome. Im sure it would require a heck of a lot of art though.

Well, that's the point of modularity. If you think about it, 20 pieces can be combined in how many unique ways? It's a really, really large number. So the artwork required wouldn't be that much.

You could also add the option to 'colorize' (yank) or 'colourise' (limey) ships. If you could affect the colour of ships, that'd make the game even more dynamic... you could colour coordinate different factions etc etc.

[hurleybird]

Having the apperance of your ship change with external upgrades would be awesome. Im sure it would require a heck of a lot of art though.

Well, that's the point of modularity. If you think about it, 20 pieces can be combined in how many unique ways? It's a really, really large number. So the artwork required wouldn't be that much.

You could also add the option to 'colorize' (yank) or 'colourise' (limey) ships. If you could affect the colour of ships, that'd make the game even more dynamic... you could colour coordinate different factions etc etc.

Thats a good idea as well. Homeworld did something like this, except there where a few different sections of textures that could be textured differently, thus the user could make his own 'style' of fleet. Just colorising the entire texture could be messy though.

Anyway, I think were might be starting to get ahead of ourselves a little.

[charlieg]

Anyway, I think were might be starting to get ahead of ourselves a little.

Getting ahead of ourselves / brainstorming for 0.6... same thing!

[hurleybird]

We already have support for arbitrary hierarchies of subunits. They do, however have to be hierarchies - that is, destroying a subunit KOs all of its dependants.

Perhaps have an option that would just disable the subunit and change its texture to the damage map.

Or maybe only have it possible to fully destroy a subunit if it is at the very end of its hierchie.

Either way, there should be a toltal station structural integrity that needs to reach zero to fully destroy the station. Perhaps an equation like:

core unit integrity + (numofsubunits*constant)?

[pincushionman]

Here's how something like this might be done...we need three things (we may have them already, I haven't played around with it):

1) Attached subunits need to add to the total mass, center of mass, AND the total inertia of the unit as a whole. I belive they do add to the mass already, but, as I said, I haven't played with it. And we'd need to start defining full-blown mass matricies -- I think we only use Ixx, Iyy and Izz now, and we'll need to start computing Ixy, Iyz, and Ixz because arbitrary assortments of large coomponents could seriously de-symmetrify a unit.

2) We need to either add a tag for "parent attachment" to units, which defines what point and direction a unit attaches to a mount point when used as a subunit. Either that or we need to continue to assume attachment at (0,0,0) and have a new tag that defines the center of mass and the principal axes. I say the former method is the more straightforward way. We need this because we would need the ability to connect units of wildly varying size and shape to the same mount points.

3) We would need to "network" subunits. A ship's unit file could be entirely made up of subunit tags, and we'd need the ability to say "this unit connects to this unit and this unit and this unit. Our current system of subunits inside subunits would work as well, a called subunit would just be an automatic network link to only one parent. But having explicitly-defined links would allow units to "attach" to more than one central unit, and would also allow us to more easily change the inner subunits without having to change all the downstream units as well.

Here's where it could get really cool: If any individual subunit is destroyed, a continuity check is done on the remaining network of units. If there are any isolated nodes or groups of nodes, they would be removed from the parent unit and an identical group of nodes would spawn as a new unit with stats identical to their current values. And the mass, center of mass, and inertia matrix of all the affected total units would have to be dynamically recomputed, otherwise the resulting motion would look pretty darn silly.

You could blow off entire sections of a station and the different parts would tumble through space, still firing at you.

Does this belong in "feature requests" instead?