Offsite Installation development

[stevenjackson]

Hi All

I'm thinking of developing this todo item, seems like it would be interesting.  So i was thinking about what would be involved and as a start came up with this basic (very rough) struct of offsite installations in general.

Just wanted to see what peoples thoughts were.

This will hold the data for any type of installation.  The presumed planned ones that i have included are Sam sites, ufo yard and radar facility.

Code: [Select]

/** @brief A installation with all it's data */
typedef struct installation_s {
int idx; /**< Self link. Index in the global installation-list. */
char name[MAX_VAR]; /**< Name of the installation */

installationType_t installationType; /** type of installation.  Radar, Sam Site or UFO Yard **/

qboolean founded; /**< already founded? */
vec3_t pos; /**< pos on geoscape */

/** All ufo aircraft in this installation.  This used for UFO Yards. **/
aircraft_t aircraft[MAX_AIRCRAFT];
int numAircraftInBase; /**< How many aircraft are in this installation. */

capacities_t aircraftCapacitiy; /**< Capacity of UFO Yard. */

installationStatus_t installationStatus; /**< the current installation status */

float alienInterest; /**< How much aliens know this installation (and may attack it) */

radar_t radar;

baseWeapon_t batteries[MAX_INSTALLATION_BATTERIES]; /**< Missile/Laser batteries assigned to this installation.  For Sam Sites Only.  */
int numBatteries;

int installationDamage; /**< Hit points of base */

} installation_t;

Steve

[BTAxis]

You might want to put any code in

Code: [Select]

[code] blocks.[/code]

[Mattn]

i can't remember right now - do we have alien bases already? if not, this should be introduced, too

not sure whether this struct is suitable for this task, too. Though we should keep it in mind.

[BTAxis]

I don't know if the alien bases are already there, but the campaign framework should be almost ready for them.

[Negator_UK]

Does the installation come into play instantly - are there counters to count down to startup time ?

Transfers - stuff in transit to and from, ETA ?

[stevenjackson]

with regard to alien bases it depends on how we are going to handle them.

If they  will be fairly simple then this struct could possibly cater for them.  In which case it may need the employee array of structs added (or however we handle aliens).

If we need to keep track of buildings and much it may be better to use a version of the base struct?

Is there any doco around on what we want for alien bases?

Steve

[kracken]

Alien bases are already implemented, but they are quite basics: see cl_alienbase.h

Concerning the structure offsite installation, I guess you could add a status to know if the installation is under attack for UFO yards.
when alien will attack UFO yards, you'll be able to defend them by sending a drophip. If you don't, well... you're probably going to loose all your UFOs...

I think you don't need to use an array 'aircraft_t aircraft[MAX_AIRCRAFT];' : a pointer to UFO template in aircraftTemplates[] should be enough (aircraft_t *aircraft[MAX_AIRCRAFT]

Regards,

Kracken

[tchristney]

I've also been thinking about this problem and I've come to the conclusion that it probably isn't necessary to make a specific off-base installation data type. I think the easiest and perhaps best solution is to simply use the existing base structure with some small modifications.

One way would be to just relax the 8 base limitation. This is a very, very easy way to allow players to build installations all over the globe. There is some more micro-management involved, but it would be up to the player to manage how much they are able to take on.

A slightly more complex solution would be to allow the base struct to have a heap allocated array of buildings. This would allow bases that are much smaller and/or much larger than the existing base. By keeping these other base types in a separate "off-base" linked list (or similar container) we could restrict their size and building composition to a set of prototypes as defined by ufo files. This would also allow us to manage the resources for the player (i.e. keeping missiles stocked for the SAM site, etc.).

The advantage of these approaches is that there is much existing code for dealing with base management that would need little to no modification to be used in the new context. They would be just regular bases that aren't necessarily under direct player control. Also, making new off-base installation types could be as simple as adding a new prototype definition to the ufo file.

[stevenjackson]

tchristney

We could use the base struct for installations and it was the first thing i considered.
The reason i considered a separate struct was that there is alot of information in the base struct that isn't needed for an installation.

But i think there is two questions here that need to be answered:

1) Can installations just be normal bases, so you could just build bases for specific purposes

My understanding was that the answer to this question is no.  We want to keep a base limit?
Also the ufo yards need to be handled outside of the base.

2) Should we use the existing base struct or create a new struct and code to handle installations?

I'm happy to go either way on this one.  we can just define a new "base_t installations" in global data.
My only issue is that it then could become confusing and a little unwieldy as its not just one or two fields not being used but quite a lot.  And a simpler struct may be more effective.
Obviously my struct is just a cutdown version of the base_s struct with a few additions.

Steve

[stevenjackson]

kracken

There is already a status on the struct.

I think your right about just linking to the aircraft template.  Since they arn't real aircraft this is probably a better idea.

Also there is the current plan for installations at the following wiki location:

http://ufoai.ninex.info/wiki/index.php/Proposals/Off-base_Installations

Steve

[kracken]

There is already a status on the struct.

oh sorry 

[tchristney]

There is also a chance to refactor the struct. It would be possible to place the common elements in the beginning of the struct, with the specializations at the end in a separate struct. Then the common code can use pointers to the base struct, while the specialized code uses pointers to the specialized struct. This is a more significant refactoring job that just ignoring the unused members though.

I'm not sure why the UFO yard can't be handled by the existing struct though. We may need a new "building" type, but other than that I don't see a problem, TBH. Also we would need to modify the member map to be a baseBuildingTile_t * and dynamically allocate the array based on the required number of rows and columns. So a UFO yard could theoretically be a very large installation! Similarly, a SAM site may be a 3x2 or 3x3 base with only a few preset buildings inside it. That change will probably generate some serious errors, but thankfully those are the sort that the compiler is good at catching. 

It's important to note that although this approach makes off-base and base installations identical to the code, this will be mostly hidden from the user. I would like to see the off-base installation management completely automated.