Please read the design/effects document!

[Geoff the Medio]

If there is a pressing need to add a Technology-aware Condition, we can add one, but I currently have no such plans.

I don't know if it's a "pressing" need, but IMO such a condition is important to have. Don't drop everything to implement it ASAP, but we will need this eventually.

[tzlaine]

One more thing:

Under the building specification, there is only "Build cost". (unlike techs which have a research cost and research turns)

Does v.3 work differently now, or ???

I don't understand. What would the "time" be for a building? Do you mean the time it takes to build it?

[Geoff the Medio]

I don't understand. What would the "time" be for a building? Do you mean the time it takes to build it?

AFAIK, buildings and techs are both X RP / turn for Y turns... So buildings would require specification of both X and Y, just like techs have/do.

[tzlaine]

I don't understand. What would the "time" be for a building? Do you mean the time it takes to build it?

AFAIK, buildings and techs are both X RP / turn for Y turns... So buildings would require specification of both X and Y, just like techs have/do.

Ah. My mistake. The doc has been updated, and the code changed.

[drek]

For example, an effect on a building might have a 1% chance each turn of causing a "Pollution" special to be attached to a planet within raidus of effect.

RTFD.

I'll assume that's a yes. Sorry if it's a dumb question, I want to make certain I understand the specs before writing a bunch of malformed XML techs.

So if there are N objects in the game universe, the former will take time proportional to N, and the second will take time proportional to N squared! Use with caution.

Cool. None of the techs/buildings rattling around in my head use anything other than the "Self"--the distance conditions are hella lot more flexible than I orginally concieved. (though I guess you could use it to do some cool things: matching all objects in the same system as a planet with a specific special, for example.)

This can be acheived by making this Age tech have an Effect that changes the definition of the building in question to do nothing, or to work less well. See the FAQ if you don't follow me.

I'm certain this is a dumb question: where's the Faq?

EDIT: ok, the first post is the faq. I was looking around the wiki.

One last dumb question that's popped up:

EmpireAffiliation (and the ownership effects) uses an Empire ID parameter. What should be inputted into this field to indicate the Empire "owning" the tech/building/special in question?

[Geoff the Medio]

What should be inputted into this field to indicate the Empire "owning" the tech/building/special in question?

Probably Source.Owner

[drek]

Yeah, Geoff. It's right there in the expressions section, my eyes just glazed over it.

Thanks.

[drek]

Just finished my first real techs as practice for more difficult parts of the tree. The results are in the construction category, hopefully Geoff and/or Tzlaine can glance at them to make sure I got the right idea.

Some questions came up while I was trying things out:

1 Yet another dumb question: how do I make my building's effects non-stackable? Or is that the default? (If a player builds mutliple Megalithes with overlapping areas of effect, the bonus should only count once.)

2: YADQ: I've seen no examples of Techs and Buildings with multiple effectgroups in the documentation, and no "..." indicating that multiple effectgroups are possible. Can a tech/building/special have multple EffectsGroups (as I've done) or just one?

3: re: the string table. Can we include any formatting (such as HTML) or at very least line breaks? From the example, it appears that a line break indicates a new entry, and there's no quotation marks or markups delimitating the end/start of a string. I'm thinking of the nice descriptions that SMAC had for their techs: if you look at the text files for the descriptions they are nicely formatted via mark-ups.

Ultra-low priority suggestion for the future: tooltips and ledgers...I'm thinking a formatted string (like the sort of thing you'd feed into a printf statement) that spits out a description of what an effectsgroup has done to a given value.

[tzlaine]

Just finished my first real techs as practice for more difficult parts of the tree. The results are in the construction category, hopefully Geoff and/or Tzlaine can glance at them to make sure I got the right idea.

Some questions came up while I was trying things out:

1 Yet another dumb question: how do I make my building's effects non-stackable? Or is that the default? (If a player builds mutliple Megalithes with overlapping areas of effect, the bonus should only count once.)

Currently, the stacking issue is not addressed at all, except that you can't have more than one Special of a given type attached to the same object. The designers need to address this.

There are several options as I see it:

1) Everything stacks.

2) Stacking is not allowed based on Special/BuildingType, so that two Effects from the same kind of Special or two Effects from the same kind of BuildingType will not have double effect.

3) Stacking is not allowed based on some unique code associated with each Effect or EffectsGroup. So if two Effects/EffectsGroups have the code "WonderFarmBonus", only one of them will affect the target(s). This will mean greater control over which Specials and/or Effects/EffectsGroups will not stack, but is certain to complicate things for the designers.

2: YADQ: I've seen no examples of Techs and Buildings with multiple effectgroups in the documentation, and no "..." indicating that multiple effectgroups are possible. Can a tech/building/special have multple EffectsGroups (as I've done) or just one?

This is an oversight on my part; I'll support for multiples.

3: re: the string table. Can we include any formatting (such as HTML) or at very least line breaks? From the example, it appears that a line break indicates a new entry, and there's no quotation marks or markups delimitating the end/start of a string. I'm thinking of the nice descriptions that SMAC had for their techs: if you look at the text files for the descriptions they are nicely formatted via mark-ups.

You can insert "\n" anywhere you want a line break. You can also do quite a lot of formatting to the text, but it will be ugly. I'll put the formatting instructions in the FAQ.

Ultra-low priority suggestion for the future: tooltips and ledgers...I'm thinking a formatted string (like the sort of thing you'd feed into a printf statement) that spits out a description of what an effectsgroup has done to a given value.

I'm currently working on code that will spit out the description of an arbitrary EffectsGroup. This will be useful not only for verifying that your EffectsGroups do what you think they, do, but also for in-game encyclopedia entries and info dialogs on Specials, Techs, and BuildingTypes.

[drek]

Thanks for the reply, etc.

Currently, the stacking issue is not addressed at all, except that you can't have more than one Special of a given type attached to the same object. The designers need to address this.

In the orginal Geoff/Drek document, we used option #3. I'm cool with #2 or #3....probably Aq or Tyreth should make the decision.

I'm currently working on code that will spit out the description of an arbitrary EffectsGroup. This will be useful not only for verifying that your EffectsGroups do what you think they, do, but also for in-game encyclopedia entries and info dialogs on Specials, Techs, and BuildingTypes.

That sounds sweet. I was worried about little syntax errors cropping up here and there, and was thinking about a command line tool to verify my XML statements.

[Geoff the Medio]

Currently, the stacking issue is not addressed at all, except that you can't have more than one Special of a given type attached to the same object. The designers need to address this.

There was some stuff about a "Stacking Number" in the pre-implementation effects design stuff.

http://www.freeorion.org/wiki/index.php ... ing_Number

This is essentially the same as your #3, but with itegers instead of text codes. The codes probably make more sense though, so go with them. (Edit: posted simultaneously, if slowly, with drek...)

I think it would be sufficient for effect groups should to stack or not, given that activation and scope conditions apply to whole groups as well. (This contradicts the linked page, which had stacking numbers for each effect.)

A possibly useful variation would be to allow multiple stacking codes per effects group. An effects group would not stack with any other effects group with any of the same stacking codes.

[drek]

I think it would be sufficient for effect groups should to stack or not, given that activation and scope conditions apply to whole groups as well. (This contradicts the linked page, which had stacking numbers for each effect.)

Agreed.

[Aquitaine]

3) Stacking is not allowed based on some unique code associated with each Effect or EffectsGroup. So if two Effects/EffectsGroups have the code "WonderFarmBonus", only one of them will affect the target(s). This will mean greater control over which Specials and/or Effects/EffectsGroups will not stack, but is certain to complicate things for the designers.

This is ideal. It will be work to keep track of the stacktypes, but it gives us more flexibility.

[tzlaine]

3) Stacking is not allowed based on some unique code associated with each Effect or EffectsGroup. So if two Effects/EffectsGroups have the code "WonderFarmBonus", only one of them will affect the target(s). This will mean greater control over which Specials and/or Effects/EffectsGroups will not stack, but is certain to complicate things for the designers.

This is ideal. It will be work to keep track of the stacktypes, but it gives us more flexibility.

Consider it done. The EffectsGroup documentation has been updated to reflect this.

[Geoff the Medio]

Consider it done. The EffectsGroup documentation has been updated to reflect this.

Are we limited to one <stacking_group> tag per effects group?

eg. I want multiple copies of building A to not stack, and I want multiple copies of building B to not stack, and building C does the job of both A and B, so shouldn't stack with A's, B's or C's, but A's and B's should stack with eachother, as they do different things.

Also, thanks for being so quick with these changes / additions.