Help Wanted Ads

[Thunderbrd]

Is the unit related workRate(bool iMax) function exposed to Python? The doco says it is but I get a no such method error message. Also what is the iMax meaning?

1) Yes that is exposed to python via CyUnit. If there's an error in that, perhaps its something AIAndy or Koshling may be able to figure out but it looks mostly right to me. However, perhaps its supposed to be called as (bool bMax) rather than iMax. Nothing suggests it's changing in the translation:

int CyUnit::workRate(bool bMax)

2) The iMax meaning is - are we checking for the ultimate potential work output of the unit or are we checking for the current work output of the unit. If iMax is boolean false then there's a check to see if the unit can move still and if the unit cannot move for whatever reason (like having already moved) then the return for the function will be 0. If your checking for the pedia or really any other type of display purposes, its probably best if this is set to true (1).

 

[Dancing Hoskuld]

I now see what you did there... I've added new rules through the promotionline mechanisms to enable new ways to attach promotion requirements. This is intended to make things MUCH easier on us as we can attach prereqs to entire categories of promos rather than just to each and every individual promotion. This makes us more agile in being able to audit and adjust promotion prereqs throughout and makes it much easier when designing a promotion set. So its an update to the pedia we're looking for here that makes this fit the way the pedia displays these things. (I'm sure you get all this at this point so I'm just trying to clarify anything that MIGHT be confusing at the moment.)

The idea that many of these displays are being derived from lists generated in the dll in the first place gives me a concept of how I may be able to repair these without much adjustment on the python side and I'm looking into that today. (along with the previous request)

I am all for keeping the interface to the Python the same. So that I would expect the DLL to do the work to convert the expression system prerequisites into the same list(s) as used by Python.

In the case of Promotions there is no list just the three fields so you would need to convert it to a list and I would need to convert the Python.

1) Yes that is exposed to python via CyUnit. If there's an error in that, perhaps its something AIAndy or Koshling may be able to figure out but it looks mostly right to me. However, perhaps its supposed to be called as (bool bMax) rather than iMax. Nothing suggests it's changing in the translation:

int CyUnit::workRate(bool bMax)

2) The iMax meaning is - are we checking for the ultimate potential work output of the unit or are we checking for the current work output of the unit. If iMax is boolean false then there's a check to see if the unit can move still and if the unit cannot move for whatever reason (like having already moved) then the return for the function will be 0. If your checking for the pedia or really any other type of display purposes, its probably best if this is set to true (1).

I meant bool bMax Since I am talking about the pedia I am asking about a generic unit of that type so agree I should use false.

@AIANdy The code I am using that gets the no such method is

	def placeStats(self):
		screen = self.top.getScreen()
		panelName = self.top.getNextWidgetName()
		iCombatType = gc.getUnitInfo(self.iUnit).getUnitCombatType()
		[B]iWorkRate = gc.getUnitInfo(self.iUnit).workRate(True)[/B]

Is it obvious what it is that I am doing wrong?

 

[Thunderbrd]

I am all for keeping the interface to the Python the same. So that I would expect the DLL to do the work to convert the expression system prerequisites into the same list(s) as used by Python.

In the case of Promotions there is no list just the three fields so you would need to convert it to a list and I would need to convert the Python.

I'm not sure if I can really compile this correctly or properly in the dll first but I AM exposing the promotionline and its tag infos to Python right now. This would enable you to check against the promotion's promotionline for the information needed.

There's multiple tasks here but one example would be if looking for the prereqs as automatically assigned by promotionlines:
Loop through promos for any promo that matches the promotionline of the promo you're evaluating. Then display a promo from among that filtered list if that promo is at iLinePriority equal to 1 less than the iLinePriority of the evaluating promotion.

Might want to make sure that the promotion hasn't already been displayed by the normal check before telling it to display though. (to avoid duplicates in the list)

While I could code well enough to generate a proper list straight from a single vector established in the dll that could then be reported to python on this, I'm really not sure if I can do that without establishing a whole CvPromotions.cpp page like we have for CvUnit.cpp and then figure out how to get something along those lines that's appropriately reporting to python. This is probably all basic C++ operational stuff but its all totally beyond me since I'm not learning from a procedural college class setting here. Maybe AIAndy or Koshling could help us here?

 

[Dancing Hoskuld]

I'm not sure if I can really compile this correctly or properly in the dll first but I AM exposing the promotionline and its tag infos to Python right now. This would enable you to check against the promotion's promotionline for the information needed.

There's multiple tasks here but one example would be if looking for the prereqs as automatically assigned by promotionlines:
Loop through promos for any promo that matches the promotionline of the promo you're evaluating. Then display a promo from among that filtered list if that promo is at iLinePriority equal to 1 less than the iLinePriority of the evaluating promotion.

Might want to make sure that the promotion hasn't already been displayed by the normal check before telling it to display though. (to avoid duplicates in the list)

While I could code well enough to generate a proper list straight from a single vector established in the dll that could then be reported to python on this, I'm really not sure if I can do that without establishing a whole CvPromotions.cpp page like we have for CvUnit.cpp and then figure out how to get something along those lines that's appropriately reporting to python. This is probably all basic C++ operational stuff but its all totally beyond me since I'm not learning from a procedural college class setting here. Maybe AIAndy or Koshling could help us here?

So you want me to program something Python that you can't do in the DLL? Or are you saying that all the stuff I am doing in Python for the pedia is also done in the dll? I am confused.

On another topic I can't find the info on the sub combat classes, in particular the method I call on the unit to see if the sub combat class is valid for the unit.

 

[Thunderbrd]

So you want me to program something Python that you can't do in the DLL? Or are you saying that all the stuff I am doing in Python for the pedia is also done in the dll? I am confused.

What I'm trying to say is this:
Currently we're getting the information on promo prereqs directly passed from xml to the dll then passed directly to python. Then apparently this is combined in the python for the Promotions pedia page.

I can see how the dll could generate a list that compiles those three tags, prereqpromotion, prereqORPromotion and prereqORPromotion2 as well as tossing in the promotionline's prereq promotion that could then be reported to python so that would then simplify the programming in the python for the pedia page.

However, I may not have the skill for this since Promotions don't have a more in-depth page of their own like units do. It might be possible to do it in the CvInfos.cpp file under each given promotion individually but I can see some potential problems with this approach that I'm not sure if this would be the right or even ok way to go about this. Additionally, I'm not sure how the OR factor (as in some promotions may be used in place of others) is displayed in the pedia currently but it'd take even more effort and probably a couple of functions exposed to the python that would then need to be combined in the python for the pedia page to be done correctly. Perhaps it would be possible to generate a new function and report it to python that gives a list of only the primary promo prereq combined with any promotionline applicable promo prereqs and that could be used in place of the current singular primary promo prereq. But I'm not sure this is even worthwhile since it would require as extensive a programming effort in the python as simply exposing the promotionline's prerequisite to be added to the promo alone.

Perhaps I should clarify that, according to rules established in the dll, we may currently assign a promotion prerequisite to only the promotionline and that then applies to all promotions in that line. The problem is that's not showing up in the pedia for those promotions. (I think that's clear but just in case it's not and that's what you're confused on I figured I'd restate that.)

On another topic I can't find the info on the sub combat classes, in particular the method I call on the unit to see if the sub combat class is valid for the unit.

Perhaps a programmer here who's a bit more knowledgeable in how python interacts with the dll can assist on answering this question. I BELIEVE I did sufficiently report the full sub combat mechanism but I could be wrong.

I did report those in CyInfoInterface1:

		.def("getSubCombatType", &CvUnitInfo::getSubCombatType, "int (int i)")
		.def("getNumSubCombatTypes", &CvUnitInfo::getNumSubCombatTypes, "int ()")
		.def("isSubCombatType", &CvUnitInfo::isSubCombatType, "int (int i)")

Where the rest of the base unit info is defined such as, for example:

		.def("isAnimal", &CvUnitInfo::isAnimal, "bool ()")

 

[Dancing Hoskuld]

What I'm trying to say is this:
Currently we're getting the information on promo prereqs directly passed from xml to the dll then passed directly to python. Then apparently this is combined in the python for the Promotions pedia page.

I can see how the dll could generate a list that compiles those three tags, prereqpromotion, prereqORPromotion and prereqORPromotion2 as well as tossing in the promotionline's prereq promotion that could then be reported to python so that would then simplify the programming in the python for the pedia page.

However, I may not have the skill for this since Promotions don't have a more in-depth page of their own like units do. It might be possible to do it in the CvInfos.cpp file under each given promotion individually but I can see some potential problems with this approach that I'm not sure if this would be the right or even ok way to go about this. Additionally, I'm not sure how the OR factor (as in some promotions may be used in place of others) is displayed in the pedia currently but it'd take even more effort and probably a couple of functions exposed to the python that would then need to be combined in the python for the pedia page to be done correctly. Perhaps it would be possible to generate a new function and report it to python that gives a list of only the primary promo prereq combined with any promotionline applicable promo prereqs and that could be used in place of the current singular primary promo prereq. But I'm not sure this is even worthwhile since it would require as extensive a programming effort in the python as simply exposing the promotionline's prerequisite to be added to the promo alone.

Perhaps I should clarify that, according to rules established in the dll, we may currently assign a promotion prerequisite to only the promotionline and that then applies to all promotions in that line. The problem is that's not showing up in the pedia for those promotions. (I think that's clear but just in case it's not and that's what you're confused on I figured I'd restate that.)

"All" I would expect is that instead of those three methods now used new methods which provide the same functionality as is used in techs, units and buildings. In fact I would have thought all three would have been similar just using a different base class. This is not in my highest priority list at the moment so I can mull over what needs to be done and hopefully come up with an amazing solution.

I did report those in CyInfoInterface1:

		.def("getSubCombatType", &CvUnitInfo::getSubCombatType, "int (int i)")
		.def("getNumSubCombatTypes", &CvUnitInfo::getNumSubCombatTypes, "int ()")
		.def("isSubCombatType", &CvUnitInfo::isSubCombatType, "int (int i)")

Where the rest of the base unit info is defined such as, for example:

		.def("isAnimal", &CvUnitInfo::isAnimal, "bool ()")

In the code I wrote before you exposed the methods I assumed isSubCombatType would be isSubCombatValid ie it matches the Promotions. Never mind I should have it ready to update soon. I may also get the split in Promotions so that the Equipment and Afflictions are on different pages.

We really need a page or pages for the stuff being added both tags and methods exposed to python. One similar to what Afforess did. Given that at least three people are adding tags and methods I suppose each of you could have a page you update which is then linked to the Modders documentation in some way.

 

[Thunderbrd]

Do we have a link to the one Afforess did so we can take a look at the template you're asking for?

Thanks for your help... I know trying to communicate with me on these dll-python matters is a pain since I'm not the greatest at expressing these concepts.

"All" I would expect is that instead of those three methods now used new methods which provide the same functionality as is used in techs, units and buildings. In fact I would have thought all three would have been similar just using a different base class

It's most likely possible as I'm trying to say... just perhaps a bit beyond my skill grade.

 

[Dancing Hoskuld]

Do we have a link to the one Afforess did so we can take a look at the template you're asking for?

For the XML there is a link in the modders document to Afforess's stuff but here is the direct link

 

[Thunderbrd]

Ah... I see what you mean. Yeah, eventually would be good to compile it all in one place I think.

 

[Dancing Hoskuld]

There is. We have bEquipment and bAffliction tags. I believe those are exposed to python but I'll check.

Are they exposed and how? Is it a isEquipment() method on the promotion? I assume that a promotion can't be both.

 

[Thunderbrd]

CyInfoInterface1 has them exposed already.

yes, isEquipment() and isAffliction().

The promotionline actually establishes this by tag usually but the promotion inherits that definition into its own isEquipment and isAffliction functions.

There's nothing to ENFORCE that a promotion can't be both but it would be a mistake in xml if they were both made true.

 

[Dancing Hoskuld]

CyInfoInterface1 has them exposed already.

yes, isEquipment() and isAffliction().

The promotionline actually establishes this by tag usually but the promotion inherits that definition into its own isEquipment and isAffliction functions.

There's nothing to ENFORCE that a promotion can't be both but it would be a mistake in xml if they were both made true.

OK, I assumed that was the case. Are there any promotions of these types yet? I am not seeing any?

 

[Thunderbrd]

Not yet, no. But having pages for them in the pedia will be important to have when they start going into design and application.

 

[AIAndy]

@AIANdy The code I am using that gets the no such method is

	def placeStats(self):
		screen = self.top.getScreen()
		panelName = self.top.getNextWidgetName()
		iCombatType = gc.getUnitInfo(self.iUnit).getUnitCombatType()
		[B]iWorkRate = gc.getUnitInfo(self.iUnit).workRate(True)[/B]

Is it obvious what it is that I am doing wrong?

The workRate method that TB exposed is on the unit, not the unit type info. There is a getWorkRate method exposed on the unit type info which returns the base work rate of a unit.

 

[Dancing Hoskuld]

The workRate method that TB exposed is on the unit, not the unit type info. There is a getWorkRate method exposed on the unit type info which returns the base work rate of a unit.

I tried that one too but got the same method not found or global variable not defined. maybe I misread the doco on that one. I'll try it again. Thanks.

 

[AIAndy]

I tried that one too but got the same method not found or global variable not defined. maybe I misread the doco on that one. I'll try it again. Thanks.

This is from the Python interface file:
.def("getWorkRate", &CvUnitInfo::getWorkRate, "int ()")
So it takes no parameters and returns an int.

 

[Dancing Hoskuld]

Do we have a tag on buildings that reduces the cost of one or more technologies?

 

[Hydromancerx]

Do we have a tag on buildings that reduces the cost of one or more technologies?

Not that I know of. But I could see where that would be very useful.

 

[Dancing Hoskuld]

OK I talked about putting some missions and outcomes on all subdued and tales of animals. In particular I want to put the two missions "record tale of" and "study" on all of them. The first provides culture and science the second just science. The return is determined by the buildings you have in the city and will be scaled to game speed etc.

Currently I have the same code (unscaled) on each animal. Now I want it on the combat class. Do I just add Actions to the combat class definition?

 

[Dancing Hoskuld]

I had the outcomes working when in the unit infos but when I transfer them to the unit combat I get the message

Assert Failed

File:  CvGlobals.cpp
Line:  5195
Expression:  stricmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message:  info type ADAPT_DEFAULT not found, Current XML file is: modules\DancingHoskuld\Subdue_Animals\Subdue_Animals_CIV4UnitCombatInfos.xml

----------------------------------------------------------