Tower field persistence and :destroyed? (Unresolved)

[GoodMorning]

Hello again:

I have a CRPL script which involves a creeper spreading field around the tower.
However, the field persists after the destruction of the Core.
Any thoughts?

(The rest of the map is a test, designed to make a powerful unit, which is invulnerable to normal destruction. It is to be broken by overloading it. The notion is that it will burn power faster, the more power it contains. It will also make more Creeper as the power level goes up. It is charged from the group of five towers on the left. Put a CN on the PZ and wait to see the behavior. Suggestions welcome. There's a trace block in the code.)

Any idea why the field persists after the destruction of the core?

[Builder17]

Field isn't part of core , you should make core remove field in :Destroyed build-in function.

[GoodMorning]

The :Destroyed function currently reads:

:destroyed
  DisableTowerField

This, I thought, would remove the field I create earlier, with EnableTowerField.

What is actually required, as this is not working?

[Builder17]

I am not sure , did you recompiled after changing script?

[Nicant]

Try this, delete your current core and make a new core with the script! Doing that helped me make the (or making) Creep Forge!

[J]

In case you didn't reload the map after every test run, there may still be a field left over from a core destroyed in an earlier test run. I have no idea how to get rid of that other than rebuilding the map from scratch.

[GoodMorning]

In this map, because there are units that refer to the main one, I have set it up by building the cores, attaching scripts, saving, then unpausing and testing. Then, if (when) I find a bug, I alt-tab out, edit the CRPL file, save it, then hit load in the map editor. This causes the script to recompile, and allows me to skip some initialisation issues with the auxiliary cores. So, a version with no fields, or even initialised scripts, should be what loads. The net effect is to effectively run the script in the same circumstances, on a new core each time. Or so I thought.

[GoodMorning]

Does anyone have any more help to offer? If not, I shall have to rebuild from scratch.

[knucracker]

If you think there is some latent field in the map left over from something earlier (and you naturally want to get rid of that and continue editing your map), you could write a script that sets all field cells to 0 and just run that once.

But I'm not sure that is what is going on in your case.  Tower fields shouldn't leave a ghost behind across a save.

[GoodMorning]

I really don't know what might be happening.

My best guess, in that case, is that the script I am running has failed to remove a field that I placed in an earlier frame. But this seems unlikely, as there should be a DisableTowerField call in every frame.

I'll try building a mew map, and edit this if it turns up again. Otherwise, you know as much as me. Probably more.

[GoodMorning]

I built a new world, by the method of:

<new>
<copy/paste scripts>
<compile>
Build the equivalent cores. (1 main, 5 aux)
Attach scripts.
Save. Load. Exit. Look at the values used in the other world.
Reload new world. Change values.
Add such things as CN, energy pack, lots of shields, relays connecting all units on map...
Adjust energy pack to hold ~250000-2500000 energy.
Save. Load.
Run.

End result: Huge field (about 1/4 map) persisting, and enough Creeper to make it visible.

Scripts attached, and the original map is attached to a previous post. Note that these cores were created in the same frame, and the main core was created first.

[Builder17]

Does Trace log says anything?

[GoodMorning]

It's difficult to get anything sensible out of a trace log, when the only time anything seems wrong is after the destruction of the core.

I suppose that it could be done, with a dedicated tracer core, that exists solely to, say run this:

Code Select Expand


once
  CONST_NULLIFIERDAMAGES false SetUnitAttribute
  CONST_COUNTSFORVICTORY false SetUnitAttribute
  CONST_SUPPORTSDIGITALIS false SetUnitAttribute
  "MapLog" ->UnitIdentifier #Used to assist GetCoresWithVar
  ""->TraceString
endonce

ShowTraceLog
ClearTraceLog
<-TraceString Trace


Combined with an appropriate function to write to this core, it might work for tracing stuff from dead cores.

But the script should be DisableTowerField -ing each time it runs the main block (in order to avoid issues when changing field size/strength), as well as when it takes the fatal damage, and when it is :destroyed. The trace log can only tell us if a block runs, and whatever variables we ask for. There seems little use for it here.

Feel free to take a look. But I can't tell what's wrong, unless DisableTowerField can't work until the next frame from when EnableTowerField was called. That would explain it, but there seems to be no reason that it would be so. (Unless there is an optimisation that is usually safe breaking it? Changing fields in bulk at frame-end would seem sensible... But the tower should have withdrawn any request for the field by that stage. Oh well, not knowing the structure of the internal code, I can only speculate.)