Can't remove gravity from Mistet code

[Clean0nion]

I copied over the Mistet magnetar code to use in my map, removed the gravity effect and added a few radians. Everything was working fine until I added some creeper into the map and saw that the gravity effect, despite my removal of it, still remained.

I've pasted here the code from the magnetar, and also attached my map. If you download the map to have a look, most of the code is in fullercraft.crpl.

Code Select Expand

# thullercraft.crpl
# Created on: 7/19/2013 6:59:44 PM
# ------------------------------------------

79 ->orbitDistance
0.0016 ->orbitSpeed

once
0 ->mag_angle
<-orbitDistance mul(8) ->mag_distance
#Converts 270 degrees to radians
#This bit isn't even needed but it's a good memory for me
Self "main" 270 PI mul 1 180 div mul sub 90 PI mul 1 180 div mul sub SetImageRotation
@PositionMagnetar
GetCreeperColors ->acB ->acG ->acR ->creeperB ->creeperG ->creeperR
<-acB 255 mul 0 Round ->acBn
<-acG 255 mul 0 Round ->acGn
<-acR 255 mul 0 Round ->acRn
#11 97 11 <-acRn <-acGn <-acBn SetCreeperColors
0 0 0 <-acRn <-acGn <-acBn SetCreeperColors
endonce

@PositionMagnetar

<-mag_angle add(<-orbitSpeed) ->mag_angle


:PositionMagnetar
#Rotates the image
Self "main" GetImageRotation ->currentRotation
<-currentRotation <-mag_angle 270 PI mul 1 180 div mul sub 90 PI mul 1 180 div mul sub ->currentRotation
Self "main" <-currentRotation SetImageRotation

cos(<-mag_angle) mul(<-mag_distance) ->mag_x
sin(<-mag_angle) mul(<-mag_distance) ->mag_y

<-mag_x add(644) ->mag_x #The center of the map is at 80 (80.5)(times 8 for pixels)
<-mag_y add(644) ->mag_y

SetUnitAttribute(Self CONST_PIXELCOORDX <-mag_x)
SetUnitAttribute(Self CONST_PIXELCOORDY <-mag_y)

[J]

Are you sure you saved the script before recompiling? I don't see any code there that changes creeper flow. If you add creeper, does the gravity follow the magnetar? The fields might still be there from an earlier script run.

[Clean0nion]

Are you sure you saved the script before recompiling? I don't see any code there that changes creeper flow. If you add creeper, does the gravity follow the magnetar? The fields might still be there from an earlier script run.

That script is the only script affecting the magnetar. I have saved and recompiled many times, and have specifically removed the antishield that makes the gravity.

[knucracker]

Call DisableTowerField in your script and see if that fixes it.  EnableTowerField is a persisted attribute on a CrplCore.  So if you had it on at some point, ran and saved, then removed it from the code, then loaded the game (or just kept developing)... the tower field would stay on for the core.  You could also delete the core and add the new script (That never turns on the tower field) to the new core.

[Clean0nion]

Call DisableTowerField in your script and see if that fixes it.  EnableTowerField is a persisted attribute on a CrplCore.  So if you had it on at some point, ran and saved, then removed it from the code, then loaded the game (or just kept developing)... the tower field would stay on for the core.  You could also delete the core and add the new script (That never turns on the tower field) to the new core.

That worked! Thank you very much Virgil. May the niceness of day be maintained upon you.

[knucracker]

Just to complete the thought, once you have called DisableTowerField and saved, you can stop calling it.  In general you only have to call EnableTowerField or DisableTowerField once in the lifetime of a particular core.  Unlike manually set field cells, the TowerField attribute is persisted on a core and you only use commands to toggle it.  Tower fields in general are the most efficient way to put fields on the map.  It's internal code that recalculates all of the individual field vectors as the core moves, for instance.    So if you wanted to create a space scene with different planets and stuff and have Creeper swirl around, tower fields would definitely be the way to go.

[Clean0nion]

Just to complete the thought, once you have called DisableTowerField and saved, you can stop calling it.  In general you only have to call EnableTowerField or DisableTowerField once in the lifetime of a particular core.  Unlike manually set field cells, the TowerField attribute is persisted on a core and you only use commands to toggle it.  Tower fields in general are the most efficient way to put fields on the map.  It's internal code that recalculates all of the individual field vectors as the core moves, for instance.    So if you wanted to create a space scene with different planets and stuff and have Creeper swirl around, tower fields would definitely be the way to go.

Which reminds me of a further error I encountered previously: the central cell of a circular shield cannot be detected as field. Just thought I'd bring that up, and thanks greatly for your help.

[knucracker]

That's not technically an error since there is no field in the center of a shield or a tower field.  I know it messes with the technique of using fields to find shields, but...

[Lost in Nowhere]

It is mostly an issue on, um, Egos: Choix (and any map that borrows the random slip emitters), although I didn't run into this problem myself, the random slip emitters will occasionally pop up in the middle of a shield.

[Grayzzur]

I've found that as a general rule of thumb, when a CRPL Core is behaving strangely for no reason I can figure out it's time to delete it, make a new one and re-add the scripts. Reset all those persistent values you're not aware of.

[Clean0nion]

I've found that as a general rule of thumb, when a CRPL Core is behaving strangely for no reason I can figure out it's time to delete it, make a new one and re-add the scripts. Reset all those persistent values you're not aware of.

Thanks for that advice Grayzzur! This will be useful.