which is right

[Lady Wandbender]

which is the right way to do this? (to add multiple units into the list)

def doFrostling(argsList):
kTriggeredData = argsList[0]
pPlot = gc.getMap().plot(kTriggeredData.iPlotX, kTriggeredData.iPlotY)
bPlayer = gc.getPlayer(gc.getBARBARIAN_PLAYER())
newUnit = bPlayer.initUnit(gc.getInfoTypeForString('UNIT_FROSTLING'), pPlot.getX(), pPlot.getY(), UnitAITypes.NO_UNITAI,
newUnit = bPlayer.initUnit(gc.getInfoTypeForString('UNIT_FROSTLING'), pPlot.getX(), pPlot.getY(), UnitAITypes.NO_UNITAI,
DirectionTypes.DIRECTION_SOUTH)

or

def doFrostling(argsList):
kTriggeredData = argsList[0]
pPlot = gc.getMap().plot(kTriggeredData.iPlotX, kTriggeredData.iPlotY)
bPlayer = gc.getPlayer(gc.getBARBARIAN_PLAYER())
newUnit = bPlayer.initUnit(gc.getInfoTypeForString('UNIT_FROSTLING'), pPlot.getX(), pPlot.getY(), UnitAITypes.NO_UNITAI,
bPlayer = gc.getPlayer(gc.getBARBARIAN_PLAYER())
newUnit = bPlayer.initUnit(gc.getInfoTypeForString('UNIT_FROSTLING'), pPlot.getX(), pPlot.getY(), UnitAITypes.NO_UNITAI,
DirectionTypes.DIRECTION_SOUTH)

and assuming a Unit_Settler is on that list, the AI will go ahead and make a city? and Units_ with summon promotions, will use them when they get in combat? (like Barbatos)

also can I please beg someone to create a code for me, that does what the Statue of Zues did for civ3? (units every X turns) the one I found online never worked.

what I wanna do is:

Spoiler :

create barbarian cities on mana nodes, then give barb's a palace which will then create a free forge which will then create a "statue of zues" that will shoot out barbs a little faster (nastier) than the current improvement useage. and at different turn levels the barbarian "Flavor" will change from like Orcs to Ogres to dragons(mini dragons)

 

[Vehem]

which is the right way to do this? (to add multiple units into the list)

def doFrostling(argsList):
kTriggeredData = argsList[0]
pPlot = gc.getMap().plot(kTriggeredData.iPlotX, kTriggeredData.iPlotY)
bPlayer = gc.getPlayer(gc.getBARBARIAN_PLAYER())
newUnit = bPlayer.initUnit(gc.getInfoTypeForString('UNIT_FROSTLING'), pPlot.getX(), pPlot.getY(), UnitAITypes.NO_UNITAI,
newUnit = bPlayer.initUnit(gc.getInfoTypeForString('UNIT_FROSTLING'), pPlot.getX(), pPlot.getY(), UnitAITypes.NO_UNITAI,
DirectionTypes.DIRECTION_SOUTH)

or

def doFrostling(argsList):
kTriggeredData = argsList[0]
pPlot = gc.getMap().plot(kTriggeredData.iPlotX, kTriggeredData.iPlotY)
bPlayer = gc.getPlayer(gc.getBARBARIAN_PLAYER())
newUnit = bPlayer.initUnit(gc.getInfoTypeForString('UNIT_FROSTLING'), pPlot.getX(), pPlot.getY(), UnitAITypes.NO_UNITAI,
bPlayer = gc.getPlayer(gc.getBARBARIAN_PLAYER())
newUnit = bPlayer.initUnit(gc.getInfoTypeForString('UNIT_FROSTLING'), pPlot.getX(), pPlot.getY(), UnitAITypes.NO_UNITAI,
DirectionTypes.DIRECTION_SOUTH)

and assuming a Unit_Settler is on that list, the AI will go ahead and make a city? and Units_ with summon promotions, will use them when they get in combat? (like Barbatos)

also can I please beg someone to create a code for me, that does what the Statue of Zues did for civ3? (units every X turns) the one I found online never worked.

what I wanna do is:

Spoiler :

create barbarian cities on mana nodes, then give barb's a palace which will then create a free forge which will then create a "statue of zues" that will shoot out barbs a little faster (nastier) than the current improvement useage. and at different turn levels the barbarian "Flavor" will change from like Orcs to Ogres to dragons(mini dragons)

Either looks like it will work, though the second version defines bPlayer twice with no difference between them - which is redundant (works, but not needed). Also, the "newUnit = " part is redundant unless you want to then do anything else to the unit (such as naming it, setting promotions/experience etc). bPlayer.initUnit(.... will work without assigning it to newUnit.

Regarding the settlers - interesting question. In principle, a Barbarian settler with it's AI set correctly probably should be able to settle a city, but the reports are that Barbarian settlers have caused issues (including spinlocks apparently).

It is possible though to use initCity to create a barbarian city where you want it.

 

[Lady Wandbender]

so instead of using:

newUnit = bPlayer.initUnit(gc.getInfoTypeForString('UNIT_FRO STLING'), pPlot.getX(), pPlot.getY(), UnitAITypes.NO_UNITAI,

it would just be

Bplayer.initcity
or do I need to add something more?


and what is the difference between bplayer and eplayer?

And thank you so much Vehem I really appriciate all the time you take with people like me trying to learn what to do without having to constantly keep asking dumb questions.

 

[MagisterCultuum]

I can't really say if either is right unless you use [code] [/code] tags around them so that the tabs show up.

 

[Vehem]

so instead of using:

newUnit = bPlayer.initUnit(gc.getInfoTypeForString('UNIT_FRO STLING'), pPlot.getX(), pPlot.getY(), UnitAITypes.NO_UNITAI,

it would just be

Bplayer.initcity
or do I need to add something more?


And thank you so much Vehem I really appriciate all the time you take with people like me trying to learn what to do without having to constantly keep asking dumb questions.

For initCity we have...

CyCity initCity (int plotX, int plotY)
initCity( plotX, plotY ) - spawns a city at x,y

so we'd need

bPlayer.initcity(pPlot.getX(), pPlot.getY())

and what is the difference between bplayer and eplayer?

In this case, nothing - it's just a "naming convention" and in this case it's used wrongly anyway.

The lowercase letter that appears before most variables is used to describe what "type" of variable it is. Python doesn't care too much about typing (not as much as a lot of other languages in anycase), but it's still useful to know what it should be. It's basically used as follows...

iRnd - i denotes "Integer" - a whole number. Rnd is a name that is assigned to the variable. In this case, without having see any other code, I'd assume it was a "random number". If it was called "Bob" (which is valid codewise) - I'd have no clue what the variable actually was.

pCity - p denotes "Pointer" - simplest terms, it's referring to something that exists in the game, not something that we've just made up for the sake of the script. The "pointer" points to the actual object we're talking about. Again, because it's called pCity, I know that it's a pointer to a city object - and I can "ask it" for things like City Population or Current Culture. It could again just have been called "Bob" - but again - this isn't helpful.

bHasCasted - b denotes "Boolean" - True or False. This one tracks if the unit has cast a spell this turn. Bob is no good here either.

aUnitList - a denotes "Array" - you don't see this one too often in the Civ4 Python code. An array is a collection of something - numbers, pointers to units, words etc... The naming convention allows it to be combined with the "type" that it is a collection of - apUnitList would be an "array of pointers".

ePlayer - e denotes an "enumeration" - in this case the "number of the player". Player0, Player1, Player2 etc... Again - not many of these in the Civ code - they tend to use iPlayer instead (which is at least partially right as it is a number - it's just not fully in the spirit of the convention)

​

In your first example - ePlayer and bPlayer;

ePlayer - the player number
bPlayer - NOT a boolean (True/False) named player. They've broken the naming convention.
​

They actually mean the Barbarian player. gc.getBARBARIAN_PLAYER() should probably be assigned to eBarbPlayer (the number of the Barbarian Player). getPlayer(eBarbPlayer) would be pBarbPlayer (a pointer to the actual Player Object owned by the barbarians).

===

Head hurt yet?

Short version - if you're not sure, don't worry about it too much. The variable name isn't important anyway in the end - its just helpful to not have to deal with Bob everytime...

 

[Lady Wandbender]

thank you so much Vehem, for taking the time for this, hopefully it will help out other neophytes who are looking to start this long process of learning enough to do things without handholding every step of the way.

It is really great of you to take the time.

 

[Vehem]

thank you so much Vehem, for taking the time for this, hopefully it will help out other neophytes who are looking to start this long process of learning enough to do things without handholding every step of the way.

It is really great of you to take the time.

No problem - in theory if I help 5 people, then the next 25 belong to them

 

[Bad Player]

For initCity we have...

CyCity initCity (int plotX, int plotY)
initCity( plotX, plotY ) - spawns a city at x,y

so we'd need

bPlayer.initcity(pPlot.getX(), pPlot.getY())

In this case, nothing - it's just a "naming convention" and in this case it's used wrongly anyway.

The lowercase letter that appears before most variables is used to describe what "type" of variable it is. Python doesn't care too much about typing (not as much as a lot of other languages in anycase), but it's still useful to know what it should be. It's basically used as follows...

iRnd - i denotes "Integer" - a whole number. Rnd is a name that is assigned to the variable. In this case, without having see any other code, I'd assume it was a "random number". If it was called "Bob" (which is valid codewise) - I'd have no clue what the variable actually was.

pCity - p denotes "Pointer" - simplest terms, it's referring to something that exists in the game, not something that we've just made up for the sake of the script. The "pointer" points to the actual object we're talking about. Again, because it's called pCity, I know that it's a pointer to a city object - and I can "ask it" for things like City Population or Current Culture. It could again just have been called "Bob" - but again - this isn't helpful.

bHasCasted - b denotes "Boolean" - True or False. This one tracks if the unit has cast a spell this turn. Bob is no good here either.

aUnitList - a denotes "Array" - you don't see this one too often in the Civ4 Python code. An array is a collection of something - numbers, pointers to units, words etc... The naming convention allows it to be combined with the "type" that it is a collection of - apUnitList would be an "array of pointers".

ePlayer - e denotes an "enumeration" - in this case the "number of the player". Player0, Player1, Player2 etc... Again - not many of these in the Civ code - they tend to use iPlayer instead (which is at least partially right as it is a number - it's just not fully in the spirit of the convention)

​

In your first example - ePlayer and bPlayer;

ePlayer - the player number
bPlayer - NOT a boolean (True/False) named player. They've broken the naming convention.
​

They actually mean the Barbarian player. gc.getBARBARIAN_PLAYER() should probably be assigned to eBarbPlayer (the number of the Barbarian Player). getPlayer(eBarbPlayer) would be pBarbPlayer (a pointer to the actual Player Object owned by the barbarians).

===

Head hurt yet?

Short version - if you're not sure, don't worry about it too much. The variable name isn't important anyway in the end - its just helpful to not have to deal with Bob everytime...

You mentioned this naming convention to me but I didn't get it until this post - thanks!