Woes with activation regions

[EntropiaFox]

Hello there, once again.

While I was able to solve the issues I was having with weirdly disappearing enemies / healthbars thanks to skydereign's help, another issue arose, this time exclusively related to activations regions, or, well, the use I'm giving to them.

On my current game iteration, my activation regions for each room overlap a bit so my player actor has an existing and definite target to move to when moving across rooms. However, this causes issues at times. For example, sometimes enemies or objects spawn twice, or they disappear because the view just left the other activation region they belong to, or some control variables I have are set more than once because as long as the player is in the intersection of the regions, both will seemingly exist.

I'm trying to look for a solution to this problem, one thing I was thinking about was to actually spawn enemies/items not when they come into view (Because view enters their activation region when overlapping), but rather when the player actor reaches his destination (Collision event with "prevmk" and "nextmk" actors, which I'm using as destination locations when moving between rooms), but I imagine this would cause a delay that would turn annoying with a sizable number of actors, and would limit my placement options (It would be bad to place an enemy right next to a "door", because it would not be there by the time the player gets inside, but would suddenly appear as it gets spawned, for example). Another option would be ensuring the existence of only one spawned actor per spawner, but would things like emitters rather impractical. I would like to know if anyone else has experienced things like these, and if they did, which approach you used to solve them. Thanks a lot in advance!

[skydereign]

Okay, well the system you were using uses intersecting activation regions, which as you stated is the cause of your problems. One weird thing about activation regions is that you can access actors in other activation regions. So, you don't have to have the regions intersecting, and your room jumping code will still work. You can even edit the nonexistent actor's actor variables, for instance turning them a different color.

[EntropiaFox]

Okay, well the system you were using uses intersecting activation regions, which as you stated is the cause of your problems. One weird thing about activation regions is that you can access actors in other activation regions. So, you don't have to have the regions intersecting, and your room jumping code will still work. You can even edit the nonexistent actor's actor variables, for instance turning them a different color.

Thing is, I'm using a MoveTo to another actor to move between rooms, and I was under the impression that, in order for my player's actor to survive the transfer, it needed to be the intersection of both activation regions so it's not "lost" when view moves out of the previous activation region to the next (I can't remember the exact place in which I read about that, but surely was on the forums when tackling some problems with activation regions and player actors disappearing during the transfer). Oh boy...

Also, made a quick test and removed any overlaps and indeed, while I seem to be able to change the actor variables for actors that aren't even created yet (Haven't actually checked if the changes are being kept), MoveTo to an nonexistent actor naturally fails. I wouldn't want to give up the convenience of using a reference actor when moving my player actor between rooms, as opposed to using absolute coordinates.

[skydereign]

First of all, there are other ways of moving actors besides MoveTo, so you don't have to use it. But, it sounds like when using MoveTo do jump to another actor, it fails for you. Is that the case? Because it doesn't happen for me when I was editing your game.
Well all I did was move the regions so they were no longer colliding. The game runs fine, and the player actor is never destroyed in between the jumps. While I know of the problem you are talking about, it doesn't apply here. When you move an actor into another region it does not get destroyed if it wasn't an actor created with CreateActor. Activation regions only destroy and create things when you enter/leave a region. So, if the view is in your first region, and you move the player into the second region, then move the view to the second region, the player will never get destroyed. But if you created the player in the first region, and tried to do the same thing, the player would be destroyed. And, since you are able to access non-existing actors (ones that are in other regions) you can continue to use your actors to jump between.

[EntropiaFox]

First of all, there are other ways of moving actors besides MoveTo, so you don't have to use it. But, it sounds like when using MoveTo do jump to another actor, it fails for you. Is that the case? Because it doesn't happen for me when I was editing your game.
Well all I did was move the regions so they were no longer colliding. The game runs fine, and the player actor is never destroyed in between the jumps.

Either I keep omitting something really important, or my computer is simply cursed, because it doesn't work for me that way. One thing I forgot to mention is, it does work using GE's "Game Mode", but I'm using an executable export for tests, because I did read that activation regions only worked the way they should when exporting.

Anyway, until I find a proper solution to this issue, I'm just using absolute positions (MoveTo using "Game Center" as a reference), so I can work in other parts of my game. I still want to use reference actors, but I'll try to come up with something better later, or just use spawners for everything. Thanks a lot for the help again, though!

[skydereign]

Ah, okay, that makes sense. I do almost all my work in game mode so I wasn't taking the actual export into consideration. There are things you can still do without having to put in your own coordinates. Albeit these are less preferable, but I'd avoid having activation regions collide due to the nature of activation regions. Since your warp points are used by regions, you can use their coordinates, plus width/height to determine where to put the actor. This is kind of roundabout, and there are other options. I personally would use actual coordinates, but I wouldn't ever type them. In Global Code, I'd make a variable, just name it spawn or similar.
Global Code

Code: Select all

int spawn[50][2];

The 50 is just however many spawn actors their are.
nextroom -> Create Actor -> Script Editor

Code: Select all

spawn[cloneindex][0]=x;
spawn[cloneindex][1]=y;

Then on some key event of the view, have this.

Code: Select all

int i;
FILE* file = fopen("spawn.c", "w");
fprintf(file, "int spawn[50][2] = {");
for(i=0;i<50;i++)
{
    fprintf(file, "{%d, %d}, ", spawn[i][0], spawn[i][1]);
}
fprintf(file, "};");
fclose(file);

That event will generate the xy coordinates you need, and you can still use the actors to hold the spawn positions. The file it creates, you can load it in (to replace the script with the int spawn[50][2];) and it will have the actual coordinates). Of course you might need to create a giant region to encompass everything when you do this, and it will need to be updated whenever you start adding more rooms... but it was the first thing that came to mind (so there might be a more elegant solution).

If you want to keep the intersecting regions, then you'll have to overcome the current problems with the double regions, which if that is the case, I can help with that instead.