Jump to content
XCOMUFO & Xenocide

Facility Types


dteviot

Recommended Posts

A few things I've noticed.

1. In the facilities.xml, "manteinance" should be spelt "maintenance"

2. There doesn't seem to be a type for Defense Array facilities. E.G. GAIA Defense Facility.

3. I'm not sure there's a need for separate research and workshop facility types. The Facility types already seem to share common types. E.g. A FAC_ALIEN_CONTAINMENT_FACILITY and a FAC_GENERAL_STORAGE_FACILITY are both storageFacilityType.

 

1's easy to fix

 

I'd like to discuss items 2 and 3 before making changes.

Initial thought for 2 is just create the type. Possible attributes of a defense array would be: range (km), accuracy (% chance of hit per shot), damage per shot, reload time (secs).

Link to comment
Share on other sites

My two cents :)

 

2) I think we should add this type of facility to xml shemas

3) Yes in .xml file we can't distinguish if givent storage facility is general or alien storage. (I think i was already asking somebody about that, but know don't remeber it). I implemented it by checking by type names which is very ugly (at least for me) and should be changed.

 

4) We can't say wich object (from research.xml) can be bought and wich have to be produced. Also there are no buy / product prices anywhere. I'm voitng to add this attributs to item.xml/.xsd

 

 

Beetle

Link to comment
Share on other sites

Additional comments

We have the following human facilities:

 

Base Access Facility

Landing Pad

Barracks Facility

Research Facility

Engineering Facility

Plasma Defense Array

Laser Defense Array

GAIA Defense Array

Missile Defense Array

Storage Facility

Xenomorph Holding Facility

Short Range Neudar

Long Range Neudar

Tachyon Emissions Detector

Gravity Shield Facility

Neural Shielding Facility

Psionic Training Facility

 

And we form humanfacilitytype.cpp,

have the following HumanFacilityType classes - which the following facilities belong to:

 

 

HumanFacilityType

- Base Access

- Landing Pad

 

StorageFacilityType

- Storage

 

ScanningFacilityType

- Short Range Neudar

 

ResearchFacilityType

- Research

 

PersonelFacilityType

- Barracks

 

WorkshopFacilityType

- Engineering

 

 

Looking at this list, it would apper that Long Range Neudar & Tachyon Emissions Detector would go under ScanningFacilityType

 

And if we add a DefenseArrayType, then the 4 defense arrays go there.

 

That leaves Gravity Shield, Neural Shield & Psionic Training.

Which I don't know where they go, although I suspect Psionic training goes under PersonelFacilityType.

 

Also, as I said before, I suspect the Research & Workshop types can be replaced with a single class.

Link to comment
Share on other sites

Using the Project Wise framework, those can be unified into a single class.

 

Greetings

Red Knight

Please confirm, you're saying that Research & Workshop could become "Project" class?

 

I'm thinking, Gravity & neural shield can go under HumanFacility, at least for the moment.

Link to comment
Share on other sites

but we have to know wich facility is which. Both research and engineering have projects, but if we put them into one we have to add a attribute (in xml) of some sort.

Yes, something like "Supported Project Type"

 

Incidentally, unless someone tells me different within the next 48 hours, I'm going to add the missing items to facilities.xml, facilities.xsd and update HumanFacilityType.cpp and HumanFacilityType.h to load them as well.

 

Looking at the XNET description for the Grav shield and Neural shield, I think they become 2 new types.

Grav Shield gets attribute: Speed reduction. Float range 0.0 to 1.0 indicating how badly UFO's speed is reduced. 0 = stopped, 1.0 = uneffected.

Neural shield gets: dampening. Float range 0.0 to 1.0 indicating how much it reduce's bases detectability. 0 = no reduction, 1.0 = undetectable.

Link to comment
Share on other sites

Yeap, dont wait ;)

 

Greetings

Red Knight

Done. Sort of. (Updated files sent to Beetle for check-in.)

The HumanFacilityTypesFactory should now return a valid object for each facility type. Note, I suspect many of the Facilities don't have a complete set of attributes.

 

While doing this work I discovered that facility.xsd already had entries for defense and shield, so I keep them. And for the other types, I've also kept their existing attributes from the .xsd. (With the exception of Research & Workshop, which I've consolidated.)

 

I've added entries to facilities.xml so that it has a complete set. However the values for many of the attributes I just made up off the top of my head, so someone will need to go through and put in the correct values. (Hint, the SIZE attributes should be fixed ASAP.)

 

At any rate, now when we figure out what static attributes the various facility types have it should be simple to add them.

 

A couple of final notes.

1) I was unable to find an entry in research.xml for the GAIA defense array, so I've assumed it is called FAC_GAIA_DEFENSE_ARRAY

 

2) I had to patch HumanFacility.cpp to match the changes, and found code like this:

void HumanFacility::scrapFacility()
{
   if (facilityType->getTypeName() == "FAC_HANGAR_FACILITY")
{
 ownerBase->changeLaunchAreas(-1);
}
if (facilityType->getTypeName() == "FAC_GENERAL_STORAGE_FACILITY")
{
 ownerBase->changeGeneralCapacity(-1 * ((StorageFacilityType*)facilityType)->getCapacity());
}
if (facilityType->getTypeName() == "FAC_ALIEN_CONTAINMENT_FACILITY")
{
 ownerBase->changeAlienCapacity(-1 * ((StorageFacilityType*)facilityType)->getCapacity());
}
if (facilityType->getTypeName() == "FAC_BARRACKS_FACILITY")
{
 ownerBase->changePersonelCapacity(-1 * ((PersonelFacilityType*)facilityType)->getCapacity());
}
if (facilityType->getTypeName() == "FAC_RESEARCH_FACILITY")
{
 ownerBase->changeResearchCapacity(-1 * ((ProjectFacilityType*)facilityType)->getCapacity());
}

   Player::get().modifyMoney(facilityType->getScrapRevenue());

}

 

Which suggests the need for some additional virtual functions in the HumanFacilityType class. e.g. OnScrap(), OnConstructed()

Link to comment
Share on other sites

Yes virtual methods will be nice :)

 

You can also think a little on canBeDestroyed() since i don't really like how i done it :) Maybe You will manage to make something more intuitive :) (i don't mean only this funciton but a "communication" between HumanBase and HumanFacility about this topic)

 

There is also needed a method wich can GUI use for assigning a callback function wich will be called insted of facilityConstructedInfo.

 

:)

Link to comment
Share on other sites

A couple of final notes.

1) I was unable to find an entry in research.xml for the GAIA defense array, so I've assumed it is called FAC_GAIA_DEFENSE_ARRAY

I'll look into it :)

Just so you know, I will update and fix research.xml once someone fixes the schema and allows "free" research, otherwise I can see myself going through it all again once it's eventually done :) is anyone working on it?

Link to comment
Share on other sites

A couple of final notes.

1) I was unable to find an entry in research.xml for the GAIA defense array, so I've assumed it is called FAC_GAIA_DEFENSE_ARRAY

I'll look into it :)

Just so you know, I will update and fix research.xml once someone fixes the schema and allows "free" research, otherwise I can see myself going through it all again once it's eventually done :) is anyone working on it?

Just to fill in, this is what Azrael is talking about. If there are no objections, I'll fix up the .xsd to allow 0 time tomorrow. I have RL plans for tonight.

 

Azrael,

 

Noticed in reseach.xml the topic topic RES_PSIONIC_AMPLIFIER

has a prerequisite of XNET_PSIONIC_LAB which doesn't appear to exist anywhere else.

 

I will take a thorough look tonight and try to fix as many errors as possible, there are some things I would like to ask you too about it, maybe you can answer my doubts. For now my most important question is: how do you do to make a topic be obtained "for free" after it meets different requirements?

For example, the XCAP, GAIA should be available for manufacture after researching XC-2 Starfire and GAIA Missile (not sure if these are the actual requirements, but doesn't matter, it's an example :)), now you should obtain the Xnet entry "XCAP, GAIA" and the ability to manufacture the XCAP after researching these two entries (XC2 and Missile) with no additional research time (i.e. you don't need to select "XCAP, GAIA" in the research dialog, you just get it after meeting the requirements). So how am I to put that it needs these two requirements but doesn't need to be researched (not even selected from the research screen) ? So far my best option was to put Research Time 0, but the schema won't allow me to do that, and if I understand it correctly, it'd still need to be researched if I did that, though it'd be completed instantly.

Did I make any sense there? do you have any idea how to make this?

The answer is I don't know. All I know about research.xml is what I see in the file. From the sounds of it, we need to update the research schema, either to allow a duration of 0 (which the "reseach engine" will need to understand means a research project isn't needed) or a new explicit attribute (e.g. automatic) to indicate same. Either way, changing the schema exceeds my authority.

 

Same thing as with the other issue. Post it in the forums. That way, the process is documented and everybody gets to give their opinion.

 

Rincewind

 

P.S: The duration of 0 seems to me the appropriate way to do it but let's get some feedback from the others.

Link to comment
Share on other sites

Azreal,

 

Attached is updated research.xsd, that will let you set time to 0.

 

Also, I've discovered that the latest build of Xenocide crashes in base view if you try to create a facility other than

baracks,

short range neudar,

or Research.

 

This is because the Facility Type names differ between the files:

research.xml

graphics.xml

facility.xml and HumanFacilityType.cpp

 

When you've confirmed the names in research.xml are up to date, please drop me a note and I'll update the other files to match.

 

Thanks,

David

research.xsd

Link to comment
Share on other sites

I have fixed it yesterday, are there still problems with facility names??

Maybe we should switch HumanFacilityType.cpp from searching thru names into searching thru xsi:type?

 

About reasearch.xml, i already PM Azrael about that, but there is strange (for me) attribute in there

<xsd:attribute name="persists" type="xsd:boolean" default="false"/>

 

maybe it's supposed to be used for that kind of research ??

edit: At this point this attribute isn't used anywhere (it's false everywhere).

Edited by Beetle
Link to comment
Share on other sites

Ok, so what do I use? Research time 0 or Persists?

Also, will Research Time 0 allow it to be obtained without even having to click on the research window? remember that for example the Fusion Tank once the requisites are met, it's supposed to pop up and simply say "Research Completed: GAIA XCAP" without me having to ever select it for research :)

I promise I'll look into Research.xml tonight, haven't had time cause I had to swap drives and for unfortunate events I had to reinstall it two more times <_<

 

About reasearch.xml, i already PM Azrael about that, but there is strange (for me) attribute in there

CODE

 

<xsd:attribute name="persists" type="xsd:boolean" default="false"/>

 

 

maybe it's supposed to be used for that kind of research ??

edit: At this point this attribute isn't used anywhere (it's false everywhere).

I think I remember something like this from one of the first tech trees, made by Cpt. Boxershorts, isn't that attribute mean that you can still research it? so, if it's false it means that you cannot research it again once research is completed, if it's true you can, that'd mean that for example "Grey Medic" would be True since you can obtain more than one Live Alien Study from it. Makes sense to me, and we also need such an attribute, in case that's not the one.

Edited by Azrael
Link to comment
Share on other sites

I have fixed it yesterday, are there still problems with facility names??

My error, I haven't updated my code since Tuesday, so the code I have didn't have your updates.

 

Maybe we should switch HumanFacilityType.cpp from searching thru names into searching thru xsi:type?

Possible, but I'm not sure we'd gain much. We still need to do a mapping from element in XML file to C++ class we're going to create.

 

In addition, the "element names" e.g. FAC_GAIA_DEFENSE_ARRAY are essentially identifiers, that are used in multiple files, e.g. xnet, research, graphics etc. So, if it's changed in one file, it must be changed in all of them.

 

And I believe I know how to enforce this.

In basic.xsd, the facilityID has a simple pattern restriction of:

If I change this to an enumeration restriction (putting in the "official" names) then the XML files will only validate if the names are correct. :-)

 

So,

1. Does this plan look feasible, or am I overlooking something? (I'm still learning XML)

2. I'm assuming the master source for the IDs is research.xml. Is this correct?

3. If this works, as well as doing the facilities, all of these element names should be coded in basic.xsd as enumerations. However, as that's a big job I'd like to stage it over a period of time. Any objections?

 

Cheers

Link to comment
Share on other sites

Maybe we should switch HumanFacilityType.cpp from searching thru names into searching thru xsi:type?

Possible, but I'm not sure we'd gain much. We still need to do a mapping from element in XML file to C++ class we're going to create.

In addtion, changing an identifier name will break code instances like this

void HumanFacility::facilityConstructed()
{
   if (facilityType->getTypeName() == "FAC_HANGAR_FACILITY")
{
 ownerBase->changeLaunchAreas(1);
}
if (facilityType->getTypeName() == "FAC_GENERAL_STORAGE_FACILITY")
{
 ownerBase->changeGeneralCapacity(((StorageFacilityType*)facilityType)->getCapacity());
}
if (facilityType->getTypeName() == "FAC_ALIEN_CONTAINMENT_FACILITY")
{
 ownerBase->changeAlienCapacity(((StorageFacilityType*)facilityType)->getCapacity());
}
if (facilityType->getTypeName() == "FAC_BARRACKS_FACILITY")
{
 ownerBase->changePersonelCapacity(((PersonelFacilityType*)facilityType)->getCapacity());
}
if (facilityType->getTypeName() == "FAC_RESEARCH_FACILITY")
{
 ownerBase->changeResearchCapacity(((ProjectFacilityType*)facilityType)->getCapacity());
}
   isConstructing = false;
}

Link to comment
Share on other sites

Yes You have right, but (the is always but) doing like that isn't very flexible. Maybe we will just leave this as it is :)

 

Beetle

 

P.S. About research.xml you have also right :)

So, is the persistency thing as I think it is?

And what the research time 0? how will it work? (or whatever you guys did to fix the "free research")

 

edit: I'll update research.xml tomorrow, hopefully, my windows is having another crisis and needs to be reinstalled for the third time in two days <_<

Edited by Azrael
Link to comment
Share on other sites

Yes You have right, but (the is always but) doing like that isn't very flexible. Maybe we will just leave this as it is :)

 

Beetle

 

P.S. About research.xml you have also right :)

So, is the persistency thing as I think it is?

And what the research time 0? how will it work? (or whatever you guys did to fix the "free research")

 

edit: I'll update research.xml tomorrow, hopefully, my windows is having another crisis and needs to be reinstalled for the third time in two days <_>

I'm sorry, I don't know anything more about the "persists" attribute at this time than you do.

 

At the moment, I'd say ignore the persists attribute, use time = 0. If this proves to be wrong, I can always write a script to fixup the file.

 

The change I made to the .xsd schema now permits the minimum "time" value to be zero. Previously it was 1. My thought is that when a new "knowledge" is gained by research, the engine would run through the list of all "knowledges" and if you now meet the critera for a time = 0 knowledge it would automatically give you that as well.

Link to comment
Share on other sites

Yes You have right, but (the is always but) doing like that isn't very flexible. Maybe we will just leave this as it is :)

 

Beetle

 

P.S. About research.xml you have also right :)

Beetle,

Can you confirm what you're saying is:

1. We use research.xml as the master reference for element names.

2. We could enforce correct element naming by defining the enumerations in base.xsd, but you'd rather we didn't, as it's not flexible.

 

Assuming my understaning is correct, why do we need the flexibility? As I see it, the flexibility just causes problems, as it allows the element names in the various files to get out of sync.

 

Thanks,

David

Link to comment
Share on other sites

Currently "persits" is not used.

So lets use it :)

From code part we will made it as you want it :)

I'd argue against using persists. What Azrael wants is to show that given prerequisits X and Y, you automatically get research item Z. Which suggests to me that the best way of indicating this is by the time attribute. The "persists" attribute would appear to indicate something else. (Possibly that it doesn't destroy the items required for researching an item.)

Link to comment
Share on other sites

Hmm when i was writing my previos post i didn't noticed azrael post :Brickwall:

but he had right :) :) ok so i'm conviced now :) we will use 0 time for that.

Azrael and dteviot i own you a beer :) :beer:

 

Yes, we use research.xml as major reference for names.

 

Flexibilty, yes it always means complexity :) we are trying here to make everything as much flexible as it can be ( i didn't develop that i was forced :P ), or at least we are trying to make a future possibilty to easy add new things. Or at least other programmers are trying to do it, becouse in my case, i almost always fail at this point :)

 

2. Go on with that enumeration (in future i will try to add testings from program part (test names from research.xml :) ) )

Link to comment
Share on other sites

The change I made to the .xsd schema now permits the minimum "time" value to be zero.  Previously it was 1.  My thought is that when a new "knowledge" is gained by research, the engine would run through the list of all "knowledges" and if you now meet the critera for a time = 0 knowledge it would automatically give you that as well.

My concern is that even with time 0 it will still require the player to go to the Research screen and select the topic.

But I'll set the appropiate topics with 0 and I guess you guys will take it from there :)

About the persist attribute, is that what I think? should I use it? I assumed it was to allow the player to research something more than once, i.e. Grey Medic. I dunno, you people tell me :)

Link to comment
Share on other sites

The change I made to the .xsd schema now permits the minimum "time" value to be zero.  Previously it was 1.  My thought is that when a new "knowledge" is gained by research, the engine would run through the list of all "knowledges" and if you now meet the critera for a time = 0 knowledge it would automatically give you that as well.

My concern is that even with time 0 it will still require the player to go to the Research screen and select the topic.

But I'll set the appropiate topics with 0 and I guess you guys will take it from there :)

So far as I am aware, the research engine hasn't been written yet. But I'm very eager to get started on it. (More on this in a few days.) Dealing with a time 0 topic should be simple enough. Just means that when the project manager does it's daily progress update it needs to check for any zero time topics with a full set of prerequisites. If any are found, they're marked as available and player is informed. No biggie.

 

About the persist attribute, is that what I think? should I use it? I assumed it was to allow the player to research something more than once, i.e. Grey Medic. I dunno, you people tell me :)

I'd ignore it for the time being, until we figure out what it's for.

Link to comment
Share on other sites

The change I made to the .xsd schema now permits the minimum "time" value to be zero.  Previously it was 1.  My thought is that when a new "knowledge" is gained by research, the engine would run through the list of all "knowledges" and if you now meet the critera for a time = 0 knowledge it would automatically give you that as well.

My concern is that even with time 0 it will still require the player to go to the Research screen and select the topic.

But I'll set the appropiate topics with 0 and I guess you guys will take it from there :)

So far as I am aware, the research engine hasn't been written yet. But I'm very eager to get started on it. (More on this in a few days.) Dealing with a time 0 topic should be simple enough. Just means that when the project manager does it's daily progress update it needs to check for any zero time topics with a full set of prerequisites. If any are found, they're marked as available and player is informed. No biggie.

 

About the persist attribute, is that what I think? should I use it? I assumed it was to allow the player to research something more than once, i.e. Grey Medic. I dunno, you people tell me :)

I'd ignore it for the time being, until we figure out what it's for.

The xml validator does not allow me to set time 0.

Link to comment
Share on other sites

The xml validator does not allow me to set time 0.

Which validator are you using?

XMLSpy Home Edition 2006

OK, I'm not familar with that tool.

The change I made to research.xsd was very simple. The line

was changed to

 

The difference being xsd:positiveInteger doesn't include zero, but xsd:nonNegativeInteger does.

 

ref:

http://books.xmlschemata.org/relaxng/ch19-77247.html

 

Suggestions.

1. Check the .xsd file itself, possibly I sent you the wrong one.

2. Is it possible you have multiple copies of the .xsd file on your PC, and you're validating against an older one?

Link to comment
Share on other sites

The xml validator does not allow me to set time 0.

Which validator are you using?

XMLSpy Home Edition 2006

OK, I'm not familar with that tool.

The change I made to research.xsd was very simple. The line

<xsd:element name="time" type="xsd:positiveInteger" />

was changed to

<xsd:element name="time" type="xsd:nonNegativeInteger" />

 

The difference being xsd:positiveInteger doesn't include zero, but xsd:nonNegativeInteger does.

 

ref:

http://books.xmlschemata.org/relaxng/ch19-77247.html

 

Suggestions.

1. Check the .xsd file itself, possibly I sent you the wrong one.

2. Is it possible you have multiple copies of the .xsd file on your PC, and you're validating against an older one?

I am using the xml file from the repository, so they are all the latest ones (unless you haven't commited it yet?)

Link to comment
Share on other sites

The xml validator does not allow me to set time 0.

Which validator are you using?

XMLSpy Home Edition 2006

OK, I'm not familar with that tool.

The change I made to research.xsd was very simple. The line

was changed to

 

The difference being xsd:positiveInteger doesn't include zero, but xsd:nonNegativeInteger does.

 

ref:

http://books.xmlschemata.org/relaxng/ch19-77247.html

 

Suggestions.

1. Check the .xsd file itself, possibly I sent you the wrong one.

2. Is it possible you have multiple copies of the .xsd file on your PC, and you're validating against an older one?

I am using the xml file from the repository, so they are all the latest ones (unless you haven't commited it yet?)

No, I had not committed it. I was expecting you to do that, along with the updated results.xml file.

Link to comment
Share on other sites

No, I had not committed it.  I was expecting you to do that, along with the updated results.xml file.

Sorry, meant research.xml file.

I don't know how to change an xsd file, don't even know what it is or what to do with it, I only play with xmls.

You shouldn't need to change the research.xsd file I sent you, just overwrite the research.xsd only your system with it, and check it in with your updated research.xml (they both live in the same directory in the xenocide repository.)

 

FYI. xsd files are just xml files that specify the restrictions on a xml file. If you want to edit a .xsd file, easiest way I find is add .xml to end of the .xsd, then open it with your favourite .xml editor.

Link to comment
Share on other sites

No, I had not committed it.  I was expecting you to do that, along with the updated results.xml file.

Sorry, meant research.xml file.

I don't know how to change an xsd file, don't even know what it is or what to do with it, I only play with xmls.

You shouldn't need to change the research.xsd file I sent you, just overwrite the research.xsd only your system with it, and check it in with your updated research.xml (they both live in the same directory in the xenocide repository.)

 

FYI. xsd files are just xml files that specify the restrictions on a xml file. If you want to edit a .xsd file, easiest way I find is add .xml to end of the .xsd, then open it with your favourite .xml editor.

You didn't send me anything.

 

edit: Nevermind, I edited research.xsd the way you told me, now accepting 0 as research time, and updated research.xml fixing a few inconsistencies, unfortunately I don't have the time to give it a proper look, will try to do it tomorrow, should you find any more errors, please let me know.

Edited by Azrael
Link to comment
Share on other sites

You didn't send me anything.

 

edit: Nevermind, I edited research.xsd the way you told me, now accepting 0 as research time, and updated research.xml fixing a few inconsistencies, unfortunately I don't have the time to give it a proper look, will try to do it tomorrow, should you find any more errors, please let me know.

You are quite correct. It's an attachment to post #17 on this thread.

Link to comment
Share on other sites

  • 3 weeks later...

Just had a thought, many of the base facilities primary function is to increase a capacity of one type or another.

e.g. alien containment, barracks, landing pad, storeroom, lab, workshop, etc.

Therefore, idea is have them inherit from a common base class “Capacity facility”, and they specify the type of capacity they increase.

 

We then change the Capacity Info so that it tracks the type of a capacity, as well as the quantity.

 

E.g.

Class CapacityInfo
{
public:
enum CapacityTypes
{
aliens,
 personnel,
equipment,
craft
};

void changeCapacity(CapacityType type, int quantity)
{
   capacities.find(type)->second += quantity;
}

int getCapacity(CapacityType)
{
return capacities.find(type)->second;
}

private:
::std::map<CapacityType, int> capacities
}

This should allow simplification of Facilities code.

Link to comment
Share on other sites

  • 1 year later...

Facility Class(es) design.

 

OK, here’s my plan for how we do facilities. Your input is requested. Once this is agreed, then I think these notes should be put into the design document, because they’re a work of genius.

 

In the current design, there are 17 unique facilities, which can be grouped into 4 classes, which I have named:
  • Storage
  • Scan
  • Defence
  • Unique

Storage Facilities

In simple terms, these increase the quantity of some “material” that can be “stored” in a base. The “storage” facilities are:

  1. Landing Pad
  2. Barracks Facility
  3. Xenomorph Holding Facility
  4. Storage Facility
  5. Psionic Training Facility
  6. Research Facility
  7. Engineering Facility

Notes on storage type

  • Some people might wonder why the Psionic Training, Research and Engineering facilities are on this list. Well, the Research Facility increases the number of “working scientists” that a base can hold.
  • The easiest way to model these facilities is to give the base a “capacity” for each types of “material”. Then when a facility is constructed the relevant base’s “capacity” is increased. (And decreased when the facility is destroyed.)
  • A facility can’t be destroyed if it’s in use. As the “material” is owned by the base, not a facility, test is checking if destruction of the facility would reduce the base’s “capacity” below the level currently present in the base.
  • Beyond needing to know when a facility finishes being built, the facility does not change over time. It doesn’t need to implement update(gametime).
  • What about start/end of month Psi training? Answer, that’s not the responsibility of the Facility. That’s done in the “start of month” processing. (Aside, it’s probably easier to work with “start of month”, because “end of month” varies depending on the month.)
  • What about research projects? Answer, the research manager is responsible for tracking them, not the facility.

Scan Facilities

These detect UFOs. The “scan” facilities are:

  1. Short Range Neudar
  2. Long Range Neudar
  3. Tachyon Emissions Detector

Notes on scan type

  • These facilities do need to implement an update(gametime) function, because they need to check each “time period” to see if they’ve detected any UFOs.
  • In X-COM, despite what Ufopedia says, having more than one of each type of Neudar in a base doesn’t help. So, we will not allow a base to have more than one of each type of scan facility.

Defence Facilities

These facilities shoot at UFOs when UFOs try to attack a base. The defence facilities are:

  1. Missile Defence Array
  2. Laser Defence Array
  3. Plasma Defence Array
  4. GAIA Defence Array

Notes on defence type

  • These facilities only come into play when a UFO is attacking the base and gets into range.
  • When the attacking UFO gets into range, then each facility gets to take one shot at the UFO. (Or 2 shots if a Gravity Shield is present in the base.)
  • So, defence facilities don’t need to update their state with an update(gametime). They’re just called as part of the sequence for an “Alien Attack on X-Corp” base.

Unique Facilities

These are facilities that don’t belong to a class. That is, each one is unique, with no other facility like it. The unique facilities are:

  1. Base Access Facility
  2. Gravity Shield Facility
  3. Neural Shielding Facility

Notes on these types

  • Base Access Facility: Every base must have one, and only one, of these. It must be the first facility that is built when a base is constructed, and is the core around which all other facilities are constructed. Beyond this, it adds nothing.
  • Gravity Shield Facility : A base can have no more than one of these. If one is present, then each defence facility gets to twice at attacking UFOs. So no update() function is needed, we just check to see if base has one of these as part of an “Alien Attack on X-Corp”.
  • Neural Shielding Facility : check: A base can have no more than one of these. Reduces the “visibility” of a base. So needs to be called when we calculate a base’s “visibility”. Again, no update() function is needed.

Common Facility Behaviour

  • Build cost
  • Build time
  • Size
  • canBuild(Base& base)
  • canDestroy(Base& base)
  • onfinishedBuilding(Base& base)
  • onDestroy(Base& base)

I’d propose the following set of classes for hooking facilities to bases.

(UML diagram attached, note that it doesn’t show member functions nor all attributes for classes.)

The basic idea is that the FacilityInfo classes are flyweights, holding the “class properties” (build cost, size, etc.) and functionality, but not the instance data. Actual instances of facilities are represented by the FacilityHandle class. Which holds build state.

The Base class owns a FloorPlan and a Capacities.

The FloorPlan is responsible for managing the FacilityHandles. Really, it just keeps track of the position of the facilities in the base (probably in an array) and their build state. (As you can guess, I haven’t quite figured out the exact division of responsibility between FacilityHandle and FloorPlan classes.) For performance reasons, the FloorPlan will probably also hold a list of “updateable” facilities. That is, facilities that need to get called on an update(game time). Currently it’s only the scan facilities, but it might be others later.

The Capacities is responsible for tracking the “storage capacities” granted by the facilities. As discussed above in Storage Facilities.

Facility.01.png

Link to comment
Share on other sites

Facility Class(es) design.

 

OK, here’s my plan for how we do facilities. Your input is requested. Once this is agreed, then I think these notes should be put into the design document, because they’re a work of genius.

Looks like a solid, thought through design.

I vote for the genius notes =b

Link to comment
Share on other sites

This looks really great.

 

I have one tiny suggestion for this issue:

 

For performance reasons, the FloorPlan will probably also hold a list of “updateable” facilities. That is, facilities that need to get called on an update(game time). Currently it’s only the scan facilities, but it might be others later.

What about making an 'UpdatableFacility' that has to implement an update function? Then have scan facilities use them as the base class. Then when we need a list of facilities to be updated we just check if they are children of this 'UpdatableFacility' class. If we need more facility types to be updated, we just use this class.

 

Here's a rough sketch of what I'm talking about to hopefully clarify.

-[FacilityInfo]
 -[UpdatableFacility]
-[ScanFacilityInfo]
-...Other facilities if needed...
 -[StorageFacilityInfo]
 -[DefenseFacilityInfo]
 -[UniqueFacilityInfo]

 

I think we need to come up with shorter name than 'UpdateableFacility', maybe 'UpdatedFacility'?

 

Just throwing an idea out.

Link to comment
Share on other sites

×
×
  • Create New...