Danmacsch's Lua (and general modding) inquiries

If it doesn't. I'll have to wait till I get home later in the day to actually be able to test it (instead of just rearranging the code on my screen).

Disable the event and verify that the units can be trained at all based on the way they are inserted into the game's database. If they do not show as ever being trainable without the event handler running, then the event handler will have no effect whatever on these units. By this I mean do they ever show as valid production or purchase items within the city view when the event handler is turned off -- if not, then the problem is not in the lua code.

PlayerCanTrain, CityCanTrain, PlayerCanConstruct, CityCanConstruct, etc., only fire when the unit, building, etc., is otherwise trainable or constructable based on data within the game's database. If your unitTaratineCavalryCheaper1ID, unitTaratineCavalryCheaper2ID uniques are not trainable by whomever civilisationID is without the event handler running, they will not be made trainable with the event handler running. In essence all you can do with these CanX events is disable what is otherwise allowed from the information within the database.

Thanks for pointing this out LeeS - I do know how the CanX events function and what they cannot do, but I didn't even consider to check if the cheaper copies of the units were trainable without the handler.
And it seems they are not. They do appear in the database however and as far as I can tell, they are identical to the units which they are copies of. What can be the cause of this ?

Danmacsch said:

What can be the cause of this ?

Click to expand...

Without the actual mod, it's just a guessing game

It is I guess. I just thought that maybe it was something obvious I just wasn't aware of. I'll upload it in a second.

Here you go.
Thank you all for taking your time to help me out.

They indeed are identical to the units they're copies of - right down to sharing a UnitClass, so they're only buildable by a civ that has the cheaper unit as its Civilization_UnitClassOverride for that class.

Klisz said:

They indeed are identical to the units they're copies of - right down to sharing a UnitClass, so they're only buildable by a civ that has the cheaper unit as its Civilization_UnitClassOverride for that class.

Click to expand...

Okay, wasn't aware it worked like that. So by setting up a separate unit class for unit copy and then using PlayerCanTrain as described above, it should work? I'll try it - thanks Klisz!

It is because all the units are falling within existing Unit-Classes, and a single Civilization can only ever train or purchase one unit from within any one Unit-Class. It can never train or purchase any other unit from within the class except for the Default Unit or the Unique One it has been overridden within the Unit-Class to use via table Civilization_UnitClassOverrides. So your handler is never firing for these extra units within the 'Horseman' class of units, for example, it is only ever firing for the unit specified as correct for the civ within the 'Horseman' class of units, (for example).

You would need to make all these 'extra' and cheaper versions of these units their own unit-classes which mirror the 'Horseman' Unit-Class, (for example). And then you need your handler to not only enable these surrogate units when correct, but you need the handler to also disable the units from within the 'regular' unit-class (such as the 'Horseman-Class') when the 'Cheaper-Horseman-Class-Level-A' is the correct class of unit to have enabled. You also will have to deal with issues of the game *poof* deleting the unit from a city-qeue if the conditions change mid-stream of producing the unit and the city can no longer produce Unit-X.

edit -- mostly ninja'd by Klisz

Fantastic - it works! I didn't consider that you couldn't have more than one unit from the same unit class trainable at the same time, but of course that makes sense. Thank you all of you for your help.

There is one more thing though, now all the copies with a different cost is appearing in the tech tree. Iirc PlayerCanTrain (and it's equivalents) can't do anything about that, but is there another way to make a unit with a cost invisible in the tech tree?

You could try setting the PrereqTech to NULL, then make the tech still required by inserting the units into the unused (but apparently still functional? I haven't tested this, though) Unit_TechTypes.

Will try - thanks Klisz