DLL coding thread

[Nightinggale]

in Civ4CivilizationInfos.xml (from the top of my head, haven't checked it in the files) you do not add, but exclude certain professions.
Should read like this:

<ProfessionType>PROFESSION_BRAVE</ProfessionType>
<bValid>0</bValid>

Does your new code cope with that as well?

Not directly, but with a bit of coding, yes.

What InfoArrays does when set to bool reading is that it goes to the array name (FreeBuildingClasses in the example). Here it reads the value of each child (FreeBuildingClass). If the child has children, it will enter the first child recursively until it reaches a value and then it goes back to looking at the next FreeBuildingClass. As a result, it will never look at bValid since it isn't the first child.

The InfoArray converts the strings to ints (just like vanilla arrays does that). It will then assign 1 to the indexes present and 0 to those not present.

The way I would read valid professions from CivilizationInfo is this:
Replace the current array with a JIT array of length numProfessionTypes (PermArray). Set the default value to 1.
Make a temp InfoArray (TempArray) and read the XML data, which can then be written in the short format.
Next subtract TempArray from PermArray. THis will be 1-0=1 for not mentioned professions and 1-1=0 for mentioned professions, precisely the same result as we get with the current code.

The XML reading code will then have to replaced from

pXML->SetVariableListTagPair(&m_abValidProfessions, "Professions", GC.getNumProfessionInfos(), true);

to

InfoArrayBool TempInfo;
TempInfo.read(pXML, "Professions");
m_ja_iValidProfessions.add(TempInfo, -1);

We could also use a bool array since it is just 1 or 0.

We can then assign the JIT array into an InfoArray if we like. JIT/Bool/Info arrays are aware of each other and can copy data between them with one line commands. (not 100% done with BoolArray implementation for that though)

So a bit more coding, but certainly within the doable range of recoding. TempInfo can be reused for other arrays as well.


Alternatively we can invert the setting to disallow where 1 is disallow and 0 is allow. That mean the InfoArray can read the XML directly, but it will have to invert the answer in the function to read the array data.

 

[Commander Bello]

Well, the easiest and most understandable procedure might be to change the way in which Civ4CivilizationInfos.xml has been set up.

From entering professions which are not allowed to entering those which are. That way, it would be a consistent way...

 

[Nightinggale]

From entering professions which are not allowed to entering those which are. That way, it would be a consistent way...

That sounds silly since most civs allows most professions.

Also we could make a native CivEffect, which gives -10 to all the professions we don't want the natives to use. That way we completely avoid the civ specific setup.

 

[Commander Bello]

That sounds silly since most civs allows most professions.

Also we could make a native CivEffect, which gives -10 to all the professions we don't want the natives to use. That way we completely avoid the civ specific setup.

With all due respect, but it doesn't sound silly at all.

We were talking about avoiding the boolean tag. So, without it, any newcomer now has to know by heart whether that respective xml-file shall allow a certain setting (here: the professions) or shall explicitly disallow that very setting.
If the general rule is to only mention allowed settings, no confusion can happen.

For setting up the "European" professions, a simple copy and paste will do - they are always just lines.

The final result is always the same: we have a list of allowed features for a certain entity.

Then your "native CivEffect" can work exactly in the way you want it to work: it will will attach -10 to all professions not being allowed to natives.

But do as you want.

 

[Nightinggale]

We were talking about avoiding the boolean tag. So, without it, any newcomer now has to know by heart whether that respective xml-file shall allow a certain setting (here: the professions) or shall explicitly disallow that very setting.
If the general rule is to only mention allowed settings, no confusion can happen.

I suspect the majority of newcomers will figure it out if we use a tag name like DisallowedProfessionType. BUt you are right that name and effect should match. Adding an enable tag, which actually disables is confusing and will cause even experienced modders to make mistakes.

 

[Lib.Spi't]

In Civ the way it works is you have the unique unit tag, where you set if a unitclass has a unique version for that civ. To disallow, you set the unitclass, and set the unique unit to NONE.

If there is no unique unit entry, then it just uses it as normal.

 

[Nightinggale]

In Civ the way it works is you have the unique unit tag, where you set if a unitclass has a unique version for that civ. To disallow, you set the unitclass, and set the unique unit to NONE.

If there is no unique unit entry, then it just uses it as normal.

It works the same way in Colonization. The issue here if a civ is allowed to set units to become a certain profession. We can set a farmer to be a fisherman if we like. However the civ can disallow the profession fisherman (hydrophobic leaders?) and then the farmer can't be set to be a fisherman. This has nothing to do with allowing expert fishermen or not, though expert fishermen makes little sense if fisherman profession is disallowed.

 

[orlanth]

There can be interesting effects to allowing & obsoleting Professions via Techs (meaning CivEffects in M:C), in order to enable a more advanced/efficient version of the basic Profession (for example using the new Yield Multiplier behavior to enable you to discover a late-game Profession that makes more Tools per unit Ore, and obsoleting the old version. In 2071 I've been thinking about having some Professions create YIELD_POLLUTANTS as a negative side effect of production, and letting you discover some "Green Techs" that unlock an environmentally friendly version and obsolete the old one Anyway if you want to disallow a chunk of Professions for a certain civ type, maybe you could use one CivEffect to do this.

btw I think the real Major Breakthrough was uncovering that awesome emoticon with the feathered cap and bugle

 

[Kailric]

So, it looks like Ocean plots are not included in PlotGroups. I am thinking they where in Civ4 as when you built a city on the coast all the connected Ocean plots became part of that cities plotgroup. In order to have Coastal Cities connected by Plotgroups wouldn't we need to Ocean plots added to Plotgroups?

But then, it would be confusing to Land units, they would be in the same plotgroup as Coastal Cities, even if there isn't a land route connecting them to the city. So, how should we handle this?

 

[Nightinggale]

So, it looks like Ocean plots are not included in PlotGroups. I am thinking they where in Civ4 as when you built a city on the coast all the connected Ocean plots became part of that cities plotgroup. In order to have Coastal Cities connected by Plotgroups wouldn't we need to Ocean plots added to Plotgroups?

BTS plotgroups spread using an exe function, which isn't in colo. I wrote my own addon to compensate and it is far more simple than the BTS one. It spreads across plots where route != NO_ROUTE. It does check owner, open borders, enemy units etc as you would expect, but it can't spread across terrain types or rivers like in BTS.

I kind of like the route approach as we use it to detect if cities are connected by road. Automated transports will eventually use it to determine if there is a road or if they have to go through wilderness to fulfill a certain traderoute.

I have one idea though, which could be interesting. Making a ship, which is a worker. It can then sacrifice itself to place a route on water (ferry connection). This would allow plotgroups to spread across water while at the same time remove micromanagement in having cities on two islands close to each other as land transport can use the ferry. Movement bonus on the ferry should be horrible, preferably the unit should always end movement on the ferry route.

I think the DLL setup for this change is fairly easy. CvUnit::canMoveInto() needs to be changed to ignore checking for domain if there is a route. The build route command needs to be able to kill the worker depending on XML.

 

[Lib.Spi't]

Could some kind of plotgroup connection be made by a building.

Not for all parts of the plotgroup, just certain parts.

So for example not the AI transport route type stuff, but things like bonuses that work within a specific plotgroup. (Like being attached to a monastery and such)

I quite like the idea of continents being seperate plotgroups, so in a WHM type arena your colonies won't benefit from your homeland plotgroup for much of the game, but eventually you can build a building (Like an airport or some such) that 'connects' continental plotgroups together.

 

[Kailric]

But we still haven't answered my initial question. Ships can't use plotgroups. If you have two Coastal Cities, even connected by roads, ships will not be able to use the plotgroup. This caused a CTD in my current game because the Ship was in a port city, that was connected to another Foreign City, it left the Port headed to the Foreign city no problem, but next turn it CTD because the Plot it was on had no Plotgroup. I fixed this by making it check for Null plotgroups atm.

So, what is the simplest solution? Are Oceans considered Areas and perhaps the Two cities could just see if they are in the same Area?

Edit: I just checked this out in my current game. There was one area that was disconnected by land from and it had a different Area ID, so, could this be a viable way to tell if two cities are connected by a sea route?

 

[Nightinggale]

Could some kind of plotgroup connection be made by a building.

Sounds to me like it would require two plotgroup types, one for detecting road connections and one for plotgroup benefits. I guess that would be possible, but totally not what I plan to make in the near future.

 

[Nightinggale]

But we still haven't answered my initial question. Ships can't use plotgroups. If you have two Coastal Cities, even connected by roads, ships will not be able to use the plotgroup. This caused a CTD in my current game because the Ship was in a port city, that was connected to another Foreign City, it left the Port headed to the Foreign city no problem, but next turn it CTD because the Plot it was on had no Plotgroup. I fixed this by making it check for Null plotgroups atm.

That sound strange. I'm not really aware of code, which makes the unit check plotgroup on the current plot

If you added code like that, then it would be an issue for land transport as well. Imagine a CivEffect, which allows you to build roads in hills (not possible right now, but planned). You connect two cities by circling the hills. However some transports leave the road and head over the hill because it will be faster than the detour despite the road movement bonus.

The problem isn't that the ocean plots lacks a plotgroup. It's something else, but I can't think of any code I have written, which would cause such a problem

 

[Nightinggale]

Edit: I just checked this out in my current game. There was one area that was disconnected by land from and it had a different Area ID, so, could this be a viable way to tell if two cities are connected by a sea route?

I have a plan, which will make a "water plotgroup system". Essentially it will set all plots to 0. It then loop all plots. if the plot is water and group is 0, it sets an ID to the plot and all plots next to it (that ships can move on). This way if two plots have the same ID, ships can sail between them and we can rely on this for tasks like the one you just mentioned.

It will not tell if the route is blocked by pirates or owned by somebody, who will not let you pass, but it will tell if nature allows you to move. This system should spread through cities meaning it would be possible to build cities at strategic locations to allow ships to pass.

 

[Kailric]

In case you didn't see my edit of last post...
I just checked this out in my current game. There was one area that was disconnected by land from and it had a different Area ID, so, could this be a viable way to tell if two cities are connected by a sea route?

It is my AI Trader code and for some reason across country Traders had no issues. Well, it was because they don't check plotgroup once you get a target city, they just head towards that city. Which, I believe what happened was that the City the Ship was going to lost its Plotgroup because of Bandits, which then the unit tried to find another but the plot it was on had no Plotgroup. So, yeah this bug would have effect land units also but I addressed the issue so far. So, while the bug wasn't directly caused by Oceans no having plotgroups it did raise the question of what to do about it.

 

[Nightinggale]

It is my AI Trader code and for some reason across country Traders had no issues. Well, it was because they don't check plotgroup once you get a target city, they just head towards that city. Which, I believe what happened was that the City the Ship was going to lost its Plotgroup because of Bandits, which then the unit tried to find another but the plot it was on had no Plotgroup. So, yeah this bug would have effect land units also but I addressed the issue so far. So, while the bug wasn't directly caused by Oceans no having plotgroups it did raise the question of what to do about it.

How about setting a home city? The unit can then use the plotgroup from the home city if the current plot lacks a plotgroup. That way it will not end up without a plotgroup and no idea what it should do.

 

[Kailric]

I have a plan, which will make a "water plotgroup system". Essentially it will set all plots to 0. It then loop all plots. if the plot is water and group is 0, it sets an ID to the plot and all plots next to it (that ships can move on). This way if two plots have the same ID, ships can sail between them and we can rely on this for tasks like the one you just mentioned.

It will not tell if the route is blocked by pirates or owned by somebody, who will not let you pass, but it will tell if nature allows you to move. This system should spread through cities meaning it would be possible to build cities at strategic locations to allow ships to pass.

Yeah, as using Area IDs will tell if an Ocean plot is connected to another it doesn't tell if two Coastal Cities is connected to each other. So, for the moment, in order to use Ships in the Trader AI code I guess we can simply have them attempt to Generate a Path to the City. If they can Reach it, then they can trade with it.

 

[Kailric]

How about setting a home city? The unit can then use the plotgroup from the home city if the current plot lacks a plotgroup. That way it will not end up without a plotgroup and no idea what it should do.

It is required to have a HomeCity in order to use the system, but yeah, checking for the Home Citiy's plotgroup would work better. That way you could start a trader working even if it isn't on a plot with a Plotgroup. Still, for Ships we need some kind of Water Plotgroups.

 

[Nightinggale]

Yeah, as using Area IDs will tell if an Ocean plot is connected to another it doesn't tell if two Coastal Cities is connected to each other. So, for the moment, in order to use Ships in the Trader AI code I guess we can simply have them attempt to Generate a Path to the City. If they can Reach it, then they can trade with it.

That is slow a bit slow, but sort of needed. The static water plotgroup could tell that two cities are connected, but the trader can't move through the pirate blocking the chokepoint. That can only be fixed by making real water plotgroups for each player. That might actually make sense as it would make sense as it would only spread across explored plots.

There could be a third plotgroup system for costal plots. I wonder if that is overdoing it though.