[MOD] Medieval: Conquests

[Nightinggale]

Great. I'm idle modding this mod for a week and people start asking if the mod is dead

Due to major internal rewrites there has not been any stable releases in quite a while. It will get a new stable release when it's ready and while I believe in not waiting too long between releases, releasing a stable version prematurely is quite bad as it would be unstable and possibly no fun to play.

 

[Kailric]

Great. I'm idle modding this mod for a week and people start asking if the mod is dead

Due to major internal rewrites there has not been any stable releases in quite a while. It will get a new stable release when it's ready and while I believe in not waiting too long between releases, releasing a stable version prematurely is quite bad as it would be unstable and possibly no fun to play.

It's alive, it's alive!!!

Yes, it is still active, but not as active as it has been in times past.

 

[Nightinggale]

Link to video.​

Back on the topic of medieval mining. I found this video of a Flatrod System. The idea is that a waterwheel transfers motion into rods, which then powers a water pump to drain a mine. It could also be used to lift miners and ore from the mine. The two very interesting parts to this is first the age: they predates the steam engine by 200 years, which place their introduction in the 16th century. The other is the length of the rods. It could transfer the power 4 km (2.5 miles). Sure the high friction meant a significant power loss, but 50% loss is attractive if the alternative is muscle power.

Having a hunch of German origin (based on name), I dug into the German wikipedia and found lots of information not in the English wikipedia. Most interesting is this one: https://de.wikipedia.org/wiki/Pumpenkunst
It's an article on the pumping system itself. The first one was built by Heinrich Eschenbach in 1540. Before this, all mines where based on a horizontal design to allow draining. This pump system allowed digging strait down and it could drain mines as deep as half a kilometer! It seems like the fladrod system came as soon as somebody else invented a pump, which works based on the motion in rods going like a pendulum. The flatrods didn't even have to be level and to make it even more fun, (at least in theory) it could be on a steep slope below the mine, meaning it could be powered by the water it pumped out of the mine. The poor efficiency likely required an additional source of water, but the requirements to the natural stream would be less if water was added this way.

For M:C purposes, first the pump, then the "transmission" would be ideal techs to unlock mining levels.

 

[Nightinggale]

For those of you, who haven't been following me, I have been busy with BTS lately. I made an "engine" for modding BTS and wrote a thread about it here: http://forums.civfanatics.com/showthread.php?t=564062

Leoreth brings up a very good point and if there is some sort of "compile server", it should learn how to compile based on the M:C source as well. It would actually be awesome if all DLL files are compiled every 24 hours for those who lacks a compiler.

On top of that, I have worked on two modcomps for BTS, both could be interesting for M:C.

1: art for all eras
Rather than displaying early/late art, it allows assigning one art string on a unit for each era. This also works for ArtStyles and would be of great benefit for us. I haven't checked the code yet, but I suspect the same setup would have to be adapted to professions. Regardless of how art and professions work, I know how it works in BTS and naturally it will work in M:C as well.

2: images for events
I didn't actually code this, but I converted it to BTS from warlords or whatever. The idea is that ingame images for random events can be added using xml only. It sounds useful and feedback is that it works as intended after being converted to BTS.

 

[Lib.Spi't]

I know at one point kail was doing images for events in M:C, I can't remember what came of that though.. I htink it may have been put on yhold when you started working on civeffects... It was a long tme ago.

I know at the moment he is taking a break, while he finishes some work.

I read your thread, but it was above my pay grade!

I don't know how well it would work for FTTW, as that uses kmod which changes a lot of structures of bts code.

You have access to the repository though, so you would probably know better than me anyway!

 

[Nightinggale]

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.

I tried looking into running M:C using the BTS exe because the more I look at it, the more stuff is screwed up in colo compared to BTS. I started on a header compare to see features colo calls, whcih aren't present in BTS. It looked ok with just some minor stuff until I reached yields. BTS is not able to display yields on the map, which includes the map seen in the city screen. Full stop. We are not getting the BTS exe and there is nothing we can do about that. I have been thinking about this on and off ever since I joked about it on the first of April and now I can rest my mind and forget about it.

I don't know how well it would work for FTTW, as that uses kmod which changes a lot of structures of bts code.

The problem with FTTW isn't kmod, but rather the fact that it already exist in a git repository. To make it work on this new setup would require rewriting history. It might be doable, but I'm not entirely sure. There are so many "it depends" involved in that. The setup works best for mods as they start or when they are added to git for the first time. Preserving a git history could be problematic. That being said, it isn't impossible. It's just not plug'n'play and two click merging.

Also FTTW is a bit off topic in this thread. I mentioned it mainly due to the modcomps, which has been produced in this system. They could be interesting in M:C as well.

 

[Nightinggale]

Leoreth seems to be full of good ideas, or he gives me ideas or whatever. Either way I'm on to the concept of a compile server to generate DLL files based on the newest version in git. That could be useful for any mod using the M:C source code, particularly as long as the yields are hardcoded in the DLL. Sure it would be better if the header is autogenerated based on xml, but I plan on doing that anyway. Getting rid of the hardcoding could still be beneficial since the DLLs would likely only be compiled once a day, meaning it could take up to 24 hours to get a new DLL based on changes you just committed.

 

[Nightinggale]

I finished my compile "server" and it will compile an assert DLL for M:C whenever I turn it on, providing something was committed to git. This can be expanded to other mods, meaning it effectively removed the need for XML modders to use a compiler.

DropBox DLL folder.

The thread about the compile server and ModComps and stuff is still this one: http://forums.civfanatics.com/showthread.php?t=564062

 

[Lib.Spi't]

Nice one!

So this .dll contains all your civeffect stuff.

What needs to be done to bring this in line with the current M:C Xml situation?

Sorry I am feeling rough and can't remember what state everything is in.

I am trying to remember what (if anything) is structurally different in the xml now, in that if I got this .dll, and the latest M:C content, and looked to merge it with my building/unit/terrain/text work from VIE. would anything clash?

What other things would I need to know to bring it in line with the latest civeffect stuff?

I can't even remember all the things that civeffect unified.

Era
Tech
FF
Events?
erm...

 

[Nightinggale]

The easest way to see what CivEffects are would be to look inside the CivEffect directory. Traits and Eras aren't working yet, but other than that, I think CivEffects should be working.

We could ask git what changed regarding the schema files.

The perl GUI xml editor should help upgrading xml files, but it's not done yet

There is a glitch in the autocompiled DLL btw. The git version string is empty, meaning the DLL is not aware of which git revision was used when it was compiled. Not a major issue and I know how to fix it. I just not that urgent.

If you are to mod xml once again, then which git server/repository would you use? You better use a proper git setup or it will turn messy. Or should I say: should I do anything to set up anything in git for you?

 

[Lib.Spi't]

I noticed a typo, TechGategoryInfos.xml.

I don't have my VIE work with me on this computer, I thought I did bring it with me but nope..

I would use whatever you guys are using, as I still can't get my head around interacting with git. I can pull a snapshot but that is about it!

Do you have a 'blank' entry for the new xml file structures? like an example entry with all of the tags in the right place/order with a default entry?

I have tried working it out from schema files before but I always end up losing the plot with them!

because right now I am guessing that the civeffect xmls of M:C don't work with the new .dll because they are structurally different or has that already been solved?

 

[Nightinggale]

I noticed a typo, TechGategoryInfos.xml.

Didn't I fix that

Do you have a 'blank' entry for the new xml file structures? like an example entry with all of the tags in the right place/order with a default entry?

That's part of the idea with the perl GUI. It is meant to have a "new entry" button, in which case it makes a new unit/building/whatever with blank/default settings for everything.

 

[Lib.Spi't]

Yeah I know that is the plan for the GUI, I was just wondering if you had made one before that, either as a comparison or as a test object.

I was just wondering incase my energy beats your GUI to the start line

I could start building a VIE tech tree (or whatever else) from scratch, as it will need to be all different from the M:C one anyway.

 

[Kailric]

Wow, there has been a lot of interest in the mod of late it seems. On there is two post at Mod Data Base where people say they love and like the mod. Hopefully I can do some work on this this coming week.

 

[smartclick20]

I have really interest in this mod. I need the map of europe to play. I hate the random maps...

 

[Nightinggale]

What is wrong with the random maps? They could always be improved, adding more options and stuff, but I don't see anything wrong with it as it is right now.

We talked about a map of Europe, but I'm not sure it was ever made. Generally I hate fixed maps as it ruins the whole point in exploring the map.

 

[Marla_Singer]

We talked about a map of Europe, but I'm not sure it was ever made. Generally I hate fixed maps as it ruins the whole point in exploring the map.

It's a different approach.

As you've said, random maps make exploration funnier, however, real maps can make your game more immersive as the action happens in real places.

For instance, in a game happening on the map of the Americas, it can become a challenge to join the settlements in California to those from the East. It can be fun to send settlers in what you know as Colombia to produce coffee berries. All this feels a lot more real because everything happens in places you can recognize.

When you're on a random map, games don't have that flavour. Places look more anonymous one from the other. And very often, random maps don't have the same complex structure as real world maps, with specific points of strategic importance such as capes, isthmus, valleys, small inhabitable areas like the Salt Lake or lost islands like the Bermuda which can become a haven for your privateers. It's a different approach, really.

 

[Nightinggale]

When you're on a random map, games don't have that flavour. Places look more anonymous one from the other. And very often, random maps don't have the same complex structure as real world maps, with specific points of strategic importance such as capes, isthmus, valleys, small inhabitable areas like the Salt Lake or lost islands like the Bermuda which can become a haven for your privateers. It's a different approach, really.

Agreed, but it would also be an argument for working on a better map generator.

 

[Fullerene]

It's true that fixed map ruins the exploration element, but I'd like to add one more thing to the list of points given by Marla_Singer: When map is always same, it can be fun to try different strategies.

I have attempted to create Europe map scenario to this mod, but at the moment my interest towards this mod have been decreasing

But when I regain the thrill I probably try again.

 

[Marla_Singer]

Agreed, but it would also be an argument for working on a better map generator.

Those who enjoy random maps are usually happy and those who prefer fixed maps are also happy. I see your modder instinct being stimulated but I guess there are other priorities.