Mountain Climbing Mod, Failure to Climb & LUA Code - Need Ideas & Help

[Gleb Bazov]

So, I've recently posted a small mod that creates a way to exploit and move over mountains in game in a regulated manner. No free-for-all, but only certain unit types can traverse the peaks.

Here it is: Mountain Movement & Exploitation Mod.

But I need suggestions and new ideas about some future steps I'd like to take. I would very much appreciate your thoughts.

I have since compiled a LUA script that achieves the following:

1. Index and track through a table a roster of each player's mountaineer (unit capable of traversing mountains) units;
2. Index and track each mountaineer unit's location throughout the game;
3. Listen for and identify any instance when a mountaineer unit moves onto a mountain;
4. By random chance either:
   1. allow the mountaineer unit to remain on the mountain, or
   2. damage the unit and push it back to the location where it started, before it tried moving up the mountain, and
   3. destroy the unit if it is damaged beyond 100 points;
   4. all the while maintaining the unit's promotions and damage points, if any.

Here comes the catch, however. Because I've found no function in CIV 6's LUA that allows me to actually force a unit back from the mountain to the plot from which it moved, I've been forced to improvise and destroy the old unit while creating a new one simultaneously to simulate the failed attempt to traverse a mountain. The promotions and damage can persist no problem, so that's less of an issue. I still can't find a way to persist the unit's veteran name, but I might be able to fix it with time. There is a greater problem, however.

With civilian units, like settlers, GPs, etc., there is no issue - because they can't earn experience or promotions. However, with any military unit (like scouts or rangers) that this mod allows to climb the mountain, I face a dilemma. I can persist their promotions and damage points in the new unit without a problem, but the way the game's experience/promotions system is coded, it produces an unfortunate hiccup.

Despite getting x number of promotions up front, the new units are still treated by the game as brand-new units that had received no promotions. That is, the promotion are active, but, instead of having to earn x++ number of experience points for the next x+1 promotion, only 6 points are required. This wouldn't be a game-ending problem in and of itself (although it is quite ugly, there are ways to circumvent the problem by delaying the unit's experience progress using LUA), but a strange bug crops up in the game, where a unit that's given too many promotions off the bat has its promotion mechanic lock up. It stops being able to apply any new promotions and experience points it earns after re-creation, but still continues to earn them. This also might be a product of conflicting LUA codes that I am running in several of my active mods, but I doubt it.

So, here is my dilemma. I'd love to be able to code a way to prevent a unit from climbing the mountain, but I see no way of doing it using in-game scripts (there are ways, it seems, of doing it in the UI context) without the create/destroy process. And the process only works in an elegant way for non-promotion-capable units.

Thus, I have a choice: (1) implement the process as I have done, and keep trying to find a solution, (2) instead of pushing the unit back, only damage it if it climbs the mountain, or destroy it (and perhaps keep the original mechanic for the civilian units); or (3) keep the original mechanic and just live with the fact that the unit will lose all of its promotions (well, I can say that... heh... the unit was so damaged, that it forgot how to be a zweihander sword-wielder and everything else it learned )).

OR, and I just came up with this: on the first go round, the first time a unit is damaged on the mountain, give it a chance of getting a "mountainclimber" free promotion that will keep it safe from any future mountain failure (so I won't have to ever re-create it again), and make that chance a 100% if a unit has at least one promotion (and keep it on the mountain instead of re-creating it).

Actually, I might just go with this . BUT, please let me know if anyone has any other suggestions, I'd love to hear them!

Thanks for your attention!

 

[Infixo]

Did you try UnitManager.RequestCommand()? There's also UnitManager.ChangeMovesRemaining(). I have not used them, but maybe you can give the unit back some move points and then command it to move to the starting location. Just an idea.

 

[Gleb Bazov]

Thanks for the ideas! I have not tried UnitManager.RequestCommand() because in Gedemon's very useful collection of LUA Objects, that specific function is listed as existing only in the UI context, not in the In Script context, and I did not want to bother yet with passing information from one to the other. But maybe I should have. It could be that a corresponding function exists in the In Script context. I'll certainly give it a go.

As for UnitManager.ChangeMovesRemaining() - that is very helpful! This function is not listed anywhere, and I did not know it existed, so this is great! It is necessary for another element of my code.

Much appreciated!

 

[Infixo]

Even more good news. I've just checked and they've added new functions to UnitManager available in gameplay context. MoveUnit and PlaceUnit are there, so your problem might have an easy solution after all.

 

[Infixo]

For objects like UnitManager you can use TableBrowser in FireTuner to easily check which functions are available in which context.

 

[Gleb Bazov]

Thank you very much for the tip! Cheers!

 

[Gleb Bazov]

This is terrific! You are a rockstar . Now, all I need to do is finally get off my bum and port all my codes and mods over to the new Spring patch (I am running both simultaneously , because I just haven't had time to deal with everything yet), and I am golden. Thank you!

 

[Gleb Bazov]

Infixo, your tip was invaluable. I now have the full and exact functionality I wanted. Thank you very much!

(AND, as a P.S., it turns out that the UnitManager.MoveUnit and PlaceUnit were in the game all along -- my pre-SpringPatch version of the game works just as well with them as the post-SpringPatch).

 

[Infixo]

They were probably added in Winter patch. Lua objects excel didn't have them and it was created before winter patch.I did some updates in March and found several new functions, but haven't checked UnitManager until yesterday.

Can you post here the lines of code which use those new functions? So we'll know what parameters to use. Finding the parameters can be a real pain in ... sometimes.

 

[Gleb Bazov]

I definitely will post the parameters later on today. Cheers.

 

[Gleb Bazov]

I will post this separately in the LUA Objects thread, but here are the arguments I used for the following functions:

UnitManager.RestoreMovement(pUnit)

UnitManager.MoveUnit( pUnit, iPlotX, iPlotY )

UnitManager.PlaceUnit( pUnit, iPlotX, iPlotY )

NOTE: In order to move or place a unit after a move that exhausts its movement points. the unit's movement points must first be restored. If this is not done, and PlaceUnit is used, error artifacts appear on the game screen, where the game treats the unit as being at the new location, but the graphics do not update. I.e. visually it remains at the old location, but, in actuality, it is at the new location.

If MoveUnit is used to move a unit that has exhausted its movement points, no move takes place. The function fires successfully, but has no effect.

-- where:

local pPlayer = Players[ iPlayerID ]

local pUnit = pPlayer:GetUnits():FindID( iUnitID )

On a separate note, I have determined the following parameters for the following event:

function OnUnitGreatPersonCreated( iPlayerID, iUnitID, igpType, igpID )
-- main chunk --
end
Events.UnitGreatPersonCreated.Add(OnUnitGreatPersonCreated);

-- where:

igpType is an integer, from 0 to 8, corresponding to index of the GreatPersonClasses table

-- and:

igpID is an integer, corresponding to the index of the GreatPersonIndividuals table