game-editor.com

I'm this | | close to completely ditch GE's built-in timers and use variable timers, but before that I decided it wouldn't hurt to ask about this most peculiar behavior of actors with infinite timers...

Here's more or less the problem I'm having. I have attached the latest version of my game prototype, and in the "enemy_prototype" actor, you'll notice two timers are created, a "HurtTimeout" that only happens once when they get "hurt" (Collide with "player_attack"), and an "AttackInterval" which is periodic and infinite (One inside and outside of script, in case that was the problem, it wasn't ). So far so good, the enemies turn around and shoot at my general direction with every AttackInterval timer event, for now the bullets do nothing but to destroy themselves when colliding against a wall (A "solid" actor) or after they've been traveling for some time. You'll also notice the "enemy_prototype" creates by itself two more actors, an instance of "healthbar" and "health_display_numbers" that display the enemy's health graphically and textually (Along with some other information, and yes, I just read about activation events, and indeed I believe I could pass their cloneindex numbers more efficiently, though I'm open to any more ideas as to how associate them with their parent / creator so they get destroyed along with it. Would something like "if(!creator) DestroyActor(clonename);" work without so much hassle?). Now this is when things get freaky.

Upon exiting the room, and thus the activation region in which all "enemy_prototype" instances were, when re-entering, they don't seem to "respawn" if I have killed them before. Moreover, their "healthbar" and "health_display_numbers" actors don't get created for some reason. However, removing the CreateTimer event restores what I assume is normal behavior (They "respawn" when entering their corresponding activation region and "healthbar" and "health_display_numbers" get created correctly). Any ideas on what I could be doing wrong?

PS: Also, some of you might be able to notice I'm using some snippets of code I've seen around these forums, among them pyro's method for collisions, lcl's (I believe?) anti-moonwalk, Bee-Ant's dialog system (With a few tweaks) and such. Thank you all!

Here is a way to tell if the creator or parent is destroyed.

Code: Select all

if(getclone(creator.clonename)->cloneindex==-1)
{
    DestroyActor("Event Actor");
}

getclone returns a fake actor with a cloneindex of -1 if the actor does not exist (instead of a NULL).

Now, you've assumed wrong about activation regions. Any actor within an activation region, not created by a CreateActor call (so put there on the stage) will be recreated when you leave and reenter the region, if and only if the actor was not destroyed with a DestroyActor call. That is to say, all actors created with a CreateActor call, and all actors destroyed with a DestroyActor call, will not respawn when you reenter the region that they existed in. I don't know how removing the timer changed that, it didn't for me, so here is the better way to do it (when using activation regions).

You need to create a spawn actor, that will spawn these enemies.
spawn -> Create Actor -> Script Editor

Code: Select all

CreateActor("enemy_prototype", "WrathfulGhostF_StandL", "(none)", "(none)", 0, 0, false);
VisibilityState("Event Actor", DISABLE);

If you plan to have more enemies, you might use the spawn actor's animation (so give it the enemy actor's animation) to determine what actors to spawn (and their animation), but that is up to you.

skydereign wrote:Here is a way to tell if the creator or parent is destroyed.

Code: Select all

if(getclone(creator.clonename)->cloneindex==-1)
{
    DestroyActor("Event Actor");
}

getclone returns a fake actor with a cloneindex of -1 if the actor does not exist (instead of a NULL).

Oh, that makes sense. Thanks, that's what I was looking for!

And yes, with an enemy spawner the issue I was having no longer happens. Thank you a lot for the help! Now I gotta solve some issues with disappearing solid actors, which I believe it's due some overlapping activation regions. Or just go back to pixel perfect collision detection for most things, though I do recall I had a reason I decided to go with bounding boxes for some actors. Well, it does let me have asymmetrical sprites, so I don't have any protruding bits getting stuck on edges.