FreeOrion

As I mentioned here, viewtopic.php?p=17424#17424

There are some glaring omissions in the current model for buildings. We spent a lot of time working out effects, but forgot to deal with most of the non-effects details of buildings, aside from cost, build time, simple maintainance and a name and description.

In order to remedy that, I've written up a draft pseudobrainstorming wiki page of buildings model issues and possible solutions. It is here: http://www.freeorion.org/index.php/Buil ... l_Quickpad

Thoughts / comments? tzlaine / Aq?

edit: fixed wiki link from before it was changed...

Geoff the Medio wrote:As I mentioned here, viewtopic.php?p=17424#17424

There are some glaring omissions in the current model for buildings. We spent a lot of time working out effects, but forgot to deal with most of the non-effects details of buildings, aside from cost, build time, simple maintainance and a name and description.

In order to remedy that, I've written up a draft pseudobrainstorming wiki page of buildings model issues and possible solutions. It is here: http://www.freeorion.org/wiki/index.php ... l_Quickpad

Thoughts / comments? tzlaine / Aq?

Random collection of thoughts:

Not keen on the 'Register' property. Having temptingly non-specific properties like this just seems like a recipe for confusion , conflict and disaster. In other words, an OO nightmare. Either make it more specific, or allow a series of more general variables (i.e. something like the (hideous if you're into C) syntax of Source("SpecificRegister") defaulting to some number if unset previously).

Timer is just about o.k. since at least it pins the use down to the time domain. However <Activated>1</Activated> etc. should probably be replaced with synmoblic constants like <Activated>NonZero</Activated> etc. Otherwise we're just asking for some loon to write and effect based on <Activated>4</Acitvated>!

emrys wrote:Not keen on the 'Register' property. Having temptingly non-specific properties like this just seems like a recipe for confusion , conflict and disaster. In other words, an OO nightmare.

I suspect tzlaine will agree with you... I think he's mentioned dislike of overly general and thus hard to test and debug properties. Hence my making it optional.

However <Activated>1</Activated> etc. should probably be replaced with synmoblic constants like <Activated>NonZero</Activated> etc. Otherwise we're just asking for some loon to write and effect based on <Activated>4</Acitvated>!

tzlaine uses true = 1 and false = 0 in several other effects XML formats, so I'm going to stick with that convention unless he says otherwise.

(remainder edited based on noelte's comments)

For the TimerState condition, the values for the <activated> field would be 0 for false and any non-zero number for true. Putting 4 or any other non-zero number would work exactly the same as putting 1. So you wouldn't be able to hijack the TimerState condition to do anything unintended that way.

The same applies to the SetEnabling effect and Enabled condition.

Using numbers within <Activated>1</Activated> is the most easy way to do it (from a programmers point of view). BTW only 0 is taken as False any other value is True. But IMO we should use <Activated> True </Activated> and <Activated> False</Activated>

noelte wrote:Using numbers within <Activated>1</Activated> is the most easy way to do it (from a programmers point of view). BTW only 0 is taken as False any other value is True. But IMO we should use <Activated> True </Activated> and <Activated> False</Activated>

<pedantry> Using hard coded (meaningless) constants (e.g. '0' = false, '1'= true (or worse anynumber but 0 = true) is not a great move (for readability, maintenance, portability, clarity etc.). (It is VERY C though ) </pedantry>

<realism> If anyone saw the number of hardcoded, cyptic constants in my code, they'd have apoplexy!</realism>

Putting 4 or any other non-zero number would work exactly the same as putting 1. So you wouldn't be able to hijack the TimerState condition to do anything unintended that way.

Unintended? But I intended that incomprehensible weird behaviour to happen! The mere fact that nobody else knows what's going on is their problem, not mine... (Aren't you glad I'm not coding on this project)

Out of interest:
What is the difference between the time and register effects you propose?

Also what possible practical uses could they be used for?

What practical use would the galaxy turn condition have?

utilae wrote:What is the difference between the time and register effects you propose?

The time value, condition and effect would only be useful for counting time, while the register stuff would be much more versatile. With time, you can only set the value to a positive integer or 0, but the register can be set to any value. I suppose if you really wanted, you could use the SetTimer effect to set the timer to any value each turn, and if the optional TimerValue condition is used, be able to use it just like a register, but it's specifically named with "Timer", so it's clear that it's only intended for use as a timer. Timer would, however automatically decrement by 1 each turn.

Perhaps, if we wanted to avoid the misuse of timer, we could make the only effect that can alter it "ResetTimer" which sets the Timer value = 0. Then the TimerValue condition would be used to check if the timer value was with a certain range. This way, it would be impossible to misuse the timer like a general purpose register.

Also what possible practical uses could they be used for?

An event, or series of events, that occur over several turns could be made. Say I had a plague that progressed slowly over several turns, doing differing and repeated damage to population and health. Say I had a star that was about to impode... there could be a series of smaller events leading up to the big one. Say I had a building that could only be used once every 10 turns... this would allow the game to keep track of how long it had been since it was used.

What practical use would the galaxy turn condition have?

Timing the release of space monsters or ion storms so the players have a chance to build up and prepare. Scheduling all of the special events in a game scenario. Having an effect that changes in magnitude as a function of game turn. Having an effect that has changing chance of firing as a function of game turn.

Events (not yet in the game) will take care of effects that have a certain duration. And, yes, I do think the Register idea is just plain wrong.

tzlaine wrote:Events (not yet in the game) will take care of effects that have a certain duration.

Including disabling a building for N turns after a player activates its function (causing an event?), during which time the player would be unable to re-activate the function?

Will they be able to handle dynamic-length delays between effects? Eg. N turns between discrete events, not events that last M turns.

If so, that probably takes care of the timing issues.

I've updated the suggested solutions stuff on the wiki page.

The Timer stuff is still there until I know whether tzlaine's events will deal with all desired timing issues.

The Register stuff is gone.

I'd like some comments about the Production Prerequisites stuff (for buildings) here: http://www.freeorion.org/index.php/Buil ... requisites

What do we or don't we need for this?