Problem with DELETE

Previous topic - Next topic

kaotiklabs

Hi,
I have an enemy type with an array inside wich is used for the A* algorithm result.

If I delete an enemy inside a FOREACH with the DELETE command, the arrays containing the A* result of the rest of the enemies is been modified. It seems like a problem with the pointers, maybe?

In other words, when I deleted an enemy, all the other enemies' paths are messed.

For better understanding I will post you the code.
Thanks in advance and hope anyone can guide me correctly :)

Code (glbasic) Select
TYPE TEnemy
x
y
w
h
dx
dy
speed
life
path[]
pathlength
ENDTYPE


Code (glbasic) Select
FUNCTION SpawnEnemy:

LOCAL temp AS TEnemy
temp.x = (sx-1)*RND(1)
temp.y = RND(sy-1)
temp.w = 26
temp.h = 34
temp.life = 100
temp.speed = 1

temp.pathlength = FINDPATH(map[], temp.path[], 0.0, temp.x/mapstep, temp.y/mapstep, (sx/2)/mapstep, (sy/2)/mapstep)

IF temp.pathlength > 0
DIMPUSH enemies[], temp
ENDIF

ENDFUNCTION


Code (glbasic) Select
FUNCTION MoveEnemies:
FOREACH temp IN enemies[]

LOCAL a = temp.path[0][0]*mapstep - temp.x
LOCAL b = temp.path[0][1]*mapstep - temp.y
LOCAL m=SQR(a*a + b*b)

IF m < 1
//reached checkpoint
IF LEN(temp.path[]) > 1
DIMDEL temp.path[], 0
ELSE
//reached objective
DELETE temp
ENDIF
ELSE
temp.dx = (a/m) * temp.speed
temp.dy = (b/m) * temp.speed"
ENDIF

INC temp.x, temp.dx
INC temp.y, temp.dy

IF temp.life <= 0 THEN DELETE temp
NEXT
ENDFUNCTION



Vote Cthulhu! Because the stars are right!!!!
Ia Ia Cthulhu F' tang!

MrTAToad

DELETE works fine - I think the problem is with DIMDEL in that your code looks like it is modifying the values for index 0 even after it's been deleted (perhaps add a CONTINUE) after DIMDEL

Slydog

#2
To make your code cleaner and easier to read / modify, i would suggested changing your path from a 2D array into a 1D array of points (new TYPE), such as:
Code (glbasic) Select
TYPE TPoint
x%
y%
ENDTYPE


Then right after you perform the FINDPATH() command (storing into a temporary/local 2d array), move the results into the new TPoint array, such as:

Code (glbasic) Select
LOCAL path[]
LOCAL px%

temp.pathlength = FINDPATH(map[], path[], 0.0, temp.x/mapstep, temp.y/mapstep, (sx/2)/mapstep, (sy/2)/mapstep)
DIM temp.map[temp.pathlength] // The new 1d point array

FOR px = 0 to LEN(map[])-1
temp.map[px].x = map[px][0]
temp.map[px].y = map[px][1]
NEXT


Something like that. 
This avoids the 2d array confusion.  Plus is easier to read and use later on.

[Edit] Fixed a few typos.  Also, you could rename all your 'temp' variables to 'enemy' for readability.
My current project (WIP) :: TwistedMaze <<  [Updated: 2015-11-25]

kaotiklabs

Hehehe, I followed your advices and it worked perfectly.
Thanks mates!! You are great!

Vote Cthulhu! Because the stars are right!!!!
Ia Ia Cthulhu F' tang!

mentalthink

kaotic, sorry for continue whit the post... and sorry for my ignorance, but in this case for what´s it´s util the pointer... and thanks I don´t know GLbasic can handle whitout inline Pointers...

kaotiklabs


Well, Im not using pointers directly in my GLB code but they are beeing used internally for handle all the arrays in C.
The weird behaviour did me think there was an "internal" issue.
Vote Cthulhu! Because the stars are right!!!!
Ia Ia Cthulhu F' tang!

mentalthink

Thanks Kaotic... this issue I think it´s too much for me... :blink:  I hope you explain when you desire how makes this very advanced thinks...  :-* :booze:

Un saludo,

kaotiklabs

Te lo explico en español para no liarme.

GLBasic funciona internamente en C. Los arrays en C usan punteros.

Me pasaba una cosa rara al usar arrays en GLB y pensé que habria algún bug en el código en C de Gernot.
En GLB no hay punteros, por lo que no podemos usarlos directamente.
Cosa que no implica que no existan de verdad y puedan dar problemas.

No se si me explico.
Vote Cthulhu! Because the stars are right!!!!
Ia Ia Cthulhu F' tang!

mentalthink

Gracias Kaitic te he enviado un MP.

Thanks Kaotic I send you a PM.