OK, this helped me figure it out! The rules.txt loads and plays fine without the Lua Template, but the Lua Template wanted the # of units in UNITS and the # of units in UNITS_ADVANCED to match! I made sure that was the case, and now the template loads fine. Now to editing stuff! Hopefully. Thanks Prof.
Small Questions Thread
- Thread starter Prof. Garfield
- Start date
CurtSibling
ENEMY ACE™
Is there a Lua function to force the AI to use missile flagged units are normal?
I am wondering if there is something from the "Over the Reich" development that may be a factor?
I am wondering if there is something from the "Over the Reich" development that may be a factor?
You could not give it the missile flag, and just kill it with a unit killed event. Or, maybe use Lua to remove the flag on unit activation, and restore it as part of onInitiateCombat.
CurtSibling
ENEMY ACE™
In my scenario I had previously had some "onunitkilled" triggers, which I removed by copying over the edited file with the vanilla file.
Now when I go to found a new city, but cancel, I get this message:
Is there something in the triggers file I am missing?
Now when I go to found a new city, but cancel, I get this message:
Is there something in the triggers file I am missing?
In your triggerEvents.lua file, under triggerEvents.onCityFounded (probably the last event), add a return line
Code:
return function() endIn a version of your scenario that I have, the modified code looks like this:
Code:
function triggerEvents.onCityFounded(city)
context[getContext()]["onCityFounded"](city)
universal["onCityFounded"](city)
return function() end
endIn version 18 of the TOTPP, the onCityFounded event was given the ability to return a function to be performed when the city was cancelled:
If, for example, your code changed the city centre tile, the returned function could undo that. This is supposed to be optional, but apparently it is not. I presume this means that some older Lua scenarios (at least ones where you can build cities) can cause errors on TOTPP v0.18.
CurtSibling
ENEMY ACE™
Works a treat - Thanks, good sir!
CurtSibling
ENEMY ACE™
Another pops up!
I have a little error that seems to be tied to the "onturn" events and perhaps joined with the legacy events...
I suspect a problem with the units spawned each turn in the Soviet cities, as this one pops up during the open of the Russian turn:
I am wondering if a conflict can happen if the civ is spawning units, but the city ownership is not clearly defined?
Here is a typical Soviet unit event here:
In Macro the enemy owning a spawn city will simply null the event, but I realise it might not be so simple with Lua?
Just wondering if anyone can spot something I am missing here?
(I can post files if needed)
Everything else has been running nicely, this is an immensely fun experiment with Lua so far.
(now if I can only get the missile units to balance!)
I have a little error that seems to be tied to the "onturn" events and perhaps joined with the legacy events...
I suspect a problem with the units spawned each turn in the Soviet cities, as this one pops up during the open of the Russian turn:
I am wondering if a conflict can happen if the civ is spawning units, but the city ownership is not clearly defined?
Here is a typical Soviet unit event here:
Code:
--If the Soviet civ has the "Patriotic War" tech, the event will spawn Red Army forces forces in major cities...
if civ.hasTech(object.tRussians, object.aRusPatrioticWar) and object.tRussians.isHuman == false then
--Red Army reinforcements from Moscow
civlua.createUnit(object.uRedArmy, object.tRussians, {{30,30,0}}, {count=9, randomize=false, veteran=false})
--Red Army reinforcements from Leningrad
civlua.createUnit(object.uRedArmy, object.tRussians, {{25,21,0}}, {count=9, randomize=false, veteran=false})
--Red Army reinforcements from Stalingrad
civlua.createUnit(object.uRedArmy, object.tRussians, {{34,42,0}}, {count=9, randomize=false, veteran=true})
endJust wondering if anyone can spot something I am missing here?
(I can post files if needed)
Everything else has been running nicely, this is an immensely fun experiment with Lua so far.
(now if I can only get the missile units to balance!)
Having looked at and around line 627 in legacyEventEngine.lua, I recommend looking for a legacy event which doesn't have a "@THEN" section. I think I'm going to need to write code to validate legacy events. Fortunately, I think I've written most of the tools necessary for this already.
CurtSibling
ENEMY ACE™
My bug-hunt detective hat is now on.
Hold on. Send me your file, since I can add a couple lines of code to do the check, rather than have you manually look for something. Just in case the error is caused by something different.My bug-hunt detective hat is now on.
CurtSibling
ENEMY ACE™
Thanks, dude! Here ya go!
Very last event. There should be an "@THEN" around line 6829.
CurtSibling
ENEMY ACE™
Wow - I had looked through of these, and there we go, the last line!
My sincere thanks, Prof!
BTW - The 1st event is of interest too!
My sincere thanks, Prof!
BTW - The 1st event is of interest too!
Code:
TEXT
^
^^ With thanks to Fairline, Prof. Garfield, JPetroski, civ2units and TNO.
^
ENDTEXTHello! My thanks, Prof., for all your help thus far. I'm back at it as of today. I have two questions regarding the mod I'm working on, and then I am in need of some advice for a fix for another piece of code that isn't behaving correctly (probably because of that X,Y issue).
1. Below is code that registers where a goodie hut was, changes that terrain upon the goodie hut disappearing, and then also gradually alters the terrain adjacent to that goodie hut tile. I'd like to form some stipulations, though:
- I want the system to "log" what terrain existed before it changed to "TribeTerrain" -- and then for there to be a chance that it can revert back to that original terrain during the game.
- I'd also like these transformations on either end, both adjacent terrain turning into "TribeTerrain" and the chance of reverting back to the original terrain, to only happen once when a certain tech (say, "XYZ") has been researched -- effectively meaning that if that tech exists anywhere in the game at any point, the "TribeTerrain" will stop generating, and will begin to permanently revert back to its original terrain.
Would these be possible?
Here is the current code:
2. Since this is a mod, and not a scenario, how can I register city lists in the middle of the game?
For example, say I want a list of player cities to come up in a menu, and the player selects a city, and then a unit or something appears in that city.
3. Here is some code for generating food/production onEnterTile. It keeps going to the capital city... or at least, not the "nearest city." (Ignore the TitheTable part, that is functioning as intended as it does not require nearest city.)
1. Below is code that registers where a goodie hut was, changes that terrain upon the goodie hut disappearing, and then also gradually alters the terrain adjacent to that goodie hut tile. I'd like to form some stipulations, though:
- I want the system to "log" what terrain existed before it changed to "TribeTerrain" -- and then for there to be a chance that it can revert back to that original terrain during the game.
- I'd also like these transformations on either end, both adjacent terrain turning into "TribeTerrain" and the chance of reverting back to the original terrain, to only happen once when a certain tech (say, "XYZ") has been researched -- effectively meaning that if that tech exists anywhere in the game at any point, the "TribeTerrain" will stop generating, and will begin to permanently revert back to its original terrain.
Would these be possible?
Here is the current code:
Spoiler :
2. Since this is a mod, and not a scenario, how can I register city lists in the middle of the game?
For example, say I want a list of player cities to come up in a menu, and the player selects a city, and then a unit or something appears in that city.
3. Here is some code for generating food/production onEnterTile. It keeps going to the capital city... or at least, not the "nearest city." (Ignore the TitheTable part, that is functioning as intended as it does not require nearest city.)
Spoiler :
This has a quick answer.
This function calculates the distance from the (0,0) tile to tileA, not the distance between tiles A and B.
Code:
local function distance(tileA,tileB)
local xDist = tileA.x
local yDist = tileA.y
return math.sqrt(xDist^2+yDist^2)
endThe general library provides distance functions gen.distance, gen.tileDist, gen.gameMechanicDistance.
You will have to generate the option list programmatically. Here's an example using text.menu
Code:
local menuTable = {}
local offset = 3
for city in civ.iterateCities() do
if city.owner == civ.getCurrentTribe() then
menuTable[offset+city.id] = city.name
end
end
local choice = text.menu(menuTable,"Choose a City.","Menut Title")
local chosenCity = nil
if choice >= offset then
chosenCity = civ.getCity(choice-offset)
endtext.menu requires the menuTable to have all indices at least 1 (but you can have gaps in the array). However, city ID numbers start at 0, so the trick is to add and subtract an "offset" so that all menu options are at least 1. By choosing an offset that is more than 1, you can also have places for other options. Note that text.menu automatically splits the menu into multiple "pages" if there are a lot of options.
Based on that error, unit.location is nil, which means that you're not providing the function with a unitObject when you call it.
In the code, you've also defined nearestFriendlyCity twice, except that one is 'nearestFriendyCity'. So, you're probably calling nearestFriendlyCity with a tile object instead of a unit object. In any case, in Lua you can't "overload" function names by defining them with different arguments. Rather, the last one defined is the one that will be used.
In the code, you've also defined nearestFriendlyCity twice, except that one is 'nearestFriendyCity'. So, you're probably calling nearestFriendlyCity with a tile object instead of a unit object. In any case, in Lua you can't "overload" function names by defining them with different arguments. Rather, the last one defined is the one that will be used.
Such a silly mistake. I edited that one, and removed the first, and it seems to be working great since then. Thank you for spotting that!
I think you want something like this:
Spoiler :
This may not be exactly right (partly 'cause I'm not completely sure of the exact functionality you want), but the key idea is to store the base terrain 'type' (similar to id for most objects, except 'type' is recycled for each map) in a part of the state table.
Make sure the table has been initialized:
Code:
state.originalTerrainType = state.originalTerrainType or {}Add the tile's base terrain type to the storage table before changing the terrain.
Code:
state.originalTerrainType[gen.getTileID(adjacentTile)] = adjacentTile.baseTerrain.type
adjacentTile.baseTerrain = postTribeTerrain
Code:
local origType = state.originalTerrainType[tileID]
adjacentTile.baseTerrain = civ.getBaseTerrain(0,origType)
state.originalTerrainType[tileID] = nilNote: instead of maintaining section of the state table yourself for this feature, you could use a tileData counter (you'd probably want a -1 default value). The reason to maintain a separate table is if you want to loop over all the converted tiles, since iterating over every tile in the map can cause a bit of lag, at least for large maps. This was why I created a hutTable instead of making a flag, and looping over all tiles and checking if the flag was true.
