AW Arcaeca
Deus Vult
Can't find it on the UI reference. :/ What parameters does it pass?
Also, do you know if it's G&K-compatible?
Also, do you know if it's G&K-compatible?
A couple more "quick" inquiries
- Thread starter AW Arcaeca
- Start date
LeeS
Imperator
http://forums.civfanatics.com/showpost.php?p=13628161&postcount=28
GameEvents.UnitPrekill(iOwner, iUnit, iUnitType, iX, iY, bDelay, iKiller)
GameEvents.UnitPrekill(iOwner, iUnit, iUnitType, iX, iY, bDelay, iKiller)
AW Arcaeca
Deus Vult
Alright, thanks. I'll get to work then and see if it works 
AW Arcaeca
Deus Vult
So, the algorithm isn't working... :/
It was able to resurrect the unit, until I discovered that that wouldn't stop the killer unit from still wandering onto the plot. And so I basically ended up with a unit on the same plot as 6 enemy units, when I surrounded it with 6 Barbarian marines so it would be instantly killed... 
So I added in the last segment of code (beginning with "else"), which is supposed to push the killer unit back one tile after being killed - that's the MoveUnitBackwards() function at the end of the code:
And now... the unit just dies and nothing else happens.
I'm pretty sure you should be able to plug the code into any mod and change UNIT_AW_UNIT to whatever else you want, add one to the game via IGE, surround with Barbs, and see for yourself.
Spoiler :
So I added in the last segment of code (beginning with "else"), which is supposed to push the killer unit back one tile after being killed - that's the MoveUnitBackwards() function at the end of the code:
Spoiler :
I'm pretty sure you should be able to plug the code into any mod and change UNIT_AW_UNIT to whatever else you want, add one to the game via IGE, surround with Barbs, and see for yourself.
LeeS
Imperator
without looking into anything else, there's a problem right here: "pMetsikhovne:SetHasPromotion(v, true)". This is undefined so far as I can see: pMetsikhovne.
Don't try to recreate the 'killed' unit on the same plot as this is bound to have troubles, just shift the resurrected unit to the nearest valid plot.
If you want to you can then reposition the enemy unit that occupied the original tile, and re-position pNewUnit to the original tile where it was positioned, and then re-re-position the enemy unit.
The other thing you are not doing is setting any damage to pNewUnit, so not only does it get resurrected, it gets returned to 100% health.
-----------------------------------------------
edit -->
You actually need to run your code when bDelay is 'false' and when 'iKiller' is '-1', because then all units seen under the event as being 'on the plot' will still give valid data, including the unit that is 'dead', as well as any civilian units that were on the plot and under the protection of the defeated unit. Plus, the game is not still in the process of killing off the defeated unit, which it still is in the method you are employing.
Don't try to recreate the 'killed' unit on the same plot as this is bound to have troubles, just shift the resurrected unit to the nearest valid plot.
Code:
local tPromotions = {}
for row in GameInfo.UnitPromotions() do if (pUnit:IsHasPromotion(row.ID)) then table.insert(tPromotions, row.ID) end end -- Have fun reading that :p
local iLevel = pUnit:GetLevel()
local iExperience = pUnit:GetExperience() + GameInfo.Units[GameInfoTypes.UNIT_AW_UNIT].XPValueDefense
local pNewUnit = pPlayer:InitUnit(GameInfoTypes.UNIT_AW_UNIT, iX, iY)
[COLOR="Blue"]pNewUnit:JumpToNearestValidPlot()[/COLOR]
pNewUnit:SetExperience(iExperience)
pNewUnit:SetLevel(iLevel)
for k,v in pairs(tPromotions) do pNewUnit:SetHasPromotion(v, true) end
print("unit brought back from the brink of death!")The other thing you are not doing is setting any damage to pNewUnit, so not only does it get resurrected, it gets returned to 100% health.
-----------------------------------------------
edit -->
- bDelay returns true before unit is killed (before UnitKilledInCombat) and there will be only one unit on the plot
- bDelay returns false after the unit is killed (after UnitKilledInCombat) and an enemy melee unit may be on the same plot at this point. Both the victorious unit and the defeated unit will be 'seen as' occupying the plot at this point, as well as any civilian unit which survived the combat.
- iKiller will be the ID # of the victorious player only when bDelay is true (edit: and there was actual combat)
- iKiller will be '-1' when bDelay is false
- the only way that iKiller can be '-1' and bDelay can be true is if you kill off your own unit, for example, use a settler to create a city.
- the only way that bDelay can be false and iKiller can be anything except '-1' is if a Barb (for example) kills off a civilian unit. It is the civilian unit that is the key to the behavior in this case.
You actually need to run your code when bDelay is 'false' and when 'iKiller' is '-1', because then all units seen under the event as being 'on the plot' will still give valid data, including the unit that is 'dead', as well as any civilian units that were on the plot and under the protection of the defeated unit. Plus, the game is not still in the process of killing off the defeated unit, which it still is in the method you are employing.
AW Arcaeca
Deus Vult
"pMetsikhovne" is just the name of the variable that I renamed to pNewUnit for the purpose of posting this code here. Redaction, you know. Secrecy. Looks I missed one though. :/
I'm wary of Unit.JumpToNearestValidPlot(). During an earlier test, I believe that line was somewhere in the code, and my unit got teleported some ridiculous number of tiles away and, surprise! I suddenly meet Shaka because my unit died. Plot jumping makes weird things happen.
Intended
So then... this line should've spit out an error:
Code:
for mUnit in Players[iKiller]:Units() doI guess then I would have to have a variable outside of the function that stores the value of iKiller when bDelay = true...
So:
When bDelay = true and 0 <= iKiller <= GameDefines.MAX_MAJOR_CIVS, retrieve iKiller and store outside the function[/INDENT]
Else: move the killer unit THEN proceed to resurrect the dead unit
Should that work, or have I still misunderstood something?
LeeS
Imperator
"pMetsikhovne" is just the name of the variable that I renamed to pNewUnit for the purpose of posting this code here. Redaction, you know. Secrecy. Looks I missed one though. :/
I'm wary of Unit.JumpToNearestValidPlot(). During an earlier test, I believe that line was somewhere in the code, and my unit got teleported some ridiculous number of tiles away and, surprise! I suddenly meet Shaka because my unit died. Plot jumping makes weird things happen.
Intended
So then... this line should've spit out an error:
Because there is no player #-1. But if it never spit out an error, then it must be because it never reached that line... because why?Code:for mUnit in Players[iKiller]:Units() do
I guess then I would have to have a variable outside of the function that stores the value of iKiller when bDelay = true...
So:
When bDelay = true and 0 <= iKiller <= GameDefines.MAX_MAJOR_CIVS, retrieve iKiller and store outside the function[/INDENT]
Else: move the killer unit THEN proceed to resurrect the dead unit
Should that work, or have I still misunderstood something?
You won't have viable data on the 'killer' until after UnitKilledInCombat fires, ie, when ikiller is -1 and bDelay is false. And then you will only have info for a melee or other direct-attack unit that occupied the target tile as a result of the combat. Ranged units will never 'folloow-up and occuy the tile' so there will never be any usable information on them.
So, yes, you'll need to cache the iKiller info when bDelay is true and then make use of iKiller data you just cached as necessary when bDelay is false. So you'll need a variable outside of the UnitPreKill event that stores this info, which you then stick the 'iKiller' data info when bDelay it true, read back out of when bDelay is false, and then set back to some form of 'nil' value as soon as your code has completed running when bDelay is false.
But you also have to sort out and discard the cases of self-killed units, such as by disbanding. bDelay should be true in such cases, and the ikiller data at that point should be the same as the iOwner data.
Never claimed any of this would be easy -- just claimed it would be possible.
------------------------------------------------------------------------
Code:
if (iKiller < 0) then return end
whoward69
DLL Minion
You'll need to use an array/hash and index by a combination of iPlayerId and iUnitId for the dying unit, as the DLL is capable of sending nested events, eg PreKill(A, 1, false), PreKill(B, 2, false), PreKill(B, 2, true), PreKill(A, 1, true)
AW Arcaeca
Deus Vult
Eh? 
But the player and unit IDs are still passed by the game event even when bDelay is false, so I don't understand why they need to be stored. iKiller does need to be stored since its value changes with bDelay, but why are we bringing an extra table into this?
(part of this is that I only understood the first half of your sentence to begin with. :/ "Nested events" are unfamiliar and uncharted lua territories to the 16NP)
But the player and unit IDs are still passed by the game event even when bDelay is false, so I don't understand why they need to be stored. iKiller does need to be stored since its value changes with bDelay, but why are we bringing an extra table into this?(part of this is that I only understood the first half of your sentence to begin with. :/ "Nested events" are unfamiliar and uncharted lua territories to the 16NP)
whoward69
DLL Minion
PreKill(A, 1, false)
PreKill(B, 2, false)
PreKill(B, 2, true)
PreKill(A, 1, true)
The events for the death of B are complete enclosed (nested within) the events for A.
If you use a single variable to remember something from the bDelay=false event, what you remembered for A will be overwritten by that for B so when you get the final event for A you will not be using the remembered value for A but the one for B (or possibly nil, depending on how you code it). So anything you need to remember for a unit between the bDelay=false and bDelay=true events has to be remembered against the unit (which is playerId + unitId)
PreKill(B, 2, false)
PreKill(B, 2, true)
PreKill(A, 1, true)
The events for the death of B are complete enclosed (nested within) the events for A.
If you use a single variable to remember something from the bDelay=false event, what you remembered for A will be overwritten by that for B so when you get the final event for A you will not be using the remembered value for A but the one for B (or possibly nil, depending on how you code it). So anything you need to remember for a unit between the bDelay=false and bDelay=true events has to be remembered against the unit (which is playerId + unitId)
AW Arcaeca
Deus Vult
Alright, I understand now, thanks. But looking at the logs, nothing seems to be nesting. I added the table in anyway, just to be safe, though.
But doesn't the killer, then, similarly need to be mapped to the victim player ID, such that it doesn't get screwed up by nesting as well?
The problem, I found, that was completely screwing everything up was...
Whoops. 
So I added a "not" in front of the parenthesis. And it works (pretty much) now! Definitely the most BA unit I ever made. I just tack on the invisible number 9001 (over 9000 
) to the unit and surround it with barb marines. Marines attack the unit, unit says "come at me bro", and then the marines die before my unit does.
Well, technically not, anyway. The unit dies, of course... a lot... but then just gets replaced by a new one.
Anyways, thanks everyone for their debugging aid!
But doesn't the killer, then, similarly need to be mapped to the victim player ID, such that it doesn't get screwed up by nesting as well?
The problem, I found, that was completely screwing everything up was...
Spoiler :
So I added a "not" in front of the parenthesis. And it works (pretty much) now! Definitely the most BA unit I ever made. I just tack on the invisible number 9001 (over 9000 ) to the unit and surround it with barb marines. Marines attack the unit, unit says "come at me bro", and then the marines die before my unit does. Well, technically not, anyway. The unit dies, of course... a lot... but then just gets replaced by a new one.
Anyways, thanks everyone for their debugging aid!
whoward69
DLL Minion
Because it only happens very occasionally. Every time you get in a car it doesn't crash, but that's no excuse not to allow for the eventuality.
AW Arcaeca
Deus Vult
Ah gots an algorithmic problem!
(I'm sure I make lots of friends from reporting constant problem)
Mostly a math problem, actually. Anyone here good with math?
I currently have a functional script which forcefully hands over cities from player X to player Y whenever Z happens. Since that's not technically possible, technically I have a functional script that finds X's cities, records their population, name, plot, and list of buildings therein, and subsequently destroys them; afterwards a new player Y city is plopped atop the plot and modified to fit those specifications.
What it does not account for, as you can tell, is religious followers. Religion will therefore be utterly wiped out upon city conversion. I could make a table that records the number of followers for each religion present, since there's a City.GetNumFollowers() function:
...but how do I extract that data back out? There's no City.SetNumFollowers function, at least according to the Modiki.
There's a City.ConvertPercentFollowers, but therein is the problem... percent. We could find the population and divide by the number of, say, Tengriists in the city, and multiply by 100 to get the percentage of followers of Religion #-1 to convert to Tengriism. Right?
So that's all well and good until we throw in Taoism, since now the number of followers of -1 is no longer equivalent to the population of the city, but population minus Tengriists. Therefore, if I try the same algorithm as above, I'll end up converting a fewer number of -1ists to Taoism than I should.
So... anyone know how to logically end that line of calculations?
TL;DR If I know how many followers of each religion exist in a city, is there a way to give the same number of followers per religion to another city?
(I'm sure I make lots of friends from reporting constant problem)
Mostly a math problem, actually. Anyone here good with math?
I currently have a functional script which forcefully hands over cities from player X to player Y whenever Z happens. Since that's not technically possible, technically I have a functional script that finds X's cities, records their population, name, plot, and list of buildings therein, and subsequently destroys them; afterwards a new player Y city is plopped atop the plot and modified to fit those specifications.
What it does not account for, as you can tell, is religious followers. Religion will therefore be utterly wiped out upon city conversion. I could make a table that records the number of followers for each religion present, since there's a City.GetNumFollowers() function:
Code:
local tFollowers = {}
for row in GameInfo.Religions() do
tFollowers[row.ID] = pCity:GetNumFollowers(row.ID)
end...but how do I extract that data back out? There's no City.SetNumFollowers function, at least according to the Modiki.
There's a City.ConvertPercentFollowers, but therein is the problem... percent. We could find the population and divide by the number of, say, Tengriists in the city, and multiply by 100 to get the percentage of followers of Religion #-1 to convert to Tengriism. Right?
So that's all well and good until we throw in Taoism, since now the number of followers of -1 is no longer equivalent to the population of the city, but population minus Tengriists. Therefore, if I try the same algorithm as above, I'll end up converting a fewer number of -1ists to Taoism than I should.
So... anyone know how to logically end that line of calculations?
TL;DR If I know how many followers of each religion exist in a city, is there a way to give the same number of followers per religion to another city?
Craig_Sutter
Deity
That all seems unnecessary... I have a function that transfers cities from a city state to a player and does so without wholesale reconstruction. I'd have to look it over and I will post it when I get home, but it seems to me you are doing a lot of uneeded stuff.
Of course, I could easily be misunderstanding your intent.
I will post a copy of code in a 1/2 hour or so when I get home... it may or may not be useful to you....
Of course, I could easily be misunderstanding your intent.
I will post a copy of code in a 1/2 hour or so when I get home... it may or may not be useful to you....
Craig_Sutter
Deity
This is a really simple code...
My main question is, why aren't you using player:AcquireCity()? You can set it to "trade" rather than by "conquest". It maintains the same population. If it's a matter of buildings, it would likely be the same as a traded city (which I think means no destruction). The population will not fall if set to "traded" is true. You can also transfer units in the plot area by iterating plots... so why not use it.
Unless I am totally missing something.
Code:
--this transfers City States and their units to Northumbria at the acquisition of a certain technology
function OnTechNorthumbriaResearched(team, tech, change)
local NorthumbriaTeam
local NorthumbriaTeamID
local DeiraTeam
local DeiraTeamID
local Northumbria
local Deira
local iNorthumbria
-- Set up Northumbria Player
for iPlayer=0, GameDefines.MAX_MAJOR_CIVS-1 do
local pNorthumbria = Players[iPlayer]
if (GameInfo.Civilizations.CIVILIZATION_RUSSIA.ID == pNorthumbria:GetCivilizationType()) then
Northumbria = pNorthumbria
NorthumbriaTeamID = Northumbria:GetTeam();
NorthumbriaTeam= Teams[ Northumbria:GetTeam() ]
iNorthumbria = iPlayer
end
end
-- Set up Deira Player
for iPlayer=GameDefines.MAX_MAJOR_CIVS, GameDefines.MAX_CIV_PLAYERS-1, 1 do
local pDeira = Players[iPlayer]
if (GameInfo.MinorCivilizations.MINOR_CIV_DEIRA.ID == pDeira:GetMinorCivType()) then
Deira = pDeira
DeiraTeamID = Deira:GetTeam();
DeiraTeam= Teams[ Deira:GetTeam() ]
end
end
--local pPlayerTeam
if (tech == (GameInfoTypes["TECH_NOBILITY"])) and team == NorthumbriaTeamID and Deira:IsAlive() and Deira:IsAllies(iNorthumbria) then
-- Find Deira Units
for unit in Deira:Units() do
pUnit = unit
pNewOwner = Northumbria
convertUnitOwner(pUnit, pNewOwner)
end
--convert Deira Cities
for pCity in Deira:Cities() do
if pCity ~= nil then
print("Transferring...", pCity:GetName(), "to" , Northumbria:GetName(), "from", Deira:GetName() )
Northumbria:AcquireCity(pCity, false, true)
pCity:DoTask(TaskTypes.TASK_UNRAZE);
end
end
end
end
GameEvents.TeamTechResearched.Add(OnTechNorthumbriaResearched);My main question is, why aren't you using player:AcquireCity()? You can set it to "trade" rather than by "conquest". It maintains the same population. If it's a matter of buildings, it would likely be the same as a traded city (which I think means no destruction). The population will not fall if set to "traded" is true. You can also transfer units in the plot area by iterating plots... so why not use it.
Unless I am totally missing something.
AW Arcaeca
Deus Vult
I might, um, not have known that that function existed. 
...well, it obsoletes a day of coding, but if it works...
Although, what's the convertUnitOwner function? Is that basically the unit equivalent of what I've so far been doing for cities?
Also: In my mod the UU can be expended to construct a unique improvement. Or, is supposed to be, anyway - the improvement shows up in the unit panel as buildable, but upon pressing the button... the first clue that something is wrong is that neither the unit dies nor does an improvement show up.
If anyone wants to take a look, the mod is here --> https://www.dropbox.com/s/jp23t9yx0itf2vv/AW's Improvement Gone All Screwy Mod (v 1).zip?dl=0
...well, it obsoletes a day of coding, but if it works...
Although, what's the convertUnitOwner function? Is that basically the unit equivalent of what I've so far been doing for cities?
Also: In my mod the UU can be expended to construct a unique improvement. Or, is supposed to be, anyway - the improvement shows up in the unit panel as buildable, but upon pressing the button... the first clue that something is wrong is that neither the unit dies nor does an improvement show up.
If anyone wants to take a look, the mod is here --> https://www.dropbox.com/s/jp23t9yx0itf2vv/AW's Improvement Gone All Screwy Mod (v 1).zip?dl=0
Craig_Sutter
Deity
Yes, was part of my code, but not needed for your purposes... if you want it, I can post it here though.
Craig_Sutter
Deity
For completeness, I'll post this. It would go below the code posted in #315...
I likely pulled the code out from another source... don't ask me where, for I've no idea. Thank-you unknown benefactor
.
Code:
-- Convert Units
function convertUnitOwner(pUnit, pNewOwner)
print(string.format("convertUnit(%s, %s)", pUnit:GetName(), pNewOwner:GetName()))
local pNewUnit = pNewOwner:InitUnit(pUnit:GetUnitType(), pUnit:GetX(), pUnit:GetY())
pNewUnit:SetOriginalOwner(pUnit:GetOwner());
pNewUnit:SetDamage(pUnit:GetDamage())
pNewUnit:SetExperience(pUnit:GetExperience())
pNewUnit:SetLevel(pUnit:GetLevel())
for unitPromotion in GameInfo.UnitPromotions() do
local iPromotionID = unitPromotion.ID;
if (pUnit:IsHasPromotion(iPromotionID)) then
if (pNewUnit:IsPromotionValid(iPromotionID)) then
pNewUnit:SetHasPromotion(iPromotionID, true)
end
end
end
return pNewUnit
endI likely pulled the code out from another source... don't ask me where, for I've no idea. Thank-you unknown benefactor
.
LeeS
Imperator
I might, um, not have known that that function existed.
...well, it obsoletes a day of coding, but if it works...
Although, what's the convertUnitOwner function? Is that basically the unit equivalent of what I've so far been doing for cities?
Also: In my mod the UU can be expended to construct a unique improvement. Or, is supposed to be, anyway - the improvement shows up in the unit panel as buildable, but upon pressing the button... the first clue that something is wrong is that neither the unit dies nor does an improvement show up.
If anyone wants to take a look, the mod is here --> https://www.dropbox.com/s/jp23t9yx0itf2vv/AW's Improvement Gone All Screwy Mod (v 1).zip?dl=0
I don't see a unit 'WorkRate' for the Mozarabs, nor a cusom version of UnitPanel to get around the need for a 'WorkRate'.
AW Arcaeca
Deus Vult
Ayup, I was. Works like a charm now. 
Now... I'm using Player.AcquireCity but it's kind of irritating how I get asked whether or not I want to annex the city. But DonQuiche apparently figure it out:
I guess the other two parameters just need to be nil?
He also apparently figured out the religion problem:
Now, I have absolutely no clue what any of this does.
Now... I'm using Player.AcquireCity but it's kind of irritating how I get asked whether or not I want to annex the city. But DonQuiche apparently figure it out:
Spoiler :
He also apparently figured out the religion problem:
Spoiler :
Similar threads
