Problem with a script: Finalising map breaks it? (Works now.)

[GoodMorning]

Strange issue:

These scripts are designed to cooperate to cause damage (but not destruction) of one unit to be evenly spread over the units in the distribution set.

The problem comes when I attempt to play on a finalised map.

Specifically:
Map contains six cores. Scripts and non-default values on each:

Spoiler

1. The distribution script carrier.
Distributor:
DistID 2
Debug 0

Vulnerability (Vuln):
NullifierVuln 0

2. The regenerator.

Vuln:
NullifierVuln 0
Regen 0.05
Health 1
DistID 2

3 and 6. Weaklings.
Vuln:
Regen 0
MaxHealth 2
Health 2
DistID 2


4 and 5. Tougher.
Vuln:
Regen 0
MaxHealth 3
Health 3
DistID 2

[close]

In theory, there are two (otherwise) invincible cores: one to regenerate, and one to carry the distribution script.
The others are vulnerable, and, when hit, will cause the regenerator to take damage.
By properly distributing the damage, the regenerator will be destroyed.
When the other cores are destroyed, the carrier will self-destruct.

In practice, the supposedly vulnerable cores have their health reset to maximum on every frame (I think).
This prevents the health meters from even registering damage.
They must take the damage, as they can be destroyed by multiple Nullifiers.

The map works properly in the editor, but breaks once finalised.

It is a test, the real use of this concept is as a way to have a "train" or "complex" which has interlinked parts.
Additionally, this version was to go up as a puzzle map.

Thoughts/help?

[GameGibu]

Remember that UID's change from play to play... if you're using static UID's then that could be your issue.

-GameGibu

[GoodMorning]

I don't know about the save/load differences... Perhaps the Core should be added and the export done pre-initialisation? Or an activator script included?

These seem like unpleasantly complex solutions...

Maybe I will just have to work with a factory.

[GoodMorning]

I have found an issue in the vulnerability code, which is now fixed, and stopped that bug.

Went swimmingly for an entire ten seconds!

Then, having no issues left, turned off the debugging parts of the script, which were tracing behavior.

After various shenanigans, it works now.

Custom 3180 has the idea on show.

[GoodMorning]

As a final question: If the UID is mutable between saves, is there an ID that is not?

Or must I define one myself?

I imagine having to add a 'CustomProperties.crpl'
That would have internal variables like: HasCustomPropsScript (1, always), ImmutableID (incremented, possibly have a manager core with ImmutableID 0), UnitType (string).

Is that the proper way?

[GameGibu]

One idea I've toyed around with in my thinking bag is making one script that does multiple things based on one of the initial input variables. In effect every core would rin the same script but different parts. This could make inter-core intwraction one or two steps faster, but also runs the risk of becoming extremely obfuscated in the code.

-GameGibu

[GoodMorning]

The multi-file flexibility for reuse makes it a better choice.

Having a personal IDing variable (e.g. "PUSIL_UNIT_ID" for me) along with a type indicator (PUSIL_TYPE) is useful if multiple scripts need running.

Having a single master (mainframe) script and fairly dumb (terminal) scripts seems like a good way.

If the mainframe can get UIDs for all the stuff it must manage, it can do the disparate parts in a single script.

Using the one large script, I would argue, is either over-complicating or dangerous in terms of potential variable reuse.

I.e. By the time the script gets big enough to warrant it, it is easier to split it.