forum.freeciv.org

effects.ruleset is a monstrous file, difficult to navigate and thus edit or even understand. I propose breaking up effects.ruleset into 5 different files: effects.ruleset, effects_technology.ruleset, effects_government.ruleset, effects_improvement.ruleset, and effects_wonder.ruleset (and ai_effects.ruleset too, of course)

As a general rule, the 'anchor' which is the most active determiner if an effect should even exist should be responsible for placement of an effect into one of the files.
Wonder should generally trump Improvement, Improvement should trump Government, Government should trump Technology, Technology trumps none of the others, and the remainder remain in the original file.

Wonders are listed under their appropriate buildings. Wonders generally trump Improvements when placing effects, but only if both are equal. Wonder negations do not trump Improvement positions. (ex: City Walls effect should still be placed with improvements with other City Wall effects, despite being negated by Great Wall)

Improvements are listed under their appropriate buildings. Improvements always trump governments when placing effects, as many Improvements have different effects under each government. (ex: cathedral_2 effects of -1 content requires cathedral(imp), communism(gov), and negate with mike's chapel(won) and should be placed with Improvement effects)

Most Governments are listed under their appropriate governments. A couple also have technology requirements, but as government is an active choice and technology is passive, government requirement always trumps tech requirement in placement. (ex: partisan communism effect should be placed with governments rather than technology)

Technology classification is simple. All remaining effects with technology requirements get technology placement.

Any effects with none of these requirement types remain in effects.ruleset.

I agree effects.ruleset is difficult to manage.

I don't think there's anything stopping disciplined ruleset authors following the organisation you suggest, either as sections within effects.ruleset, or as separate files with *include? The only way I could think that Freeciv programs could help is ruledit writing out effects in this way, and possibly the server trying to enforce the convention when loading rulesets.

I fear that the complexity of the relationships is going to make some reasoning and transformation hard to perform in any flat file representation, though. I mocked up another approach to managing that complexity in the ruledit UI (PDF), in a post to freeciv-dev some time ago.

If you can include, then yeah, this is pretty much taken care of.

In the file itself, the governments, improvements, and wonders themselves are MOSTLY sorted like this, with the occasional other bit in the midst.
It's the sheer, obnoxious length of the thing that makes it so hard to use. Dragging the scrollbar is pretty much useless, and the page-up/down buttons take forever to get anywhere.
Finding any one thing, especially anything that's not a government, improvement, or wonder is spread out and annoying. It's worse if you're looking for things in general instead of a specific thing.
The *include (like how ai_effects.ruleset is added) is indeed how I was thinking.
Of the list, Wonders are 441 lines, Improvements are 999, Governments are 574, Techs are 76, and the rest are 236.

I'm also thinking that building negations in general shouldn't be used for placement. While wonders negating improvements is an obvious exception, I can't really think of a good reason to have buildings, governments, or technologies used to negate effects instead of just making completely separate effect(s).

I notice the Lighthouse unusually has the opposite relation with the Port Facility (In Classic ruleset, at least). Should the Lighthouse/Port Facility relationship be reversed for stylistic reasons? No other wonder is negated by an improvement unless that improvement is superior (namely hoover dam by solar plant).

Also, how do obsoletions work? Do they effectively make the building considered no longer present as far as effects are concerned?


The 2.6 ruledit hasn't seemed very useful thus far, I tend to do Everything in Notepad++ (Which is amazing).
Your mockup there looks like it would be good. Horizontal display of properties wouldn't cut it in other files, though.
How about this for a UI setup:
You may want to collapse it all the way down differently. Have the default view be a 'collapsed' mode.
All the selection heads would be displayed on the left side, one per row, with no spacing, and only the currently selected section would show its props on the right side.
On the right side, the first column would contain the properties (Effect, Increment, Reqs in effects.ruleset).
Second column would contain the values for everything but requirements on the same row as the property.
Note that some,
The 'Reqs' property row would instead list the requirement headers on the second, third, fourth, and optionally, fifth, and sixth rows (Type, Name, Range, <Present>, <Survives>).
Requirements would use the rows below the 'Reqs' property row, and use the second, third, fourth, and optionally fifth, and sixth rows.
There would always be an extra row after the last filled requirements row.(for the selected section)
Note some of these could have dropdown boxes filled with all the available options, in addition to allowing manual entry.

There would also be an 'expanded' view. It primarily differs in that the right side is displayed for every section head, meaning that the section heads have to be placed down below the right side of the previous section head. (kinda like how your mockup has it, only Effects, Increment, Reqs, and each Type would each take up separate rows.)

Adding an entirely new section would probably have to use a button (Insert Section), along with two buttons for reordering sections (Move Section Up, Move Section Down), and a final button to remove a section (Delete Section). Each different section type in a file would be navigated separately via a dropdown menu. (effects would have only one, but terrain.ruleset has several section types)

JTN wrote:The only way I could think that Freeciv programs could help is ruledit writing out effects in this way

Some very common stuff used in many rulesets could be exported to an include-file in misc, e.g., the timeline. With the experimental tech costs (3+4) the normal timeline could be replaced, I think it should be slightly slower.

GriffonSpade wrote:I'm also thinking that building negations in general shouldn't be used for placement. While wonders negating improvements is an obvious exception, I can't really think of a good reason to have buildings, governments, or technologies used to negate effects instead of just making completely separate effect(s).

I'm not sure what you mean. Can you provide a concrete example?

JTN wrote:

GriffonSpade wrote: I'm also thinking that building negations in general shouldn't be used for placement. While wonders negating improvements is an obvious exception, I can't really think of a good reason to have buildings, governments, or technologies used to negate effects instead of just making completely separate effect(s).

I'm not sure what you mean. Can you provide a concrete example?

Hrm, while it held true with the government example I was originally thinking of, I realized it didn't make as much sense with other things. Not necessarily inapplicable, but less certain. Mind, it's all pretty well academic at this point, as far as I know. Classic, at least, doesn't have any of these issues.

Instead:
1) {Government Position} Governments shouldn't be used as negatives.
Reason: Governments aren't a check list, they're a single option. Everything is in comparison to other individual governments, not 'no government'
2) {Positive Anchor} Everything with requirements should have a positive anchor.
3) {Positive Preference} Don't use negatives for placement, unless there are no positives for Tech, Gov, or Building.
4) {Negative Hierarchy} If negatives are used for placement, normal hierarchy rules apply
5) {Hierarchal Negation} If there are multiple negatives present in a situation where negation is not desired, replace it with a hierarchy for the anchors, and the 'lower' effects would be negated in their entries by 'higher' effects.

This was the original example I was making:

If you wanted, say, Technology [Horseback Riding] to give a +1 bonus to city center tile's trade, but only if there's no [Airport] improvement.
Instead of having
[Horseback Riding] <TRUE>, [Airport] <FALSE> +1 trade
Instead have two separate effects:
[Horseback Riding] +1 trade
[Airport], [Horseback Riding] -1 trade.

Upon making the example, I realized the first one is clear and concise.

For a bonus like this, I think I'd go with the first one, since the anchor is very clearly the tech [Horseback Riding]. I would still group it with Technology, though.

positive anchor example:

If you wanted: -1 production unless you know tech [Machine Tools].
It would not use
[Machine Tools]<FALSE> -1 production
There is no positive anchor here.
Instead it would have two separate effects:
[Unconditional] -1 production
[Machine Tools] +1 production.

hierarchy negation example:

Spoilage penalty, -1 food unless [Refrigeration], [Granary], or [Pyramid] is present.
Instead of having
[Refrigeration]<FALSE>, [Granary]<FALSE>, [Pyramid]<FALSE> -1 food
Instead it would have 4 effects:
[Unconditional] -1 food
[Refrigeration], [Granary]<FALSE>, [Pyramid]<FALSE> +1 food
[Granary], [Pyramid]<FALSE> +1 food
[Pyramid] +1 food

Any changes like these should take in to account what it does for the ruleset editor development. We don't want to make it harder to go forward with ruledit.

cazfi wrote:Any changes like these should take in to account what it does for the ruleset editor development. We don't want to make it harder to go forward with ruledit.

Well, having a good rule editor might very well make it all moot. If there were an ability to filter both by requirement type and individual requirement, it'd make finding things extremely easy. Then maybe an option to block out any negated requirement types.

Some rearrangements can still be short-term solution to make ruleset editing easier. Fully functional ruledit is likely to be several versions ahead.

2.6 can handle:
- Renaming Techs, Buildings, Units
- Reordering tech-tree (but not completely adding or removing techs)
- Show some statistics about the ruleset (number of techs, buildings, ...)

3.0 main goal is to make rulesets saved from the ruledit more human-readable, so that one can edit the same ruleset both manually and with it.