Feedback and Suggestions

[Nightinggale]

I just had an idea. What if traderoute transports delivers packages instead of yields? A package should then be a class containing:

• Destination city
• Yield type
• Yield amount

The transport can then store 30 lumber for city A and 20 for city B. The cities can be aware that they are getting those yields and will not cause other transports to deliver those as well, hence avoid overflowing the warehouse.

I'm not completely sure about the memory management. Storing a list of packages in this fashion might not be the most efficient. However this specific detail is not important for the concept.

 

[Kailric]

Would the Yields be stored on the Transport as usual? So that you can click it and see the Yield Units on board? Or would they be represented by numbers only?

 

[Nightinggale]

First of all, I didn't look at the forum since I posted the last post and just returned. I posted in another (non M:C) thread at the same time as you posted. Wicked timing

Would the Yields be stored on the Transport as usual? So that you can click it and see the Yield Units on board? Or would they be represented by numbers only?

I didn't get that far in planning. Clearly it has to be linked to whatever is in the transport. However for better efficiency I would likely to use the DoaNE system where multiple different yieldtypes can be stored in one slot as long as their total will not exceed the max number of yields for a slot. I think this approach is unavoidable if we really want automated transport for work without using 10% capacity and leave stuff behind due to being full at the same time. Manual transports do that occasionally while automated ones does this all the time. I can move 100 units of food or 3 tools. Either construction is delayed or people starve because I can't transport 3 tools and 97 food.

 

[Kailric]

I'm thinking a huge change like that would need to be an expansion all to itself as I bet there are tons of hidden repercussions. It would be best with a team (small one as that's all we got), I'd be up for it after the current version is tested thoroughly. I like the more realistic yield storage idea.

 

[Nightinggale]

I'd be up for it after the current version is tested thoroughly.

Agreed. Fixing CivEffects comes to my mind every day, but I have yet to clear my head, sit down and work on it. It works, but isn't bug free.

I like the more realistic yield storage idea.

We could copy the RaR warehouse approach as the code is clearly marked and shouldn't be too difficult to copy. We could also design our own system. Perhaps a modified RaR system. It might be a good idea to start a thread to brainstorm on what to do about it.

 

[Lib.Spi't]

And behold the doors shall upon to new knowledge!

Your welcome civfanatics!

 

[Kailric]

And behold the doors shall upon to new knowledge!

Your welcome civfanatics!

That's super cool news. Good job Lib, always the diplomat

 

[orlanth]

As requested here is a post with some initial thoughts for an eventual rework of buildinfos.xml and featureinfos.xml, let us know what you think!

(These would be nice to have but a low priority, for sometime later when Round Tuits are in abundance )

Motivation:
1) for mods with many Feature types (eg multiple types of Forest or Jungle), trying to apply a modifier for a class of Features becomes cumbersome due to listing every Feature separately in XML and displaying every Feature separately in the game interface. For example a production or combat bonus applying to all Forest tiles would be individually coded and redisplayed for Light Forest, Coniferous Forest, etc. This could be improved by creating Featurecategories which contain multiple Features; and allowing any modifiers (combat, production, feature clearing time, etc) to apply either to a Featurecategory or to an individual Feature. A similar approach could be used for grouping Terrains into several Terraincategories.

• IDK what the best approach would be, but I'd think the most straightforward and flexible way could be to use a Featurecategory.xml similar to how Buildingclass xml works for Buildings, and Featureinfos.xml could have a Featurecategory tag referring to this (which could also be NONE). Then any tags in Civeffects or Unitinfos that currently apply to a single Feature could be tweaked to accept either a Featurecategory or an individual Feature.

2) The structure of vanilla Buildinfos.xml is somewhat cumbersome because it lists a single Buildinfos entry for removing every Feature, and lists a single Buildinfos entry for building each Route/Improvement which in turn has FeatureStruct sub-entries for every possible Feature that could be removed (or not) when building that Route/Improvement, with separate subentries for iTime, Yields, and bRemove. This makes it hard to apply a general modifier relating to a Feature or Featurecategory. But having moddable tags in Buildinfos (and letting Buildinfos tags separately unlockable by CivEffects) would allow modders a lot of flexibility if this is done right. Anyway here are some thoughts:

• Some of this could be solved by Featurecategories as above, if any CivEffects modifiers that currently apply to a single Feature could be tweaked to accept either a Featurecategory or an individual Feature. If these are percentage modifiers, they could stack with the base <iTime>, <Yields>, and <iCost> in Buildinfos when that Buildinfo action gets used, allowing modders to more easily make general Civeffects that apply to a Featurecategory.
  
• In the existing FeatureStruct tag of buildinfos, let <FeatureType> apply either to a Featurecategory or to an individual Feature.
• In CivEffects, add a tag and bool that can unlock or obsolete access to a Buildinfos entry. Consider moving <TerrainMakesValids> and <FeatureMakesValids> and some of the <bRequires> bools from Improvementinfos.xml to Buildinfos.xml. (Separately of unlocking access to an Improvement, this would allow Civics/Techs to more flexibly lock/unlock different construction methods to build Improvements or do Feature Clearance on various combinations of Features and Terrains).

 

[Nightinggale]

1:
A feature category xml file should be doable and reusing the approach from CivEffects it should be possible to make a tag, which can be from either of 2 files.

2:
I wonder if we should make feature removal that complex. After all there can only be one feature on a plot at once, meaning in theory one remove feature buildInfo will be enough. It will then look up <iTime>, <Yields>, <iCost> and <Button> from feature, featureCategory, buildInfo in that order, moves to next if empty. CivEffects can then get allowRemoveFeature where it lists each feature and feature category.

In CivEffects, add a tag and bool that can unlock or obsolete access to a Buildinfos entry. Consider moving <TerrainMakesValids> and <FeatureMakesValids> from Improvementinfos.xml to Buildinfos.xml.

I totally agree that it should be possible to say invent a farm for plains and then later allow farming wetlands. Right now we need multiple improvements for that (I think), but somehow having multiple buildInfos for the same improvement doesn't sound good either.

Potential issues:

• different buildInfos can have different hotkeys, meaning it might not be the same key for the same improvement
• if one buildInfo is for plains and another is for light forest, then light forest on plains will have two buttons for the same improvement
• buildInfos are looped frequently. Having a nice and

I wonder if we should set some base info somewhere, which is automatically applied to the default CivEffects (the one given to all players). Next CivEffects can add allow combos, like farm+wetlands, which is then cached like so much else in CivEffects. When testing canBuild, it checks the player for allowImprovement and if the improvement is allowed for that terrain or feature. This would allow one BuildInfo for each improvement, but at the same time it can expand using CivEffects.

While this is about improvements, I would say we should do the same for routes, allowing techs, which unlocks building roads through swamps etc. Hills and peaks should also be mentioned here..... somehow.

Speaking of build speed, I'm wondering if the build time should be multiplied by 100 when reading xml, meaning if you write 5 in xml, it becomes 500 build points internally. Workers then apply 100 points each turn instead of 1, which means it still takes 5 turns to build. The difference is that if we say give +50% work speed, adding 1+50% = 1.5 -> 1(int rounding) will still make it take 5 turns while 100+50%=150 will take 3 turns. In other words it will allow speed modifiers other than just double speed. The same goes for improvement upgrade time (when worked). Right now it also suffers from this, meaning giving 10% faster upgrade (or 90%) doesn't do a thing. Upgrading with 110 (+10%) will in fact speed up an upgrade, which takes say 20 turns.

 

[Lib.Spi't]

In FTTW we also implemented worker promotions, unfortunately we were not able to get very deep into it, but we had a few, I think some increased build speed (another cool addition I wanted would be to reduce cost of building) and some allowed feature/improvement combos like village or farm on forest without destroying the forest. This could possibly be expanded to ideas like needing a promotion which allows farms on wetlands and the promotion could require a tech to unlock it. Allowing a similar situation to the military in M:C where your workers need to 'qualify' to do certain advanced things, like build in deserts or make 'town' style improvements or (insert variations here) these could then either be accessed by promotions or by professions, or by a combination of both.

 

[Nightinggale]

I wonder if adding units to the equation will make it too complex, both to code and execution time. If we ignore those issues, how should it work?

Let's try to make it simple and more specific with an example. Say we want to look at build farm.

• Base is set in improvement info and/or build info(current code)
• civeffects can unlock building in wetlands
• unit promotion can unlock building in forest

Here comes an interesting question: how is building in forests handled? Will it need both a civeffect unlock and a promotion, or should promotion be able to overwrite that it's not allowed by base/civeffects? What if it requires a promotion and later a civeffect can allow building it?

Besides I'm not sure I like the idea of civilian promotions. I fear it will result in micro management hell.

We still have journeyman on the TODO list and it will provide a list of the number of turns the unit has spend in each profession. We could divide the turn count with a constant (likely gamespeed related) and then use it as a modifier for work speed. Say the constant is 8, then the unit will gain +1% work speed for every 8 turns it has worked on building improvements, perhaps with a max cap.

Perhaps we can have improvements/combos, which requires a certain amount of turns in the Journeyman counter. Say we hardcode experts as 300 turns of experience (just to pick a semi-random number), then we can set improvements to require 300 turns, making them expert only, but we can also set it to 50 or 20, meaning it requires somebody with experience, but you don't have to go all the way to expert. Perhaps CivEffects can lower the number of turns required, possibly to 0.

Right now we need some way of figuring out what we want and how it should be controlled in XML. How to implement it in the DLL will have to come later.

 

[Lib.Spi't]

As a quick respone I would say that a civeffect trumps a promotion, in terms of unlocking as you can have a tech unlock a promo and then a later tech unlock an improvement(or subtype/terrain) later. Representing the ability becoming more widely/readily available.

(although are buildinfos handled in professions?)

 

[Nightinggale]

We can also turn it around and say everything is handled by promotions. CivEffects can then give free promotions to units and professions. This will likely require a bunch of promotions, which is why it would likely need worker promotions or it would slow down the game. Also it would require some cache in each unit.