Difference between revisions of "Buildings Model Quickpad"

From FreeOrionWiki
Jump to: navigation, search
(Building Enabling / Disabling)
(Solutions?)
Line 80: Line 80:
  
 
This prerequisite would be an additional requirement above and beyond being unlocked.  A particular technology would be required to be researched in order for the building ot be built.  An unlocked building could not be built if this, or any other, prerequisites are not met.
 
This prerequisite would be an additional requirement above and beyond being unlocked.  A particular technology would be required to be researched in order for the building ot be built.  An unlocked building could not be built if this, or any other, prerequisites are not met.
 +
 +
===New Effect: SetTimer, New Condition: TimerState ===
 +
 +
(To be fixed up...)
 +
 +
Set Timer: Sets building property: Timer, to natural number value (integer > 0).
 +
 +
Each turn, timer is reduced by 1 towards 0, or remains at 0 if already = 0.
 +
 +
TimerState condition has option:  <Activated>
 +
 +
<Activated>1</Activated> means condition matches objects whose timer = 0
 +
 +
<Activated>0</Activated> means condition matches objects whose timer > 0
 +
 +
===Optional: New Effect: SetRegister, New Condition: RegisterValue===
 +
 +
(To be fixed up...)
 +
 +
This extends and replaces the SetTimer and TimerState Conditions.
 +
 +
Each object would have (at least) one externally readable and settable value known as a register.  The value would be accessible like other object properties, as "Source.Register" or "Target.Register", for example.
 +
 +
The SetRegister effect would alter this value just like SetMeter alters meter values, using mathematic expressions where applicable, such as "Target.Register - 1", which would decrement the register by one each turn, replicating the functionality of a timer.
 +
 +
The RegisterValue would function just like the MeterValue condition.  <max> and <min> values would be specified, and all objects whose Register's value is within these ranges would be matched.

Revision as of 10:34, 20 December 2004

This is a draft pseudo-brainstorming attempt to resolve some issues with the current buildings model. Nothing (new) here has been passed.

Issues

The non-effects details of the buildings model need to be worked out. Some isses to consider include:

Prerequisites (non-Tech)

Besides the technologies that unlock a particular building, we may want to be able to restrict where and when a building can be produced. Possible restrictions include:

  • Requiring the presence of another building first
  • Requiring a particular special to be present, and/or be known to exists on or in the planet, system, empire or galaxy
  • Requiring a particular planetary environment, star colour, minimum population, meter values, etc. for a building to be produced
  • Future: Some sort of Civ3-like special resources model, of somewhat more complexity than the above requirements for particular specials

Limits

Similar to prerequisites, but opposite in effect, limits indicate when a particular building may not be built, despite all other requirements being met. Possible limits include:

  • A limit on the number of buildings of a particular type on or in a planet, system, empire or galaxy, or within a certain distance.

This could be implimented using some sort of "building stacking group", similar to the stacking groups used with techs.

Maintainance

We can already specify the maintainance cost for buildings, as indicated in the Effects page, but this idea needs to be extended to cover what happens if maintainance is not paid. This may be integrated with the following section, Building Enabling.

Building Enabling / Disabling

Buildings mostly (exclusively?) do their jobs through their effects groups, which already have activation and scope conditions. These are very useful and versatile, but they have some limitations that are problematic for buildings. In particular, we need ways to enable to enable or disable buildings' effects groups for reasons such as:

  • unpained maintainance
  • player choice (requiring UI integration)
  • technology prerequisites (new ones gained or previously known ones lost)
  • non-tech prerequisites, as discussed above
  • unmet limits, as discussed above
  • after a fixed delay, or at a certain time

Refinements

tzlaine is already working on a way for effects to alter building descriptions for the purpose of refinements.

Solutions?

A mix of new effects and conditions and non-effects methods will likely be needed to impliment the desired functionalitly.

New Condition: TechKnownToEmpire

This condition would match all objects owned (exclusively or not) by an empire which knows a particular tech. This would allow effects groups to be activated or not, or their scopes to include or not based on whether they or other empires know a particular tech. This would be useful for:

  • specials that only work if you know a particular tech, such as space anomalies that give bonuses
  • making buildings obsolete / partly obsolete after discovering a particular tech. A building could have one function, then stop the old or start new functions when a particular tech is discovered

Production Prerequisites: Other Buildings

This would function just like tech prerequisites, except for buildings. A new building can only be built (meaning started, worked on or both) if the prerequisite is met.

Ideally it would be possible to specify the range at which the prerequisite can be found:

  • same planet only
  • same system only
  • within X distance
  • within Y starlane jumps
  • anywhere in galaxy
  • owned by own empire / any empire, exclusively or inclusively
  • must be known about / may be not known about

Production Exclusions: Other Buildings

This would function in the exact opposite way from other building prerequisites. A new building cannot be built (meaning started, worked on or both) if the exclusion is met.

The same ranges as for Production Prerequisites: Other Buildings should apply.

Production Prerequisites: Specials

This would function just like Production Prerequisites: Other Buildings, except that the prerequisite would apply to specials.

Production Exclusions: Specials

This would function just like Production Exclusions: Other Buildings, except that the exclusion would apply to specials.

Optional: Production Prerequisites: Techs

This is distinct from the idea of a tech which unlocks / locks a particular building. With lock / unlock, the availablility of a building is set by an effect, and is on/off.

This prerequisite would be an additional requirement above and beyond being unlocked. A particular technology would be required to be researched in order for the building ot be built. An unlocked building could not be built if this, or any other, prerequisites are not met.

New Effect: SetTimer, New Condition: TimerState

(To be fixed up...)

Set Timer: Sets building property: Timer, to natural number value (integer > 0).

Each turn, timer is reduced by 1 towards 0, or remains at 0 if already = 0.

TimerState condition has option: <Activated>

<Activated>1</Activated> means condition matches objects whose timer = 0

<Activated>0</Activated> means condition matches objects whose timer > 0

Optional: New Effect: SetRegister, New Condition: RegisterValue

(To be fixed up...)

This extends and replaces the SetTimer and TimerState Conditions.

Each object would have (at least) one externally readable and settable value known as a register. The value would be accessible like other object properties, as "Source.Register" or "Target.Register", for example.

The SetRegister effect would alter this value just like SetMeter alters meter values, using mathematic expressions where applicable, such as "Target.Register - 1", which would decrement the register by one each turn, replicating the functionality of a timer.

The RegisterValue would function just like the MeterValue condition. <max> and <min> values would be specified, and all objects whose Register's value is within these ranges would be matched.