Improvements in MPG vs TOT

[reubene]

Line 377 of the RulesParser refers to ImprovementType.Pyramids as the first wonder index.
var firstWonderIndex = Rules.Improvements.First(i => i.Type == ImprovementType.Pyramids).Id;

this works for MPG but TOT has an additional improvement so in TOT this is going to the (Capitalization) instead which will break city improvements.

Is there a way to do this more flexibly? Do we know at this stage of parsing the rules if we're looking at TOT or MPG?

Perhaps we could base this on the name? Could we assume that the first wonder is the first thing after Capitalisation? Or perhaps the first after a city improvement that has brackets around the name?

[axx0]

I'll take a look at it.

[axx0]

Ok so it's the transporter thingie.
No of units, terrains, leaders, etc. however is the same in TOT/MGE (well there are more units in TOT but they appear at the end of the list so it's not really an issue).

Sadly, I've found a scenario where Capitalization is not in brackets so that option's off. Also the name Capitalization can be anything in scenarios, like Wealth, Harry Potter House, etc.

My suggestion is not to mess with interfaces too much and do this:

1. Add transporter to ImprovementType.cs at position 35 so we have a universal enum for both interfaces
2. At ProcessImprovements in RulesParser.cs count the number of values at the end of method.
3. If the number of values = 68 it's TOT and you don't have to do anything.
   However if the number of values = 67 it's MGE and in that case you just have to increase Type of all improvements after port facility by one:

            if (values.Length == 68)
            {
                Rules.Improvements.Where(i => (int)i.Type > 35).Select(i => i.Type += 1);
            }

That way the Transporter enum for MGE will be skipped. And you won't have to change ProcessEndWonders.
That's my suggestion but I haven't tested this.
Also this is ok if the no of improvements in all TOT scenarios =68, which should be the case but I'm not 100%.

[reubene]

Thanks for looking into it I think it might be useful to leave if flexible as I'd like our engine to be more mod-able than the original not less. I think the ImprovementTypes enum should probably be removed as it limits mod-ability of city improvements.

It has occurred to me that every wonder needs an entry in the ENDWONDER section. Perhaps the best way to work out where the first wonder is is to work the other way. If there are N entries in the ENDWONDER values array we apply those to the last N improvements. That way it won't matter how many improvements there actually are and modders will be free to add more if they need.

[reubene]

This would allow people to add more wonders too if they wanted to

[axx0]

It has occurred to me that every wonder needs an entry in the ENDWONDER section. Perhaps the best way to work out where the first wonder is is to work the other way. If there are N entries in the ENDWONDER values array we apply those to the last N improvements. That way it won't matter how many improvements there actually are and modders will be free to add more if they need.

Good that you've noticed that! I think it's a good approach.
Also if we remove improvementtype enum we'll probably have to remove other similar enums as well.

[axx0]

But if the enums are removed how will you know which logic to hook up individual wonders and improvements to?

[reubene]

Have a look at improvements.lua that's a ones I've already implemented no enum required, and it's lua so very easy for people to modify

[axx0]

ok yeah, you basically just need an index of an improvement