Solved Possible hard coded engine spawn issue?

[PS_VITA]

Hello,

I'm having a strange issue that I can't seem to find a solution for over a month now.

I can't spawn player 1 or 2 If I'm over the altitude of 3500 pixels.

The stage I created is 6000 pixels high and I can happily spawn enemies, P1 or P2 if I spawn them below 3500 pixels.

If I do spawn any enemy or player above the 3500 pixels mark it will be deleted instantly.

causing game over screen.

I've gone over the spawn script and I see no evident issues. I've even disabled it for testing purposes and the issue is still happening.

Could there be a hard coded rule that if entities get spawned over 3500 pixels high they are deleted?

I highly doubt that, but I thought maybe it was worth checking with you guys first.

Edit: By the way I was able to finish the stage with a trick but I would still like to know why was this happening.

The "trick" I used is that any entitie that needed to be spawned above 3500 pixels high, I would spawn them below than with a script move them to higher places 2 seconds after they spawned. It was a simple script but it did the trick.

 

[DCurrent]

I don't think that's the case, but it's possible. I'll check source code next time I'm at my desk.

DC

 

[PS_VITA]

I don't think that's the case, but it's possible. I'll check source code next time I'm at my desk.

DC

Yeah I didn't think so either specially because I've seen some crazy castlevania mods and those mods have to have really high pixels count stages.

 

[machok]

I don't have this problems

spawn holly_wood_red
alias holly_wood
@script void main() {
   performattack(getlocalvar("self"), openborconstant("ANI_FOLLOW5"));
} @end_script
flip 1
coords -35 240
at 3770

although my longest stage does not exceed 5000 pixels
no offscreenkill or something?

 

[O Ilusionista]

I don't think that's the case, but it's possible. I'll check source code next time I'm at my desk.

DC

As far as I know, yes, there is an altitude limit.
I can't remember if it's tied with the wall altitude limit too - for example, if you have a wall with 6000px and you spawn over it, your character is killed.

On my Avengers game, at the select screen, i was once using an entity to display the bios and I was changing it's altitude to show different parts of the image ( i use a big image and shifts it's position). After a certain value, the entity gets killed.

I solved this by changing the shift to the Z axis instead.

 

[DCurrent]

As far as I know, yes, there is an altitude limit.

Right, but I meant I believe the limit adapts itself to resolutions. I just realized I misread something though.

The stage I created is 6000 pixels high and I can happily spawn enemies, P1 or P2 if I spawn them below 3500 pixels.

I mistook this for resolution. Yes, the killing is a hard coded behavior. It's a complex formula that takes into account your scroll position, offscreenkill setting, and screen resolution, but the short version is go too far off the screen and you die. Actually, you don't even die. You're just killed. Yes, there is a big difference.

The reason your enemies aren't killed is they have much more default leeway (offscreenskill) than players do.

int osk = self->modeldata.offscreenkill ? self->modeldata.offscreenkill : DEFAULT_OFFSCREEN_KILL;

    if((self->position.z != ITEM_HIDE_POSITION_Z && (advancex - self->position.x > osk || self->position.x - advancex - videomodes.hRes > osk ||
                              (level->scrolldir != SCROLL_UP && level->scrolldir != SCROLL_DOWN && (advancey - self->position.z + self->position.y > osk || self->position.z - self->position.y - advancey - videomodes.vRes > osk)) ||
                              ((level->scrolldir == SCROLL_UP || level->scrolldir == SCROLL_DOWN) && (self->position.z - self->position.y < -osk || self->position.z - self->position.y > videomodes.vRes + osk))        ) )
            || self->position.y < 2 * PIT_DEPTH) //self->position.z<ITEM_HIDE_POSITION_Z, so weapon item won't be killed
    {
        if(self->modeldata.type & TYPE_PLAYER)
        {
            player_die();
        }
        else
        {
            kill_entity(self, KILL_ENTITY_TRIGGER_OUT_OF_BOUNDS);
        }
        return 1;
    }

Super short version: Mess with your player model's offscreenkill setting a bit.

DC

 

[O Ilusionista]

Mess with your player model's offscreenkill setting a bit.

Wait, off screen kill works with altitude too?

 

[DCurrent]

Wait, off screen kill works with altitude too?

Indeed, it does. The forumla is hard to read, but its behavior changes depending on if the level can scroll vertically or not. It also takes into account your Z posiiton, since both have an effect on your Y axis drawing position.

In either case though, entities out of bounds are killed instantly, same as X axis.

DC

 

[PS_VITA]

Thanks guys,

I'll mess around with the offscreen kill settings but what is the recommended setting for my particular scenario does it even matter if I put a a value of 6001 vs 1,000,000? would a higher value stress the engine more? As in less optimized?

 

[machok]

I usually add this in long stages make the spawn system more stable

spawn empty
at 10000

Or maybe it's just Placebo effect

 

[DCurrent]

@machok, @PS_VITA

No need for silly values, you're not fighting a bug. The engine is doing exactly what it's designed to do. Just figure out how far your wall is taking players out of the screen, and that's your offscreenkill value.

DC

 

[DCurrent]

Just a quick elaboration. I said the engine was behaving as it was designed, but I didn't mention why. Killing offscreen entities serves two main purposes.

For players, it's a failsafe. In most cases, a player far out of screen is due to creator error. When this happens they usually get stuck and soft lock the game. Killing offscreen players is the safest preventative. When creators really do intend to push players out of screen, they can always adjust offscreenkill values for the player models.

For all other entities, it's simple optimization. When entities reach an out of bounds position, we can assume they are out of play, so they're killed to free up system resources. The defaults will accommodate most level designs, but of course you can adjust them to suit your particular needs.

HTH,
DC

 

[PS_VITA]

HTH,
DC

what is that particular value?

 

[DCurrent]

what is that particular value?

It's different for every type, and I'll have to look through the source code to check.

DC

 

[PS_VITA]

It's different for every type, and I'll have to look through the source code to check.

DC

Okay, no worries than. Thanks

 

[DCurrent]

@PS_VITA,

I went through the code and unless I missed anything, these are the default offscreenkill values:

Arrow	200
Biker	300
Bike Driver	100
Global Default (Fallback value for out of bounds function when the entity has no offscreenkill value)	3000
Knife spawns	200
Projectile (new type in development)	Horizontal Screen Size * 0.5
Steamer	80

As you can see, I was mistaken about players having a smaller offscreenkill, and I've corrected my earlier post to reflect that. They don't have a default at all, and neither do enemies, which mean both use the global default value.

I also noticed you can modify global default with a command line argument. Not really useful these days, but still interesting. It's probably something the original BOR devs used for debugging.

DC

 

[PS_VITA]

@PS_VITA,

I went through the code and unless I missed anything, these are the default offscreenkill values:

Arrow	200
Biker	300
Bike Driver	100
Global Default (Fallback value for out of bounds function when the entity has no offscreenkill value)	3000
Knife spawns	200
Projectile (new type in development)	Horizontal Screen Size * 0.5
Steamer	80

As you can see, I was mistaken about players having a smaller offscreenkill, and I've corrected my earlier post to reflect that. They don't have a default at all, and neither do enemies, which mean both use the global default value.

I also noticed you can modify global default with a command line argument. Not really useful these days, but still interesting. It's probably something the original BOR devs used for debugging.

DC

Thanks for this,
it all makes sense now.

I mentioned 3500 "pixels height" in my original post but I'm see that you wrote 3000 for global default. Perhaps it had something to do with my offset values as well, I'm just curious to know why there was a 500 pixel difference.

It's all good now.Thanks for going above and beyond.

I'm pretty sure we all appreciate it.

 

[DCurrent]

I'm just curious to know why there was a 500 pixel difference.

There several factors that come into it. Remember it takes into account your Z position too, and also that 3000 means 3000 pixels out of the screen boundary. It's not a hard limit of "go 3000 pixels and *zap*".

DC