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 wrote:If there is a pressing need to add a Technology-aware Condition, we can add one, but I currently have no such plans.
Please read the design/effects document!
Moderators: Oberlus, Committer
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Ah. My mistake. The doc has been updated, and the code changed.Geoff the Medio wrote: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 wrote:I don't understand. What would the "time" be for a building? Do you mean the time it takes to build it?
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.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.
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.)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.
I'm certain this is a dumb question: where's the Faq?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.
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
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
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.
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.
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.drek wrote: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.)
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.
This is an oversight on my part; I'll support for multiples.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?
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.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.
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.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.
Thanks for the reply, etc.
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.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.
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.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.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
There was some stuff about a "Stacking Number" in the pre-implementation effects design stuff.tzlaine wrote: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.
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.
This is ideal. It will be work to keep track of the stacktypes, but it gives us more flexibility.tzlaine wrote: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.
Surprise and Terror! I am greeted by the smooth and hostile face of our old enemy, the Hootmans! No... the Huge-glands, no, I remember, the Hunams!
Consider it done. The EffectsGroup documentation has been updated to reflect this.Aquitaine wrote:This is ideal. It will be work to keep track of the stacktypes, but it gives us more flexibility.tzlaine wrote: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.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Are we limited to one <stacking_group> tag per effects group?tzlaine wrote:Consider it done. The EffectsGroup documentation has been updated to reflect this.
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.