custom AMLA and modify recruits

[OmnisScio]

Greetings

Is there a tutorial around anywhere on how to make an AMLA system like the one in [Legend of the Invincibles]?
Also, how does one modify units recruited by the player (Like how all units recruited in LotI chapter 3 are always loyal)?

[Ravana]

I have had loyal recruits code in my addon so i could easily find it. For custom amla why dont you look how it is done in LotI?

Code: Select all

	[event]
		name=recruit
		first_time_only=no
		[object]
			silent=yes
			[effect]
				apply_to=loyal
			[/effect]
		[/object]
	[/event]

[Astoria]

For custom amla why dont you look how it is done in LotI?

I wouldn't recommend that if you're a novice coder. The way amlas are done in LotI is quite complicated. If you want to get started with amlas, I recommend you take a look at the wiki and maybe some other add-ons that use amlas (I believe After the Storm has some simple amlas you could use as a template. Alternatively, UtBS features a pretty large amla system for Kaleh).

EDIT:

I completely forgot about UtBS, thank you Dugi.

[Dugi]

For custom amla why dont you look how it is done in LotI?

Better don't do that. There are some optimalisations that make it look really bizarre, and also some hard-to-find codes to expand its function to support new effects (like changing alignment). Better look at Elynia's AMLA in Invasion from the Unknown or at Kaleh from Under the Burning Suns (if you don't mind deciphering all the macros there).
In older version of LotI, it was written in a clearer way. I have separated it and made an add-on named Dugi's Resource Pack, where you may find it.

Also, how does one modify units recruited by the player (Like how all units recruited in LotI chapter 3 are always loyal)?

They are separate unit types (to have different recruit cost). If they are recruited, a recruit event is fired upon them, using simple an [object] to do the changes.

[vultraz]

Better look at Elynia's AMLA in Invasion from the Unknown

After the Storm is better and more cleanly coded and as a result, easier to understand.

[gfgtdf]

i dont reccomend looking at UtbS amla codes as novice. Form my impression it is not much easier to understand than LotI.

[OmnisScio]

Ok, currently I'm working on the modifying recruited units bit. It works to a degree, but there are some problems.

Spoiler:

#define TEST_RECRUIT
event
name=prerecruit
first_time_only=no
modify_unit
filter
race=elf
/filter
random_traits=no
TRAIT_LOYAL
TRAIT_DEXTROUS
/modify_unit
/event
#enddef

It applies these traits, but they are appended to two that are randomly generated. I know I could probably do this with that object thing, but I want to be able to do other things with this as well, things that it looks like the object thing can't do. I was thinking of adding the AMLA options through this so that I wouldn't have to make new versions of all the units. (note that this is a test and I do not intent to have all elf units loyal and dextrous) (had to take all the brackets out for some reason, seemed to upset the ... forum thing)

[Dugi]

That won't work. Traits are determined on recruiting, and relatively hard to change. In this case, I'd recommend you to make custom units with these two traits with availability=musthave .

[Astoria]

That won't work. Traits are determined on recruiting, and relatively hard to change. In this case, I'd recommend you to make custom units with these two traits with availability=musthave .

It does work for me.

Code: Select all

    [event]
        name=prerecruit
        first_time_only=no
        [filter]
            type=Aragwaith Spearman
        [/filter]

        [modify_unit]
            [filter]
                find_in=unit
            [/filter]
            {IS_LOYAL}

            [modifications]
                {TRAIT_LOYAL}
            [/modifications]
        [/modify_unit]
    [/event]

This made every Aragwaith Spearman recruited loyal.

About the amlas, you can't do that with unit modifications. If you want to give a unit an [advancement], you'll have to make another unit type.

[OmnisScio]

I've seen a few times in events using the dollar sign to get properties of the events target, is there a list/tutorial of all the things one can do with that.

See, what if that prerecruit event, created a new unit (with the [unit] tags) of the type that would have been created, made the modifications in there with the [modifications] tags, and then killed the unit that was orginally going to be made?

[Dugi]

@bumbadadabum
But that won't remove the effect of the first trait you replaced with the loyal trait, until the unit advances. Also, if you add the dextrous trait that way, it won't increase its ranged damage, until it advances (maybe there is a trick to do this too in the simple [modify_unit] way, but still, the former second trait's effects will persist).

About the amlas, you can't do that with unit modifications. If you want to give a unit an [advancement], you'll have to make another unit type.

This is indeed true, but there are workarounds. You can add all possible advancements to the unit, give them all unachievable requirements (let's say, requiring an AMLA named unachievable_1), and add this required dummy AMLA (an AMLA just with id=unachievable_1) whenever you choose (this probably can't be done with [modify_unit], though, but it shouldn't be hard anyway). That way you will make it possible to add AMLA choices to a single unit.

@OmnisScio

I've seen a few times in events using the dollar sign to get properties of the events target, is there a list/tutorial of all the things one can do with that.

Pyrphorus was making something of that kind.

See, what if that prerecruit event, created a new unit (with the [unit] tags) of the type that would have been created, made the modifications in there with the [modifications] tags, and then killed the unit that was orginally going to be made?

You can kill the unit on recruit, and create a unit of the same type with [modifications] of your choice.

[Astoria]

@bumbadadabum
But that won't remove the effect of the first trait you replaced with the loyal trait, until the unit advances. Also, if you add the dextrous trait that way, it won't increase its ranged damage, until it advances (maybe there is a trick to do this too in the simple [modify_unit] way, but still, the former second trait's effects will persist).

Ah I see. That makes matters a little bit more complicated. The former trait's effects even persist when the effect is cleared... I think Ravana's solution for making the units loyal would work, for now.

This is indeed true, but there are workarounds. You can add all possible advancements to the unit, give them all unachievable requirements (let's say, requiring an AMLA named unachievable_1), and add this required dummy AMLA (an AMLA just with id=unachievable_1) whenever you choose (this probably can't be done with [modify_unit], though, but it shouldn't be hard anyway). That way you will make it possible to add AMLA choices to a single unit.

But the amlas still need to be defined in a unit .cfg. How I understood it, he wanted to make an amla system without custom unit .cfgs. This isn't possible.

[OmnisScio]

I havn't tried getting the amlas in yet, but almost everything else works so far.

Spoiler:

#define TEST_RECRUIT_TWO
event
name=prerecruit
first_time_only=no
unit
type=$unit.type
side=1
x=$x1
y=$y1
gender=female
random_traits=no
modifications
TRAIT_LOYAL
/modifications
/unit
kill
id=$unit.id
/kill
##need something here to move unit into correct position
/event
#enddef

This works. the only problem is that the unit is created while the original is still there, and is placed to the side. I do not know how to get the new unit positioned correctly after the original is killed, I have no way to refer to it.
About the amla, I've seen in the LotI code, [advancement] tags in [modifications] tags outside of a unit declaration cfg file. The impression I have at the moment is that [modifications] tags are more powerful than [modify_unit] tags in that [modifications] tags is like its directly affecting the constructor of the unit, while [modify_unit] tags can only use its mutators.

[Dugi]

This works. the only problem is that the unit is created while the original is still there, and is placed to the side. I do not know how to get the new unit positioned correctly after the original is killed, I have no way to refer to it.

Just kill it before creating the new one. Its properties in $unit will remain until the event ends.

About the amla, I've seen in the LotI code, [advancement] tags in [modifications] tags outside of a unit declaration cfg file. The impression I have at the moment is that [modifications] tags are more powerful than [modify_unit] tags in that [modifications] tags is like its directly affecting the constructor of the unit, while [modify_unit] tags can only use its mutators.

You must be mistaken. [advancement] tags have no effect inside [modifications]. Maybe you meant [advance] tags, I used these to alter the AMLA or change the unit somehow (this could be done also by [object], but I chose [advance] to make things slightly quicker).

[OmnisScio]

can [advance] tags be used to allow non-custom units to have custom amla systems? can the default amla be removed from a unit?

If not, I'm all out of ideas. I like the idea of adding an additional promotion to all the units as a way of getting the amla system in without having to make copies of all the ubits, might have to do that myself. I wonder, were the additional promotion levels desired to begin with (with the added bonus of being able to easily implement the amla system) or were they the solution to that problem?