[MOD] Medieval: Conquests

If you lost the Or requirement can't you just add it back?
I could, but I wouldn't be able to fix the GUI at the same time. I was thinking something like we split the remaining tasks between us. Some tasks require more coding skills and knowledge of how CivEffects works to handle than others. Reviewing XML setup (the files, not the schema) is technically the easiest part. Adding help popup text is not that tricky either and could be split between us as well.

My current main focus is to fix the tech tree GUI, which require python exposing some data, which in turn require adding more classes to the python interface. I think it would be best if I do that myself, but that will not prevent anybody else from fixing text and XML setup while I'm busy.
 
Ok, I'll check into it.

And sorry I haven't posted my changes yet for playtesting. I'll get that done this weekend along with a list of things that need testing as well. I really want to get my changes working bug free in my current release before we do any merging.
 
I really want to get my changes working bug free in my current release before we do any merging.
Me too. While I have tried to be careful, CivEffects has a greater impact on the code than planned and I would be surprised if everything works right away. I really want to know if a new bug is caused by you or CivEffects as it really changes how we should try to fix it.
 
I have been thinking of adding bIsHuman to Unit Info. The reason is that we have two main categories of units, those, which immigrate/are born/educated and those, which are build. If we look at the data, getting the type mean checking all sorts of different settings and that is prone to be buggy. I want a simple bool to check as it is easier to code and executes faster and being that simple, it is less likely to be buggy.

I want to do the same trick here as with cargo yields. This mean all humans are first, then followed by all non-humans. This will allow human sized unit arrays, meaning schools will not have to store if they can teach catapults, ship or stuff like that. Also if we need to loop all human unit types, but know it it will do nothing to non-humans, we can stop the loop at the end of the humans. This will increase performance and save memory.
Naturally making assumptions like this requires the DLL to assert if the XML file doesn't apply to the rules, just like any other assumption that the DLL does about XML.

I wrote earlier about splitting units into two XML files. I think it would be better to simply use this bool because merging multiple XML files into a single array at runtime can be done (I know how to do it), but it requires more coding. Keeping the simple one array, one XML file simplifies the XML reading code.

I'm busy with CivEffects right now and don't plan to do anything unit related before next release. However since next release will also be the base for other XML based mods, I'm thinking of adding this bool now without actually using it in the DLL.

This is part of my current design strategy, which is to ensure the needed tags are in XML before they split into multiple mods. This allows coding the DLL without modifying the XML files. Ideally all future DLL updates will only add optional XML tags to avoid breaking other mods (or at least minimizing the need for mandatory XML updates). This requires a bit of planing ahead to figure out which mandatory tags to add right now.

Note: while I call it humans, it will apply to human behavior, which mean in this sense space aliens, androids and other similar units could be considered humans as they take up citizen professions and stuff like that.

Is this a concept we can agree on?
 
Note: while I call it humans, it will apply to human behavior, which mean in this sense space aliens, androids and other similar units could be considered humans as they take up citizen professions and stuff like that.

Is this a concept we can agree on?


I give this a :goodjob:

Perhaps, instead of "bisHuman", we could have another term, like Citizen, or Settler, or Subject, or TaxPayer (that's what we are).:cry:
 
Perhaps, instead of "bisHuman", we could have another term, like Citizen, or Settler, or Subject, or TaxPayer (that's what we are).:cry:
I don't think human is ideal, but still the best of all those options. Citizen is covered by profession, not unit. Settler is bCanFound, which isn't true for all humans. Subject is... could mean a lot of stuff, particular if people aren't skilled at English and TaxPayer can be misunderstood because some humans will not pay tax (say slaves).

I was thinking of something like "is living being", but that conflicts with animals. We have bMechanical, but animals aren't mechanical, which mean that one isn't good either.

One thing we should remember with the name is that currently we are blessed with only people, who can read English well. We might not be so lucky in the future, which mean XML tags shouldn't require a degree in English or history to figure out.

While human isn't ideal, it is still the best word I can think of for the concept. It works well for most mods and if a modder adds aliens, the modder should accept that they have to be called humans for the behavior coding.
 
if a modder adds aliens, the modder should accept that they have to be called humans for the behavior coding
a remarkably enlightened attitude :goodjob::p

I don't mind what the tag would be called, but I'm not sure which specific purpose you're envisioning it to serve - although vanilla has just 2 categories of units, it doesn't have to be that way for all mods. In 2071 there actually are certain "citizen" units which can be manufactured locally if you have the right Tech, like the AI and Android unique units of the Japanese Colonies. (Kind of cool that even vanilla Civ4Col allows for modding of situations like that:cool:) So having features not all be lumped into one <bIsHuman> would add the most flexibility; perhaps instead using a few tags like below to enable modders to adjust each characteristic as desired.

<bCanJoinCity>
<bCanLearn>
<iFoodConsumption>

This way there still could be a fixed loop for units with <bCanLearn>1 to aid performance, while letting modders set units to educable or not as desired. :scan:
 
So having features not all be lumped into one <bIsHuman> would add the most flexibility; perhaps instead using a few tags like below to enable modders to adjust each characteristic as desired.

<bCanJoinCity>
<bCanLearn>
<iFoodConsumption>

This way there still could be a fixed loop for units with <bCanLearn>1 to aid performance, while letting modders set units to educable or not as desired. :scan:
I didn't say I would like the XML setup to be simplified to just a single bool. That would be plain silly.

The problem is that right now there is no reliable check to tell if a unit is a human or a ship. To some degree the code doesn't really care. If I get it right, we could set non-humans to appear on the docks (immigrants, not bought units) and it would do that because there is no check for humans only.

This lack of answering the question simple and reliably turned out to be a big issue when I made the teacher list and the solution I came up with works in this specific case, but note that it also filters out units like free peasants. This mean it isn't a general solution.

I want a general solution. I want to add a bool, which quite simply tells if a unit is a human or not. That will make an easy check and I know the code will work if that is the question I want answered.

We can then add a bunch of tags, which applies to humans only. bCanFound, iFoodConsumption and whatever. Those can be set to give a more detailed picture of the current human unit.

I was thinking of bCanJoinCity, but somehow I'm not sure if I like it. On the other hand I have been wondering if all humans should be able to join cities. If they can, then bIsHuman and bCanJoinCity would do more or less the same job. Maybe it should be called bCanJoinCity :think:
 
There could be an argument for a 'bHuman' that cannot join a city.

It could be born from food under a certain civic choice, it could be the Bio-Land-Combat-Squid, which cannot join or be used in a city, but if garrisoned in a city with Mega-Laser-Beam-Gun Yield it can be reprofessioned as a Mega-Laser-Beam-Gun-Bio-Land-Combat-Squid.

I would dare anyone to tell me that you would not want to play a mod that has that in it!!
 
It could be born from food under a certain civic choice, it could be the Bio-Land-Combat-Squid, which cannot join or be used in a city, but if garrisoned in a city with Mega-Laser-Beam-Gun Yield it can be reprofessioned as a Mega-Laser-Beam-Gun-Bio-Land-Combat-Squid.
I was thinking something similar, though I was thinking more like a berserker, which would not be allowed inside your own cities because he would get drunk and break everything.

However I started thinking of this approach in another way. What if we don't set bHuman, but rather just set a bunch of bools. In the DLL, we can have a function isHuman(), which returns true if at least one of the bools is true. Such bools could be:
  • bFound
  • bCanJoinCity
  • bCanClearSpeciality
  • iTeachLevel < 100 (100 is the default, which mean can't be taught at school)
This way we don't need to set anything in XML to tell if a unit is a human or not. At the same time there is an easy to access standardized test, which allows the DLL to figure out if a unit is a human or not.
 
what would the other 99 numbers represent in teach level? Is it a scale of how fast they would learn or?
No. Each building has a teach level and a city caches the highest teach level of all the buildings present. A unit can be taught in the city if the unit teach level is less or equal to the city teach level.

Currently 3 each levels are in use and then the numbers 4-99 are reserved for expansion (if that isn't enough, the mod is poorly designed :lol:).

At some point I wondered about adding a building class to requirements, or adding an array of units, which can be taught at buildings. That would allow some combos like fishermen would require both the school and docks, It makes little sense to educate fishermen 15 plots from the nearest fishing plot. However I never did anything to make this expansion of the education system. Either way at some point we need to give the entire education system an overhaul because it isn't flexible enough to meet the requirements of medieval education.
 
Not sure where else to post this, but I got sidetracked once again into another mod. Some people are restarting Fictionalization IV and I have set up a git server for them by request. It appears that the mod is very light regarding programming, but extremely heavy on new unit graphics and leaderheads. It might be worth keeping an eye on.

More info: http://forums.civfanatics.com/showthread.php?t=562363
 
Night, hey! Here, saluting you all. Please tell whether the mod is dead or you keep working on it, and as a result, is there any stable version released fresher than 2.5.4.2 ? Thanks!!!
 
Top Bottom