DLL coding thread

For the Natives I would need to create a None profession unit. Right now, since Natives are never on the map with out a profession they use their Warrior profession art as default. So, I could create a none weapon holding native Unit for this feature. Some how we would have to work out the Profession art though. Say, If you have a convert that uses its original art, what profession art will it use? It starts to get complicated...
Yeah I don't know much about how the unit artdefs/artstyles work, but I agree it makes since to keep the system as simple as possible, it seems not worth tons of effort/complexity to create special exceptions for unusual art. Does M:C use the same system as RaR allowing national artstyles to modify artdefs for units/professions; if not could it be easier to adopt that?

When you learn a tech that allows a profession and disallows another the code cycles through all Units, finds the disallowed profession and force applies the new Profession. This however, causes issues if the two professions require different Equipment if the city in question does not have the equipment it will be set to negative numbers, thus causing a failed assert.
Yeah I can see how that would be a problem. How about, when it disallows a Profession it reverts those units to the default Profession (with no yield requirements) then maybe drops the old equipped yields onto the nearest city so they don't vanish into thin air. On the next turn the player can select which Profession he wants, if the appropriate yields are available.
 
Does M:C use the same system as RaR allowing national artstyles to modify artdefs for units/professions; if not could it be easier to adopt that?

UnitArtStyles (originally created by Androrc) is one of the 3 best features ever created in the Civ4Col modding community.
(Version in RaR has a few small improvments.)

Every modern mod should incorporate it.
 
Yeah I don't know much about how the unit artdefs/artstyles work, but I agree it makes since to keep the system as simple as possible, it seems not worth tons of effort/complexity to create special exceptions for unusual art. Does M:C use the same system as RaR allowing national artstyles to modify artdefs for units/professions; if not could it be easier to adopt that?

Yes, M:C uses Androrc art styles.

Yeah I can see how that would be a problem. How about, when it disallows a Profession it reverts those units to the default Profession (with no yield requirements) then maybe drops the old equipped yields onto the nearest city so they don't vanish into thin air. On the next turn the player can select which Profession he wants, if the appropriate yields are available.

This not so bad except in times of war. If the Units in question are fighting a battle then having them stripped of arms because, "Hey, yo, your Bow is no longer used by us, don't you know!?!" In mods like the World History mod were there can be major profession changes this is were this will become an issue. Perhaps we just need to make the code except obsolete professions until the player can change the profession himself.

UnitArtStyles (originally created by Androrc) is one of the 3 best features ever created in the Civ4Col modding community.
(Version in RaR has a few small improvments.)

Every modern mod should incorporate it.

I totally agree. That mod was a miracle to me. I was wanting to do extensive changes to Civ graphics and diversity and was stumped at how to do this efficiently and quickly, then I got on the forums and seen Androrc's mod. It was like sent from heaven :goodjob:
 
UnitArtStyles (originally created by Androrc) is one of the 3 best features ever created in the Civ4Col modding community.
(Version in RaR has a few small improvments.)
Every modern mod should incorporate it.
That mod was a miracle to me. I was wanting to do extensive changes to Civ graphics and diversity and was stumped at how to do this efficiently and quickly, then I got on the forums and seen Androrc's mod. It was like sent from heaven
:please::please::bowdown::jesus::please::please: no arguments here lol:p what do u think are the other best features ever? (I would vote Kailrics Invention/Tech/Civics, Nightingale making everything run miraculously fast without crashing plus addition of Plotgroups, Domestic Markets / Demands, etc etc.; also the TAC/RaR Events XML system which is awesome. there are just too many to choose :crazyeye:
This not so bad except in times of war. If the Units in question are fighting a battle then having them stripped of arms because, "Hey, yo, your Bow is no longer used by us, don't you know!?!" In mods like the World History mod were there can be major profession changes this is were this will become an issue. Perhaps we just need to make the code except obsolete professions until the player can change the profession himself.
Good points all. Maybe instead of making all instances of the Profession instantly vanish, you could just become unable to adopt that Profession in future. That could certainly simplify things a lot, while also being fairly realistic.
 
Welcome to my world, that's why M:C was such a jumbled mess when you arrived:D

Just what do we want from this feature?
The reason why I said something without thinking it through is because you proposed a namechange and I didn't like that approach. I then started brainstorming to see if I could figure out a better way and what we could gain with different approaches. Usually when I come up with an idea completely on my own, I think about it for a while, possibly read the code and such before writing about it. That mean I have usually thought things through before telling anybody. I kind of skipped those steps when making a fast reply :blush:

On a different note I discovered a new app for my phone that will allow me to access my PC, run programs and such, even M:C. It has the ability to do this even away from home but I will need to set it up just haven't done that yet. M:C is playable from my iphone now :) It is a bit tedious however, but with some practice and some autokey scripts it would get easier perhaps. I can at least let the AI run through some turns and even debug to a certain extent. All the more reason to get an smart phone Night :)
Who benefits the most from this app? You, NSA or some Nigerian hacker? :lol:

Maybe you benefit from an app like that, but I don't think I will. Either I'm at a computer with the source code or I'm busy doing other stuff. I find it unlikely that I will be in a situation where I benefit from such an app.
 
If units will not change profession when their profession becomes obsolete, then we will likely have asserts as the code sometimes check if the current profession is allowed for the unit in question. Sure it can be fixed, but we should be aware that it will happen.

Personally I think it would be best to just keep units and professions when they are no longer allowed. Imagine if we obsolete a ship. Would you disband your navy? Wouldn't that be like GM releasing a new car model to replace an old one and then all the old ones on the roads are scrapped? Clearly the old ones are still valid.

I would argue that in case of professions, the units should try to upgrade instead of just doing it. If the test returns false, then the old profession is kept. Maybe they should check allowed profession during CvUnit::doTurn() and upgrade when it is possible. Imagine placing 3 units in a city on fortify and you have have yields to upgrade one of them. However you have feeder service or production to deliver more weapons. The units will then upgrade as soon as there are enough yields.

there are just too many to choose :crazyeye:
I would likely point to feeder service as it solves one of the issues, which really annoyed me in vanilla and most mods. If I had to play vanilla where I could bring just one feature, this would be this one. I wrote this feature in the first place because I was annoyed with the lack of it, hence the reason why it was the very first thing I wrote for RaRE.

However I would say it is impossible to point to a single one. It's the number of features combined, which makes a mod and some of them would be pointless if you used them alone. For instance my bugfixes and performance improvements were mentioned earlier. That would be almost pointless to add to vanilla as while they are important, they aim to solve imperfections in other features. If you start to look at how features rely on each other, then it gets really complex and it is completely impossible to pick a single one as the best.

Besides I would say it's pointless to speak of "the best" feature. Not only will it be a matter of preference, it will also be countered with "it depends on...". Also like it or not, we added a bunch of features to CMC and they are staying there as a set, not individual features.
 
The reason why I said something without thinking it through is because you proposed a namechange and I didn't like that approach.

Well, you can tell me what you think about it the next time you get a Convert in M:C as I left my test code in the mod. :D:p

Who benefits the most from this app? You, NSA or some Nigerian hacker? :lol:

Maybe you benefit from an app like that, but I don't think I will. Either I'm at a computer with the source code or I'm busy doing other stuff. I find it unlikely that I will be in a situation where I benefit from such an app.

Arghh!!! You always foil my plans to discover who you really are! I am the Nigerian hacker! I will get you yet my pretty!

If units will not change profession when their profession becomes obsolete, then we will likely have asserts as the code sometimes check if the current profession is allowed for the unit in question. Sure it can be fixed, but we should be aware that it will happen.

Personally I think it would be best to just keep units and professions when they are no longer allowed. Imagine if we obsolete a ship. Would you disband your navy?

I agree, my thinking at the time was to eliminate no longer needed professions from the list of available professions. M:C doesn't really have that issue anymore since Tools can be used for military professions, so when all else fells grab a shovel. But, this will be an issue in huge mods like World History.

However I would say it is impossible to point to a single one.

Hog wash, you all just can't accept the greatest addition of them all, Coolest Mod Ever Mod.
 
Got a coding question:

Would;

(getActivityType() == ACTIVITY_AWAKE || getActivityType() == NO_ACTIVITY)

work just the same as;

(getActivityType() == (ACTIVITY_AWAKE || NO_ACTIVITY))

It would seem if this worked then it would be a bit faster as you don't have to "get" the activity both times.
 
Would;

(getActivityType() == ACTIVITY_AWAKE || getActivityType() == NO_ACTIVITY)

work just the same as;

(getActivityType() == (ACTIVITY_AWAKE || NO_ACTIVITY))
No because (ACTIVITY_AWAKE || NO_ACTIVITY) would be read as
Code:
(ACTIVITY_AWAKE != 0 || NO_ACTIVITY != 0)
(0 != 0 || -1 != 0)
(1)
It will produce a bool, which is true and when viewed as an int, it will become 1 according to the C++ standard. This is dangerous coding as it isn't part of the C standard and PPC will make the value 0xFFFFFFFF, in which case you can end up saying if (1 == 0xFFFFFFFF) when you expect it to say if (1 == 1). If you want to write code, which can't be moved from one OS to another, then this is the kind of code to write.

It would seem if this worked then it would be a bit faster as you don't have to "get" the activity both times.
You are right about that and I believe some high level languages can handle it. However C++ is a bit low level and you have to be more specific what you want to do. While it isn't perfect while coding, the need to be specific will often allow the compiler to produce faster code. This is the main reason why CPU demanding games are all coded in C++.

You could do what you want by writing two lines instead of one.
Code:
ActivityTypes eActivity = getActivityType();
if (eActivity == ACTIVITY_AWAKE || eActivity == NO_ACTIVITY)
That way you only call the get function once and use the result twice. getActivityType() appears to be one of those functions, which only returns an int. After the first call, that int will be in the cache (presumably level 3 cache) and you will not really get a performance loss for calling the function again. However if the function is more complex or there is other activity to get the pointer to the object in question, then caching the output will be a good idea.

An example of a function to get an int where getting the pointer itself is the time consuming part could be GC.getCivilizationInfo(getCivilizationType()).isWaterWorks(). It just reads a bool from memory, but figuring out where that bool is stored takes some calculations. If you need the output more than once, then cache it. However it will likely be more practical to cache output of GC.getCivilizationInfo(getCivilizationType()) as it is often used for different CvCivilizationInfo member functions rather than the same over and over.
 
Thanks for all the info above by the way, duly noted.

If we are wanting to have a Price Market for each Trade Screen, I don't rightly know the best way to set that up. We would need an Array within an Array, an Array of all TradeScreens with an Array of all prices of Yields.

Would something like this be efficient?

Code:
m_ppiTradeScreenYieldPrice = new int*[GC.getNumEuropeInfos()];
for (iI = 0; iI < GC.getNumEuropeInfos(); iI++)
{
	m_ppiTradeScreenYieldPrice [iI] = new int[NUM_YIELD_TYPES];
	for (iJ = 0; iJ < NUM_YIELD_TYPES; iJ++)
	{
		m_ppiTradeScreenYieldPrice [iI][iJ] = 0;
	}
}
 
If we are wanting to have a Price Market for each Trade Screen, I don't rightly know the best way to set that up. We would need an Array within an Array, an Array of all TradeScreens with an Array of all prices of Yields.

Would something like this be efficient?
Yes, but it would be better to use JIT arrays. They check if you are out of bounds and they can be converted when reading savegames.

Look at the first JIT array introduced.
CvPlayer.h said:
YieldArray<ProfessionYieldCost> *m_cache_YieldEquipmentAmount;
CvPlayer::CvPlayer() said:
m_cache_YieldEquipmentAmount = new YieldArray<ProfessionYieldCost>[GC.getNumProfessionInfos()];
We can't have a JIT array of JIT arrays, but we can have an array of JIT arrays.

Saving in a way where both arrays are converted on load is possible, but I can't remember offhand how I managed to do that and I can't find it in the source right now. We will go back to that if needed.


I have an alternative approach, which could be worth considering. We make a brand new class for Europe and we load/save it in CvGame read/write. This will give a read/write function setup just like all other classes and adding data to each will be really easy. We might not have to have a whole lot in it right now, but if we have the platform for non-XML data for trade screens, then adding something later will not be stalled by "I wonder how to store this".
Presumably most of the "howto"s for adding a new class can be read in the git log from when plotgroups were added. I even figured out how to add a python class for it. If I recall correctly civ4 lacks python access to plotgroups meaning I coded from scratch.
 
So, this means we can create simulated Markets on the fly right? We are not just limited to the Number of Europe Types, right? Maybe with a code adjustment we can spawn "Markets" where ever we want.

Like Spawn one for each city. Then plotgroups can get average prices from all the cities it contains.
 
Now that you mention it, we could make a CvTradeScreen variable anywhere. It would be kind of like adding JIT arrays (those are also "just" a class). They know themselves how to save and stuff.

The real question is if it is a good idea. I would assume it to be a better idea for each civ or each plotgroup or something rather than each city as each CvTradeScreen works independently with price changes. This requires some thinking if we are to follow this path.
 
Now that you mention it, we could make a CvTradeScreen variable anywhere. It would be kind of like adding JIT arrays (those are also "just" a class). They know themselves how to save and stuff.

The real question is if it is a good idea. I would assume it to be a better idea for each civ or each plotgroup or something rather than each city as each CvTradeScreen works independently with price changes. This requires some thinking if we are to follow this path.

Well, each City in real life has its own set prices, probably even more so in Medieval times. Like the man says, value is only in the mind. Nothing in itself has value, only what someone is willing to pay for it, only what someone has put value on it. Whats valuable to me may be useless to you, and each City would value things differently depending on their inputs, outputs, and culture.

But, at the moment this code isn't needed by me at least, but I was just thinking ahead in the future if we expand on trade some more. I think what we have now will carry us to the next stage.
 
I know it could make sense to have prices in each city, but if prices varies according to sales and sales is done with plotgroups, not cities, then it could be a coding and debugging nightmare to implement a trade screen class for each city. We might also consider micro management and performance.

It might make sense to have one for each minor civ through. It depends on implementation. Most likely if it can supply itself somehow, it can use it to pay way more for yields it can't produce locally than the ones it can grow locally.
 
I tell you, not having access to the exe is a pain. While trying to get the Civs with no Parents to start trading with the Trade Screens I discovered that they will only trade if they have an AI_isPort() City. Where is AI_isPort() set? I find nothing in the DLL so can only assume it is in the exe. Anyway, I am adding my own code, like when a City is created it checks if it is a NationState, checks if it can access Europe tiles, then sets that city as a Port city. Once I did that Rome started trading.

Also, I discovered that we need to add code to check whether a Product requires Two or more Yields in the AI_professionValue() code. If one Yield is Present and the other is not it will still assign Citizens to work Buildings that produce no Yields.
 
Back
Top Bottom