Small Questions Thread

[Prof. Garfield]

This thread is mean as a place to ask questions that it doesn't make sense to devote an entire thread to.

I'm writing a "promotions" module, and one thing that I thought of was to alter the chance that a unit would be promoted in combat to veteran.

The issue that I run into is that the game shows a message when a unit is promoted. If the chance of promotion is increased, then I can simply display a message when lua promotes when the game would not have. However, if the promotion chance is reduced, that means that a message will be shown when the game promotes the unit, but the unit is not really promoted.

Is there a way to stop the game from displaying the promotion text box?

If not, which of the following makes more sense?

1. Show a promotion text for 100% of promotions, and let the scenario designer change the promotion text from Game.txt.

2. If lua 'cancels' a promotion, show a message explaining that the scenario has a lower than usual promotion chance, and that the unit wasn't promoted.

 

[JPetroski]

I think you have to anticipate that some designers will forget to do #1, so you have to go with #2. Its an easy enough thing to disable if it really bothers someone enough that they wish to change via #1.

Also, I'm uncertain what will happen if this text is simply deleted. I don't think anyone has ever had occasion to do this. I can check it out later tonight.

 

[CurtSibling]

Is there any way to add extra promotion levels above veteran, like in CIV3?

 

[Prof. Garfield]

Also, I'm uncertain what will happen if this text is simply deleted. I don't think anyone has ever had occasion to do this. I can check it out later tonight.

It seems to get the text from somewhere else.

I think you have to anticipate that some designers will forget to do #1, so you have to go with #2. Its an easy enough thing to disable if it really bothers someone enough that they wish to change via #1.

That makes sense. Upon reflection, it might not be too difficult to have both options available, and just change a parameter somewhere.

Is there any way to add extra promotion levels above veteran, like in CIV3?

Yes, by replacing the promoted unit with a new one of a different type. So, you probably don't want to do it with every unit type. Air units would gain their full range upon promotion (since we can't access/change the variable that keeps track of turns aloft at the moment), but otherwise it should be fine.

 

[JPetroski]

I don't know that this thread was meant simply for lua or not but I'm assuming not - I have a small question:

Does anyone know if the "objective" label on a city has any impact towards AI behavior? Specifically, will it drive an AI to advance towards a city moreso than without it?

 

[countmc]

This may be a stupid question, but with Lua, is there a way to promote three levels? What I mean is more of a basic, to middle, to advance? Or Recruit, Veteran, and then Elite? Obviously it would be hard to reach Elite status.

Just curious. Thanks the stuff you guys are doing is keeping a great game alive.

 

[Dadais]

This may be a stupid question, but with Lua, is there a way to promote three levels? What I mean is more of a basic, to middle, to advance? Or Recruit, Veteran, and then Elite? Obviously it would be hard to reach Elite status.

Just curious. Thanks the stuff you guys are doing is keeping a great game alive.

That's indeed possible. Howether, they are at least two ways of doing so.

First is well explained by ProfGarfield and shall work properly ... can't find where :
1 Use two unit slots per unit, first to have the recruit/Veteran, second allowing to have Elite/Rambo, playing with veteran status and others in the way.
2 When a "first unittype" unit with veteran status kills, gives it a chance to evolve (meaning, be destroyed then create the upgraded unittype, keeping as much status about it as possible and changing or not veteran status whether you wish 3 or 4 levels)

Second is only in minds, havn't read it elsewhere, and requires more work, machine ressources if it can work.
It has as advantages
-not to use more slot
-to allow as much evolutions as one wish, not limited per unit slot uses.
as disavantages are
-the sight of whether a unit is more than veteran is less visible (eg use a key to popup if the selected unit is veteran, elite, godmode, infinitly more stepped or no, just a rookie) :
-To unallow visible evolution (like it seems in some wonderfull aztec scenarios)
-One have to work more to build it for use.

1. Have a "promotedUnits" table to stock Key,Unit, and Level
2. When a unit dies, you may use alea to stock "units" winning already veteran, or not in this table.
3. Check this table before any fight to adapt the strengh of units if they are in this table.
4. Check this table whenever a unit dies, to remove it then (and shall tidy the table at the same time)

One must be sure not to use unit.id for this table key (which requires some more procedures building to keep the table clean), as Prof Garfield mentionned a unit id may change during play under some circonstances.
The unit may be the key howether, making the table build and use easier yet dirtier ?

 

[Prof. Garfield]

That's indeed possible. Howether, they are at least two ways of doing so.

First is well explained by ProfGarfield and shall work properly ... can't find where :
1 Use two unit slots per unit, first to have the recruit/Veteran, second allowing to have Elite/Rambo, playing with veteran status and others in the way.
2 When a "first unittype" unit with veteran status kills, gives it a chance to evolve (meaning, be destroyed then create the upgraded unittype, keeping as much status about it as possible and changing or not veteran status whether you wish 3 or 4 levels)

This is implemented in the template that @JPetroski and I plan to release shortly.

Second is only in minds, havn't read it elsewhere, and requires more work, machine ressources if it can work.
It has as advantages
-not to use more slot
-to allow as much evolutions as one wish, not limited per unit slot uses.
as disavantages are
-the sight of whether a unit is more than veteran is less visible (eg use a key to popup if the selected unit is veteran, elite, godmode, infinitly more stepped or no, just a rookie) :
-To unallow visible evolution (like it seems in some wonderfull aztec scenarios)
-One have to work more to build it for use.

1. Have a "promotedUnits" table to stock Key,Unit, and Level
2. When a unit dies, you may use alea to stock "units" winning already veteran, or not in this table.
3. Check this table before any fight to adapt the strengh of units if they are in this table.
4. Check this table whenever a unit dies, to remove it then (and shall tidy the table at the same time)

One must be sure not to use unit.id for this table key (which requires some more procedures building to keep the table clean), as Prof Garfield mentionned a unit id may change during play under some circonstances.
The unit may be the key howether, making the table build and use easier yet dirtier ?

I no longer think that unit.id numbers are changed. I ran an experiment where a couple thousand units were deleted, and the units with larger id numbers weren't moved after a save and load. So, unit id would make a good key. (Using the unit itself as the key would be the same thing, I think. I'm pretty sure that when the state table is saved, a unit simply becomes civ.getUnit(unit.id).

I'm pretty sure your idea would work, but you'd have to 'maintain' the table to account for when units are lost. This could be a problem, since we don't have a trigger for disbanding units. Actually, I think all you would have to do is maintain the table when units are created (I think we can find all of those, since they are either the result of production or events, both of which can be tracked).

 

[Dadais]

I no longer think that unit.id numbers are changed. I ran an experiment where a couple thousand units were deleted, and the units with larger id numbers weren't moved after a save and load. So, unit id would make a good key. (Using the unit itself as the key would be the same thing, I think. I'm pretty sure that when the state table is saved, a unit simply becomes civ.getUnit(unit.id).

Much thanks !

I'm pretty sure your idea would work, but you'd have to 'maintain' the table to account for when units are lost. This could be a problem, since we don't have a trigger for disbanding units. Actually, I think all you would have to do is maintain the table when units are created (I think we can find all of those, since they are either the result of production or events, both of which can be tracked).

I thought so, yet didn't put much a though in it, thus keeping reserves.

You're right on the disbanding point, I guess the table shall rather be cleaned each turn, looking for nil values on any of the elements or keys. Do the table.remove(key) function work properly in civ environment by the way ?

About the power it could hold,
-One may even use the veteran status to trigger this kind of promotions, allowing for more specialised veterancy based on unitType than the core civ2 generic bonus ?
-Worse, Such a promotion system would allow "SpecialityBonuses" trees somehow like in civIV (initiating dialog to choose when unit have the veteran status then remove that status for it to be earned again and have another promotion or upgrade one already owned), having "garrison, looter, mounteneer, forester, defender, attaquer, antidwarf, antielf"... for ground units ?

I find interesting to have promotion of enemies hidden, yet sad that UI wouldn't have such a promotion system friendly accessible to player, needing use of another keyboard button.

I failed to mention that table would need to be saved with/in the state variable to survive save/load.

 

[techumseh]

I don't know that this thread was meant simply for lua or not but I'm assuming not - I have a small question:

Does anyone know if the "objective" label on a city has any impact towards AI behavior? Specifically, will it drive an AI to advance towards a city moreso than without it?

Not to my knowledge.

 

[Dadais]

Two little questions :

-Do "Spaced", "sleeping" and "Fortified" unit which havn't moved this turn still have their unit.moveSpent at 0 ?
(Purposed on an AA autodefense system)

-Imagining a following bombardment system which :
1.Don't create ammunition for bombers which seems complicated (or heavy) for AI to use (or make use)
2.Don't allow damaged planes to move.
3.To figure bombing, have AirUnit attaquing nonAA ground&sea units restore their life or if didn't manage to finish their target (destroyed), create it back to where it was, with movepoints spent.
4. Similarly, have AAground unit restored or created back after attacking planes.
5.Off course, have planes attack and firepower adapted for that bombing purpose.

Would the IA handle it ?

 

[JPetroski]

If you hit "space" you expend the MP, if you hit S, you probably don't, if you hit F you probably do, but I'm not sure. If a unit starts a turn sleeping or fortified it certainly hasn't had its movespent, one would think.

Have you checked out OTR? We have a reaction system there with air defenses that you might want to tinker with (well, you might want to check out simpleReactions rather than the OTR reactions but still).

As it was MP, we had munitions trigger, this, but if you aren't using munitions, given that the AI triggers onActivate every space it moves, you could simply have the triggering unit be the AI unit activating within x number of tiles of the defensive unit.

This wouldn't help the AI attack your bombers as onActivate does not check every tile for the human player, but then a munition for the bomber, including a payload mechanism, is a good feature and one I'd encourage you to use., especially if you plan to have aircraft that move over more than 2 turns.

 

[Dadais]

but then a munition for the bomber, including a payload mechanism, is a good feature and one I'd encourage you to use.

Actually, i'm running low with unit slot, looking for ai-friendly smooth-playing mechanics to solve that.
Which gives the second question.

First question only to scout an "air active defense" feature's architecture and gameplay possibilities.

 

[JPetroski]

If you don't have space for munitions, you could replicate the AI defense by still having the bomber press "K" and then having that deal damage to nearby units, perhaps after targeting them via a menu, while also exposing the bomber to reactive defensive fire?

The AI can simply target each other via onActivation which shoul/d work just fine with the bomber as the actual triggering unit.

 

[Dadais]

(Using the unit itself as the key would be the same thing, I think. I'm pretty sure that when the state table is saved, a unit simply becomes civ.getUnit(unit.id).

Not sure there.
Just printed toString(unit), trying to solve issues, thinking I would have their id :

it gives "Unit< type , owner , damage, moveSpent, x, y, z>" and their values in <>

 

[Prof. Garfield]

Not sure there.
Just printed toString(unit), trying to solve issues, thinking I would have their id :

it gives "Unit< type , owner , damage, moveSpent, x, y, z>" and their values in <>

unit.id definitely exists, I've used it frequently. I guess you'll just have to print it manually, i.e. tostring(unit.id). Actually, I think if you're using print(), tostring is applied automatically to each argument, so you might just be able to use print(unit,unit.id) to get the id number.

Whether using the unit itself as a key (especially in the state table) will work as expected, I'm not sure. I remember running into some issue when I tried to use a civ object as a key at some point, but I just switched to an integer rather than track down the problem and figure out what exactly was going wrong.

 

[Dadais]

Whether using the unit itself as a key (especially in the state table) will work as expected, I'm not sure. I remember running into some issue when I tried to use a civ object as a key at some point, but I just switched to an integer rather than track down the problem and figure out what exactly was going wrong.

I guess when converting the unit object to string, it just ignore the Key value of the unit table, which must be the id indeed.
Using the id shall be the safest.

 

[Dadais]

Little question here, about the tile object.

tile.defender shall be the tribe with units on it, else nil.

what with tile.owner ?
Is that defined by cities borders ? What with shared between cities tiles ? Is this another mecanics ?

 

[Knighttime]

Tile.owner is the tribe that most recently occupied the tile with a unit, even if none is present now. I believe this is the measurement that is used to compute the "Land area" for each tribe in Demographics.

So if tile.defender contains a tribe (is not nil), tile.owner should always contain the same tribe. But tile.owner will continue to store that "last occupant" tribe even if the unit moves away and the tile is empty. If tile.owner is nil, that means no unit from any tribe has ever entered the tile.

As far as I know, this isn't related to whether or not a city is working the tile. I'm pretty sure a city can work a tile it doesn't "own" as long as another unit isn't currently blocking it. Lua can also access which tiles a city works, via city.workers, although it's a bit complicated to parse. Medieval Millennium contains code for this, though, in utilTile.lua, and I think Prof. Garfield's General Library does too.

 

[Dadais]

Hello coders,

came to put nose in
"civ.scen.onResolveCombat(function (defaultResolutionFunction, attacker, defender)",
first testing only with two "prints" to see if I could take the attacker location from here (rather than onUnitKilled)
quite your tricky boy if I may say

May you confirm the order above is the right one (as it seemed to result from experiments)
Then, facing auto kills, I did add a "return true", happy an all, to have this zombies-fight
0

Spoiler :

So, a little
" if attacker.hitpoints > 0 and defender.hitpoints > 0 then
return true
else
return false
end"
in the end shall do the job like it seems to do, isn't it ?

/Edith : NO, damage isn't saved. Arf

ha, guess I understood, used rather
return defaultResolutionFunction(attacker, defender) which gives the ingame true of false.
yet unit still heal after fight...
Haha, got it a little more wounded, it healed between turns in fact.It shall work well !