[MOD] Medieval: Conquests

The northern region around scandinavia was the domain of the hanseatic league, who were quite good at making money, so there must be something we can buy and sell up there!

Patrician has got the goods on that!

Kailric said:

I was thinking about the "Shield Wall" here recently, and perhaps if two or more Shield Barring units are grouped they could form a "Shield Wall" thus, gaining Fortified Bonuses faster and or other bonuses.

Click to expand...

Sounds cool, but also slow. The unit awareness of other units on the plot is... well not ideal and it requires a lot of looping. Bonuses like that would likely require a proper cache in CvPlot. It should likely be a 2D JIT cache array and have a structure we need to design before actually applying such bonuses.

Kailric said:

So, perhaps instead of building a "Siege Engine", you build a "Siege Wagon". You then have Engineers that can assemble these Engines on site, and depending on your Techs, you get a menu of what you want to assemble.

Click to expand...

I would rather have one "Siege Wagon" for each type of engine. This unit can then move to a site where it deploys. Deploying a siege engine can be somewhat like travel state where the unit is jammed for a number of turns, except deployment will not hide the unit from the map. In deployed state, the unit can't move, but it can bombard (or whatever command we assign to it). Once you conquered the nearby city, you no longer need the siege engine. Depending on unitInfo and possibly tech, it could revert to a Siege Wagon again or it could be destroyed, giving a fraction of the build costs to the nearby city.

Siege Engines and Siege Wagons should have some civilian features, such as they can be captured by enemy troops and will not defend if attacked (use other units on the same plot for that!).

Alternative idea
Maybe we can make a "Siege Engine Improvement", which can only be build by a Siege Wagon (which is more or less just a wagon with the yields needed for the construction). Construction of this type of improvement can only be done by sacrificing the Siege Wagon and then the turn timer can count by units with "siege engine building profession" continues the improvement.

Once build, instead of replacing the improvement, a unit magically appears.

I think this is as close to real life siege engines as we can get while keeping the coding process realistic. The improvement approach is likely more tricky to code and it leaves issues such as plots with half build siege engines with no graphical display and stuff like that. I think the AI prefers the first option as well.

Kailric said:

Right now we don't have any Civ Specific Buildings, Units, or Professions but this would certainly be a nice addition.

Click to expand...

Civ4 relies on classes to do that, like a civ specific building replaces another building of the same class. Professions doesn't have a system like that and it will likely be way too much work to implement.

We should use civ specific units though. Right now we have peasant and Arab peasant. I see no reason why they shouldn't have the same UnitClass. We have a few units where sharing UnitClass would make sense.

Writing this gives me an idea. I have written a function for CvPlayer where you give it a building/unit class and it returns the ID of the building/unit the player in question uses. Ok, technically that's two functions and they are only in CivEffects so far.
If we take this one step further, it will no longer be a frontend to CivilizationInfo, but rather it can merge this info with other sources.

My idea is that the declaration of which unit to use for each UnitClass can also be set in traits. That way we can add TRAIT_MUSLIM (as we have talked about for other purposes) and then this trait changes all units to their Muslim versions. This mean those overwrites are set in that trait (one location) instead of CivInfo for all of the affected civs.

Lib.Spi't said:

The northern region around scandinavia was the domain of the hanseatic league, who were quite good at making money, so there must be something we can buy and sell up there!

Click to expand...

Not true. They were in northern Germany and Bergen in Norway. The scandinavians generally viewed them as enemies and a serious threat.

Having said that, they are still a valid location for a trade screen.

Nightinggale said:

Sounds cool, but also slow. The unit awareness of other units on the plot is... well not ideal and it requires a lot of looping. Bonuses like that would likely require a proper cache in CvPlot. It should likely be a 2D JIT cache array and have a structure we need to design before actually applying such bonuses.

Click to expand...

This can be handled easily actually, Units are setup in CvSelectionGroups and Each unit has one. In fact Players Own SelectionGroups, and these are cycled each turn, which in turn cycle the Units in the SelectiongGroup and doTurn() on them.

SelectionGroups keeps track of every unit in the group and so this command can be Group specific. We already have commands to form groups, so we can use that also to form "armies" that have additional commands based on attributes of the group such as "Shield Wall Status". All these things can be cached in SelectionGroups so for a Shield Wall command; each time a unit joins a group that can "Shield Wall", the Group gains 1 point in Shield Wall, once this reaches 2 (or however we setup the rules) you can then issue the Command to Form Shield Wall.

By the way, even Single Units have a SelectionGroup; getNumUnits() = 1.

Nightinggale said:

I would rather have one "Siege Wagon" for each type of engine. This unit can then move to a site where it deploys. Deploying a siege engine can be somewhat like travel state where the unit is jammed for a number of turns, except deployment will not hide the unit from the map. In deployed state, the unit can't move, but it can bombard (or whatever command we assign to it). Once you conquered the nearby city, you no longer need the siege engine. Depending on unitInfo and possibly tech, it could revert to a Siege Wagon again or it could be destroyed, giving a fraction of the build costs to the nearby city.

Siege Engines and Siege Wagons should have some civilian features, such as they can be captured by enemy troops and will not defend if attacked (use other units on the same plot for that!).

Alternative idea
Maybe we can make a "Siege Engine Improvement", which can only be build by a Siege Wagon (which is more or less just a wagon with the yields needed for the construction). Construction of this type of improvement can only be done by sacrificing the Siege Wagon and then the turn timer can count by units with "siege engine building profession" continues the improvement.

Click to expand...

I've thought about similar ideas as well. Let's not lose these ideas and we can go over them again when we get to this stage in development.

Kailric said:

This can be handled easily actually, Units are setup in CvSelectionGroups and Each unit has one.

Click to expand...

I know, but I don't like those for this purpose. This mean if we say have a bonus if we have two units with a specific feature, the bonus will apply if they are in the same group. However if they are both on the same plot, but not in the same group, they will not gain the bonus. I want the bonus to be plot based rather than group based to avoid issues with losing bonuses because the group breaks up without you noticing because they are still on the same plot.

I have been thinking a bit about a cache for this purpose in CvPlot and it is not that tricky after all.

What we do is we make a 2D JIT array in CvPlot. This is a vector of JIT arrays. The length of the vector should be MAX_PLAYERS, meaning there is a JIT array for each player. The JIT array is then a new JIT array type, say PLOT_CACHE.

PLOT_CACHE then states the different effects we want to count. Units can then be added/removed with the vanilla iChange = 1/-1 system.
When adding a unit, it goes though the length of PLOT_CACHE and adds iChange if the category is valid for the unit in question. Changing between 0 and 1 can then activate some trigger functions.

The length of PLOT_CACHE can then be set by an enum where we defined both length (NUM_something) as well as each type. The different types could be numUnits, numMilitaryUnits, unitsWithHealOther, ShieldWall and so on.
numMilitaryUnits can trigger stuff like breaking plotgroups.

This isn't saved, but rather recalculated on load. It's just a matter of looping all plots and add all units on each plot. Alternatively loop all players and then loop all units (that might be faster).

I kind of like this approach since once it is in place, adding new types to cache is just adding to the enum and then update the addUnit function to apply the new counted type (will possibly assert if it doesn't update the entire enum). This makes the cache modder friendly and we can add new unit features to the cache easily even though we haven't considered those features yet.

I think I will make this cache once I'm done with CivEffects. This cache does in fact look quite useful for quick updating of healRate and PlotGroups. I'm sure there are other features too, which could make good use of it, but those two are what I can think of offhand.

The idea of group specific rather than plot specific 'army groups' could be interesting. (AI, coding and performance permitting).

We could then have it so you form a group as an army and they interact with each other and no one else.

Costs of upkeep and such could then be calculated by group(army) size, and even composition, so a larger army becomes exponentially more expensive, techs and the like could mitigate cost for larger armies, and allow larger amounts of things like cavalry at cheaper rates and such.

This could make a whole new decision process of composition of armies, costs with increasing/decreasing benefits and effects. Untrained could weaken trained units when mixed, larger armies could recieve negative effects based on organisation problems, etc.

It would require a lot of work, but it could be a very interesting concept that increases and decreases stack strengths, so the biggest stack of one type of unit could hve an underlying weakness.

Just a thought to consider when deciding the tile vs group decision.

I really don't like selection groups because the GUI for making a group is horrible. If we had a commander unit, which units could attach to and the commander has a window to "pick up" or "disconnect" units, then it would be a different matter. In fact that could be really interesting if such an army would act as a single unit and go to combat as a single unit (requires a lot of work!).

Perhaps we don't need commanders as such, but rather just a "form army" button, which declares a unit "flagship", which other units can attach to. The core idea is that you need better control over which units group with which units without messing up like group selection can easily do.

However I still want the plot cache. Caching number of units, which can block plotgroups as well as units, which can heal will improve performance in existing features. Implementing the plot cache will not prevent us from making group based combat later, but it will be later.

I really like the idea of "Group Combat" and it is one thing I will be looking into for the Military Expansion. As we all know, when different Unit types worked together they made a much better force to reckon with, I've been calling it "Combined Arms". There is also already the option in the game to have your units fight as a Group, which does combat all at once, perhaps this could be detailed to fit our own desires.

But yeah, we would need to build an interface for it, but the SelectionGroup is set up perfect for a good start on this and it already has SelectionGroupAI so we can adapt the AI I believe to use this concept as well pretty easily. I don't want to spend much time thinking through this yet but I am sure we could come up with something that is unique and fun.

The "plot cache" is a great idea also, and I like it best for the potential to improve AI decisions, so I'm all for that as well.

I have had it with the silly exe weirdness. Every time we try to do something interesting, we run into problems with the exe and who knows what to do to fix it? The BTS guys have solved a bunch of issues and due to the exe not being 100% the same, we can't use those fixes

Another issue is the poor user base of Colonization. RoM has 157 translators while we have... well none. Using BTS as a base instead of Colo appears to attract more modders. If we look around the colo mods, we see that I'm pretty much alone at the moment, not only for M:C, but for colo modding in general. If I didn't mod, colo modding would be more or less dead right now.

I see no alternative to moving to BTS. While it may not solve all problems, it will help a lot. The question is if M:C can survive a move or if I should switch mod. Considering that the first mentioning of moving a colo mod into BTS was in 2008 and so far nobody have done it, I know what I'm up against. However it's not like BTS mods would refuse my help

I feel your pain, brother. We got started modding too late in the game and missed out on the frenzy.

M:C still gets downloads every day and I aim to keep working on it to get it in a more polished state.

Starting fresh from Civ4 is just out of my scope at the moment. Even so, you would want to survey all the popular mods and then decided which one would work best as a base to host all our ideas. May as well check out Civ5 and see how moddable it is as well. Are the hard core players sticking with Civ5, or have they come back to Civ4, or found something else?

Anyway, the Professions, Trade Screens and the Trade economy would need to be ported if you even want to come close to the same feel, and those three things would be a huge merge. The Techs and Civics I ported where simple ports really, as Col already had Civics. FFs would be a mute thing to port, it's not really a game changer and more of a side quest, but it would be simple port I bet if you piggy backed on Techs.

Second Anyway, while it seems doable on paper, the implementation would be grand and I can't afford to throw my hat in at the moment.

PS Steam gets more attention from Col than these forums do, there is still a huge player base out there. I just now seen where Steam has uploaded the classic version. I'll have to get that for sure, and relish in the nostalgia.

When I get this mod in a more polished state I plan on going on a massive promotion campaign to draw peoples attention to it and see what happens from there.

Yeah, I can understand the frustration Night, even if I can't understand most of what you say on a daily post basis!!

I think you have hit the kind of wall most of us idiots hit all the time with modding, we have an idea that the game can't support. (or in my and the other idiots case we can't make it support)

You then face the dilemma of do I stop (and lose all I have done before) do I compromise (scaling back the idea, or abandoning that part and going for others), do I start again (move to a different game/engine/concept).

That is just a question you have to answer for yourself, is the .exe blocking just one of your ideas, all your ideas, most of your ideas, etc.

You once asked if I would consider moving FTTW over to col. and I had to answer no, because I had come too far, and put in too much to move and start again. (As well as relearn and rethink how to add everything, when adding in the bits I understand is already exhausting!!)

Interest in something is always hard to gauge, some people are interested, but feel they have nothing to offer, so watch quietly, then one day decide to take the plunge.

Kail is right, we all three of us joined the party at the 'end of the golden era' of cIV/Col. Modding, it is not down and out yet, and new people arrive and do interesting and unexpected things, like the three of us. Some people (I think particularly graphic/artisitic modders) moved on to the next gen. of Civ, some went and came back.

The thing with Col. and therefore M:C etc. is that I can't think of another strategy game that is like it. One that takes the Economic/Industry detail, and pairs it with empire building in detail, I can think of games that come close in some parts, but not all parts. (War/Diplomacy/City Founding/etc.)

So I would be sad to lose all of the things you could do, because you can't achieve all the things you want to.

It is actually quite funny, that many of the ideas I would like to see in FTTW, are like things that are in Col.

Detail in production goods, that feed into unit production, etc. More detail in 'individual units and citizens', etc. The ability to create supply chains that flow goods from have spots to need spots, or centres of power, etc.

Many of the things I want to see in M:C/Col Mods(WHM) are things that are in Bts. (Air Power, connected(plot group style,) cities that share effects, health/happiness/corruption 'scale management'.

It is like making two games in different bodies but with the same soul. Both being different but having so much of the same essence that, for me, seems to get lost in so many games...

In many ways I almost think you need to go off and build your own game engine, rather than being a modder, I mean lets face it you have more or less rebuilt the civ engine and the way it works anyway!

You could be the architect of a whole new modders 'paradise' game engine!

One that maximises the power of minimal knowledge!

We lonely few have to stay the course to build the kind of game that carries joy and accessibility in 'depth' of game play!

I absolutely love the fact that nobody spotted that I made a post like that on the first of April.


The thing I said about the exe being stupid and that some problems would be solved by moving to BTS is true though, but that isn't the same as I'm leaving M:C. It's just something I added to make it sound at least a bit convincing. Maybe I overdid the convincing part, but that didn't make it any less fun for me

Kailric said:

Anyway, the Professions, Trade Screens and the Trade economy would need to be ported if you even want to come close to the same feel, and those three things would be a huge merge.

Click to expand...

Those are in the DLL, not the exe. If we move to BTS, the only realistic approach is to get the BTS exe to accept our DLL code. At one point I tried getting BTS to load M:C in a debugger just to see what happened (learning about exe behaviour). It failed to detect the file and at that time I didn't look further into that. Now that I think about it, if the culprit for that problem is found, it would be likely that the solution to run M:C in BTS is possible as well.

To be honest I haven't thought much about it. I just noticed an April's fool article in the newspaper and figured I better come up with something fast and moving to BTS was the first thing, which came to my mind. However it is theoretically possible and maybe I really should look into it.

Moving the DLL to civ5 is out of the question. Colo is essentially a BTS mod and most of the code is reused. Civ5 is an entirely different engine. This mean just moving the DLL code isn't an option and I would not consider it at all.

Well done, you got me! (and unless he was in on it, Kail too. He sent me a PM, to share his concern and his intention to remain committed! Which I read before reading your post!!)

I even remember looking at the date of the posts while reading/writing today, although I am so knackered right now that the concept of April Fools just failed to land in my mind!

I have to say though, the idea of bringing col and Bts 'together' is a very intriguing one..

It would be fascinating just to know what really is 'different' between Bts and Col. and how 'seperate' they really are.
We all know that they share the civ4 engine, we just don't know exactly what they did to that engine to make Col.

Is it irreparably 'broken' or not?

Like I said, what I love about the two games is the things I would love to see in the other!

You sorry dog Good one, it made me chuckle. Regardless, you made some valid points, and if we where just now discussing what engine to base M:C on, I would be tempted to go with Civ4. It would be interesting to see just what all it would take to start such a mod. I wouldn't ever abandon M:C, but I may be interested in helping some with such a mod.

One big question, does Civ4 have a way to make units Disappear, aka Live Among Villages, Travel to Europe, etc? We would really need a way to do this and Col has this built in.

Let's think for a min...

Adding Europe Tiles-> this seems like an easy addition, you are simply adding new variables to plots and make them colored. Once you have Europe tiles and a way for Units to enter a Travel State, adding the Trade Screens would be easy.

Professions-> this may require to port all the Profession.cpp files (I think Night added those), add the commands for changing professions, the XML values, Art, and the AI, etc. This would be a big task but not difficult perhaps. Not sure how easy it is to change Art in Civ4 though.

Yields-> this would require the most work as you would have to mod the entire city screen. Perhaps if you first separated the City screen in M:C to its own file, this would be easier to do. Then you would have to add all the AI for yields and such. The good part is it is all written already. You would just have to add it and make it work for Civ4.

The task would be daunting no doubt.

Lib.Spi't said:

It would be fascinating just to know what really is 'different' between Bts and Col. and how 'seperate' they really are.
We all know that they share the civ4 engine, we just don't know exactly what they did to that engine to make Col.

Is it irreparably 'broken' or not?

Click to expand...

Based on what I have discovered so far (not counting DLL only differences):

• BTS handles GameFont ID generation in DLL while colo does that in the exe
  Once the exe is done setting incorrect IDs, I added a function, which does basically what BTS does
• plotgroup pathfinding is only in BTS
  I made a workaround, which can only handles roads, not rivers and plot types
• Colo is stuck with 1 byte fonts while BTS can use unicode
  RoM added this by using the Japanese exe, an approach which could work with colo as well providing we could get hold of the Japanese exe from the disc version

I think I'm missing something great here, but simply put, from what I can tell, BTS has services we want in the exe while colo doesn't provide exe services we will miss.

Kailric said:

One big question, does Civ4 have a way to make units Disappear, aka Live Among Villages, Travel to Europe, etc? We would really need a way to do this and Col has this built in.

Click to expand...

That's a DLL feature, which mean yes we can do that. Hiding it from the GUI is... well if BTS can't do that, we can just mark the unit graphics dirty and when the exe asks for the graphics, we return an empty graphic placeholder. For all we know, this could be what already happens in the DLL right now (I didn't check)

Kailric said:

Professions-> this may require to port all the Profession.cpp files (I think Night added those), add the commands for changing professions, the XML values, Art, and the AI, etc. This would be a big task but not difficult perhaps. Not sure how easy it is to change Art in Civ4 though.

Click to expand...

Profession art might actually be an issue and it might not. It depends on the implementation. If I remember correctly, the exe is told, which is the unit on the plot and then it asks for the graphics for that unit. Even if the exe has no knowledge of professions, we can just return different graphics based on profession. In fact I think that is how colo did it. The only knowledge the exe has of professions is the cache XML I disabled.

It doesn't matter how we placed the files (but yes, I copied CvProfessionInfo to h/cpp files of its own. We need to organize the code better). If we ever use BTS, we shouldn't merge with BTS vanilla or anything like that. It is critical that the BTS exe accepts our DLL file as it is (or with minor changes).

For the graphics changing, I know it changes some graphics based on era. Workers become 'modern workers' and buildings change. Also I know bts (or a mod) added graphics changes for promotions, not sure how detailed that is.

I mean technically bts should be able to do everything that Col. can do as it is the same engine, unless there is some fundamental exe voodoo that we cannot access that handles some key 'element' of the transformation.

Well, if we get M:C to a more polished state, I just may look more into this myself. Starting with what looks like the most difficult part, then working down. If all can be done, just may be worth it. And Lib is right, Col has such a unique style to it and to be turn based as well. So, it will be around for a long time.

I wrote a small perl script to compare the functions the exe calls in the DLL. To be more precise, it lists what is called in BTS and what is called in Colonization. If it calls the function in both, it will not be listed here. I attached a a rar file with the full list.

I tried sorting the function names according to which class they belong to, but it for some reason made empty classes appear and the file became twice as long. Apart from that, it appears to work just fine.

Example of the output (CvUnit)

The list is somewhat longer than expected and I wonder if moving to BTS really is such a good idea.

Some of those seem obvious, others are...strange.

Like these:
enum CivilizationTypes CvUnit::getCivilizationType(void)
void CvUnit::setPromotionReady(bool)
bool CvUnit::canFortify(class CvPlot const *)
bool CvUnit::canSleep(class CvPlot const *)
bool CvUnit::isGroupHead(void)
bool CvUnit::isFortifyable(void)

Why do things like this exist in Col and not Civ...

Others like
IsOnMap I can see about being related to the trade screens/city screens, etc.

Lib.Spi't said:

Why do things like this exist in Col and not Civ...

Click to expand...

canSleep and canFortify exist in both, which makes sense. The real question is what kind of code is there in the Colo exe, which requires this knowledge
Nomatter how I view it, those functions should be pure DLL/python. I can't think of a single reason why the exe would need this info. If it is fortified, the DLL should provide the fortified graphics and even if that the exe does that check, the exe should care for if it is fortified, not if it can be fortified at some point, but not right now.

In fact a lot of the functions shouldn't be in the exe realm. For instance CvUnit::canAirAttack() makes sense to have in the DLL, but why would the exe care for that? The DLL decides if combat should take place or not.

Functions, which makes perfect sense to be interesting for the exe would be CvUnit::shouldShowEnemyGlow() and CvUnit::getAnimationMaxSpeed(). However this brings an interesting question: why isn't the colo exe using those functions?