Possible to create a unit or corpse without firing "Unit enters <entire map>" or unit indexer ?

[Ricola3D]

Hello,

For a system I'd like to create a corpse or a unit of the same type as a variable unit (this allows me to get the unit armor without buffs).
But I'd like to avoid side effects/poluting maps with "Unit enters <entire map>" or indexing events.

Is it possible ?

For example creating the unit outside world bounds ?
Or create it hidden ?
Replace <unit> by <unit> with some settings ?
Have a dummy caster morph an existing dummy to <unit> with some settings ?
Have a dummy caster create an illusion with some settings ?
Have a dummy caster create it with an ability like Rain of Chaos ? -> tested KO
Morphing with Berserker Upgrade, Corporeal Form, ... -> tested KO, deosn't fire event, but can't set New Unit Type with Blz native.

Sincerely,

Ricola3D

 

[Uncle]

Can't you just cache the Armor upon the creation of the initial unit?

• Unit - Create 1 Paladin...
• Set Variable Base_Armor[(Custom value of (Last created unit))] = ...

Each unit can then have a reference to it's base armor at all times.

Otherwise, a Unit Indexer can be given a Condition to exclude a specific unit-type. How to do it depends on the system but I'm pretty sure all of them rely on "A unit enters map" for the initial indexing.

Alternatively, have a Hashtable/some kind of table full of data for all of your different Unit-Types. You can use the Unit-Type Id as the Key in the table so as long as you have a Unit (and it's id) you will also have access to all of the preset data related to it.

 

[Ricola3D]

Can't you just cache the Armor upon the creation of the initial unit?

• Unit - Create 1 Paladin...
• Set Variable Base_Armor[(Custom value of (Last created unit))] = ...

Each unit can then have a reference to it's base armor at all times.

Otherwise, a Unit Indexer can be given a Condition to exclude a specific unit-type. How to do it depends on the system but I'm pretty sure all of them rely on "A unit enters map" for the initial indexing.

Alternatively, have a Hashtable/some kind of table full of data for all of your different Unit-Types. You can use the Unit-Type Id as the Key in the table so as long as you have a Unit (and it's id) you will also have access to all of the preset data related to it.

I thought about saving in a hasthable by unit type it. It can increases the performances/reduces the pollution.
However, the base+upgrade defense (as its name states) changes when a defense upgrade is learnt.

So in the below cases, I should remove the saved value and be able of recomputing it:

• Manually call "Set the current research level of <name> to <level> for player <player>"/SetPlayerTechResearched.
• Event "Unit finishes an upgrade" is fired.

And since during those events, the unit may have buffs/items, I need to either remove the buffs/items, or create a corpse.



Well, it'd still be better (only 1 corpse created on first unit-type allocation & 1 corpse created on each upgrade change).
I keep the idea in stock !


Edit: I just realized the all unit indexers use struct initialization to call TriggerRegisterEnterRegion. So if I create a trigger with TriggerRegisterEnterRegion within a module initializer, it can execute before the indexers' & GUI events. Maybe it can help doing something on the unit ?

 

[Ricola3D]

@Uncle:
After some thinking I could try:
- Saving the base armor (shouldn't change all along the game)
- Saving the base+upgrade armor, and cleaning/recomputing it when event "unit - finishes research" and hook "SetPlayerTechResearched". First recompute would require creating a copy, but next ones could just add the research level diff x defense upgrade bonus.

However I don't think it's possible to skip the creation of a copy at first time. Because if I use a unit "on indexed" event, the unit may already have items (so I must find a way to disable/reenable its inventory without the items dropping on the floor) :S

 

[Uncle]

So this is taken straight from Bribe's Unit Indexer:

• If (All Conditions are True) then do (Then Actions) else do (Else Actions)
  • If - Conditions
    • UnitIndexerEnabled Equal to True
    • (Custom value of (Matching unit)) Equal to 0

You can disable the Unit Indexer and add your own Conditions. This is what runs when a unit enters the map or gets indexed during setup.

Perhaps I'm misunderstanding but it should be fairly easy to manage what does and doesn't get indexed.

 

[Ricola3D]

So this is taken straight from Bribe's Unit Indexer:

• If (All Conditions are True) then do (Then Actions) else do (Else Actions)
  • If - Conditions
    • UnitIndexerEnabled Equal to True
    • (Custom value of (Matching unit)) Equal to 0

You can disable the Unit Indexer and add your own Conditions. This is what runs when a unit enters the map or gets indexed during setup.

Perhaps I'm misunderstanding but it should be fairly easy to manage what does and doesn't get indexed.

It's an idea. But if I want to minimize the risk of an intermediate event creating units missed by the indexer, I should disable/re-enable it as soon as possible ^^

Indeed, it's funny, when you call "CreateUnit(player, type, x, y, facing)", if you track various events you will see in order:

call CreateUnit(player, type, x, y, facing)
Trigger for "unit enters <entire map>" created within a scope initializer is executed.
Trigger for "unit enters <entire map>" created within a library initializer is executed.
Trigger for "unit enters <entire map>" created within a struct initializer is executed.
Trigger for "unit enters <entire map>" created within a module initializer is executed.
"Food Used" property of the player is changed (if the unit costs food). GUI Triggers with this event are executed.
end of the call
...Next lines of code of the trigger/function...
Trigger for "unit enters <entire map>" created within GUI is executed.

So I can use a enter-region trigger created by a scope initializer to re-enable the indexer for ex. Otherwise for now a code that works for most indexers:

 

[Uncle]

It's an idea. But if I want to minimize the risk of an intermediate event creating units missed by the indexer, I should disable/re-enable it as soon as possible ^^

Indeed, it's funny, when you call "CreateUnit(player, type, x, y, facing)", if you track various events you will see in order:

call CreateUnit(player, type, x, y, facing)
Trigger for "unit enters <entire map>" created within a scope initializer is executed.
Trigger for "unit enters <entire map>" created within a library initializer is executed.
Trigger for "unit enters <entire map>" created within a struct initializer is executed.
Trigger for "unit enters <entire map>" created within a module initializer is executed.
"Food Used" property of the player is changed (if the unit costs food). GUI Triggers with this event are executed.
end of the call
...Next lines of code of the trigger/function...
Trigger for "unit enters <entire map>" created within GUI is executed.

So I can use a enter-region trigger created by a scope initializer to re-enable the indexer for ex. Otherwise for now a code that works for most indexers:

I don't quite follow what you're worried about. Can you not just exclude "corpses" from the Conditions and it'll NEVER get indexed. You wouldn't need to toggle the Indexer off or on. There's also an Index event which gets fired when a unit becomes indexed/de-indexed.

 

[Ricola3D]

Actually I cant create corpses (it's impossible for units with death type = can't raise, doesn't decay").
So I create units of same type ^^