Solved Shiver Me Timbers! top o' the walls Ramp/Basemap troubles...

[oldyz]

i am at a loss here....

i am trying to match the level "geometry" to a level's aspect

the level features one ramp portion at the beginning (portion of stairs )some depressions in the middle and another ramp portion at the end (stairs)

Ran into a bunch of problems
1: i tried featuring a hole, for the depressed area, and use a couple of ramps so the base of the level of this depression area would be 17 pixels below normal - turns out ramps and holes don't combine, any portion of the ramp "below" level just becomes a flat surface
2: shadows seem to disappear on ramp areas

second attempt : i tried making "negative" ramps ( so it allows for an entity to walk lower than zero altitude) - no dice

3rd attempt
i decided to feature a wall that is 37 pixels high with a ramp at the beggining and another one at the end. BUT

problems
1: enemy entities seem to have problems moving around on top of the wall (they tremble and shake)

2: Shadows are not visible on ramp areas (or platforms)

3: not really a problem, but it seems that there is no way to give an entity basemap/ramp attributes
it would be nice to have because i have a script that changes the basemap in the prescense of the entity, and maybe this could help...

finally @O Ilusionista, the basemap ramp info might be wrong on the manual the (x,z) marker seems to belong on the bottom left corner....

 

[O Ilusionista]

1: i tried featuring a hole, for the depressed area,

As far as I know, holes can only be place on the ground, not over walls and such

2: shadows seem to disappear on ramp areas

Not really. Ramp with shadow:

second attempt : i tried making "negative" ramps ( so it allows for an entity to walk lower than zero altitude) - no dice

Its exactly the image above. The upper area is a wall, connected to a ramp


Not an easy task, @Bloodbane gave me a hand here.

1: enemy entities seem to have problems moving around on top of the wall (they tremble and shake)

I never have had such issue.

2: Shadows are not visible on ramp areas (or platforms)

Gfxshadow has extra parementers to change how this works.
See why we say that its important to read the manual often?

not really a problem, but it seems that there is no way to give an entity basemap/ramp attributes

Like what? And, btw, walls can thave TYPE, so you can give them attributes

I use it on my Avengers game - the fence and the truck uses walls, but the truck has a specific type that my wall bounce detects
So the characters will only bounce if they jump towards that specific type

 

[O Ilusionista]

Ah, I almost forget: be aware of two issues with ramps:

- you can't get items over a ramp
- you can't grab enemies when over a ramp (in fact, you can, but your character will release it as soon as it grabs the enemy)

Only scripted grabs works.

 

[oldyz]

@O Ilusionista , here is a graphic sample of my first attempt:



i lowered the level's base on the levels.txt by about 40 pixels )center dark green
then i made some walls that are 40 pixels high (light green "summits") and then added the ramps. (represented by the pink wireframes)

everything seems to work, except the enemies act jittery and weird on the summit/top of walls, and i still can't get shadow on the ramp areas (shadow dissapears)



i am checking enemy parameters and i suppose i have to add subject to wall and they might work , but the shadow issue remains, on the ramps.

Gfxshadow parameters dont seem to help, did you create/use custom shadows for that power rangers ramp?


as for the Ramp entities, i still cant find anything.
i was thinking of making a ramp object or obstacle that moves using an entity, to create a "wave effect" via multiple entities

 

[O Ilusionista]

suppose i have to add subject to wall

and subjec_to_basemap too

Bloodbane would be a better help here

 

[oldyz]

updated post and video on next post.

 

[oldyz]

update, i dont know how, but ALL shadows started working after i fixed chris's parameters like this
Gfxshadow 1 0, i did not touch any other characters parameters....

@Bloodbane , @O Ilusionista
@Kratus
i have changed "subject_to" parameters on 3 or 4 enemy characters and i still get odd behaviors, the jittery bug got better, its not fully gone, but i see some of the fixed enemies climbing or teleporting to the tops of some walls or columns

here is a video with the weird behavior, Notice the executioner Jittering or shaking and the "jason" too, , which goes on dissappearing on the culumn area towards the end of the video...

ironically, they behave fine in the ramp/basemap areas. (no jitters)

another issue i am facing is that if you die on the top of the wall (hills or hight terrain) areas, your character spawns on the top of any nearby wall or column, some of them 2000 pixels high...

see video 4 to 5 second mark

finally i have noticed that the engine has crashes (kratu's version more often) when the "debug setting - features" is enabled on my module's Aztec level, on one machine, i even get a message that a Dll is missing.
other "features" bug i get is that some letters on the menus dissappear

if i disable the features i get no crashes

 

[O Ilusionista]

i dont know how, but ALL shadows started working after i fixed chris's parameters like this
Gfxshadow 1 0,

see here:

Gfxshadow has extra parementers to change how this works.
See why we say that its important to read the manual often?

They started to work... because you had changed the parameter

 

[oldyz]

@O Ilusionista

indeed , what i find weird is the fact that i did not touch any of the other characters, only Christopher,

another weird thing is that i removed the 0 again tested and the shadows where still working well - i put the 0 back anyway

before testing , i always close the game completely , so i dont think its some memory issue-

anyway, i am still wondering what causes the weird behaviors of the other entities,
could it be that too many walls, platforms and such can confuse them?

that aztec level has the wall at the base , a ramp on the left, , the cliff platform, simulated limits for the back portion, a big front invisible wall to contain the characters away from the extra 37 pixels of the level lift and the aztec column...

that same jittering behavior is seen on the van level where the van is a wall, and is sandwiched between 2 walls one front one back - i always thought the splat script was the culprit for the "dancing" entities...

 

[Bloodbane]

This is the panel for aztec level.


Why do you need to code the ramp on left and right side? Original game only use this panel as simple level, save that pillar.

 

[oldyz]

updated the post again, video featured (plase delete this post)

 

[oldyz]

@Bloodbane

this Aztec level was my first experiment with ramps, before the "green hills"
old Aztec had a wall 150 pixels wide horizontal, where the characters would spawn and then jump down, this wall would stay and you ended up with this weird invisible wall on the left.. and the playable area was reduced.
the stairs going down onthe right, where simulated with an invisible wall that matched the angle going down...

since i would like to let players actually move & do the jump themselves in the future, the level's geometry was changed -
the cliff area is actual platform in the back, about 45 pixels deep, the stage itself is a wall area that is 37 pixels high
that had small ramp on the left and a small ramp on the right, instead of a hole on the edges, a big invisible wall protects players from walking up beyond a certain point (9 pixels before the Chacmol statues).

the ramp on the right had to be eliminated because it seems that openbor's basic programming only seems to allow to do ramps that look like
example A:

but not like example B:
[/ATTACH]
since the ramp on the right was not like ramp B , characters and the bosses would walk and run and you could see a weird dip that would not match what you see on the screen, so i ended up simulating the ramp using a wall again-

since i decided to keep the left ramp, the level´s floor had to be raised 37 pixels, just like the green hills.

that is why rather than use walls to raise the level , i would like to use script to lower the basemap on certain areas instead-

for example during my elevator experiments, i used this code:
@script
void self = getlocalvar("self");
if(frame == 0){
changeentityproperty(self, "base", -500);
changeentityproperty(self, "subject_to_gravity", 0);}
@end_script

with this code i would make a platform entity appear, and noticed that it would make a "hole" or dip in a stage 500 pixels deep, so that is why, if "ramp entities" where a thing, maybe a ramp entity that makes the stage "sink or dip" 37 pixels would work better.

another technique would be to make a hole and spawn an antigravity "ramp entity" 37 pixels down

Update,
possible bug confirmed:
for this video demonstration, i deactivated all holes, basemap/ramps, other walls

take a look at the Jason and the executioner, these 2 entities feature the subject to wall parameters and they still have problems

 

[oldyz]

OK,

it seems that most issues have been figured out for this topic, i will make a separate topic reguarding the special entities and another reguarding making pits on a level...

Youtube user @parearxidia4422 has provided an answer for the Shivering, Jittery behavior of the enemy entities:

"I know what the issue is.
These entities must be having some kind of antiwall scripts that are not considering the Y so they get active when the entities are on top of the wall, because the script thinks they are inside it. There are such scripts in the forum that shoud work on top of walls properly.The only problem i have with this theory is that why would you have an antiwall on idle/walking animations? So maybe is a different kind of script.So when i see the other entity walking inside a wall and then disappearing, that means only one thing. The subject_to_wall is getting constandly changing by script, like one moment is 0 so that the entity can walk indide it, and then is 1 again and so the entity is getting moved on top of the wall as supposed to. So that may be also causing the Jittering if an entity is constandly changing subject_to_wall very fast on and off while trying to walk on top of a wall.One thing is for sure, it's a per entity scrips setups that causing all this and you shoud review again your entities scripts for the stuff i mentioned."

@O Ilusionista , i will mark this topic solved, and make another topic in reguards of improving the antiwall scripts that most entities are using in NS, it think that if need be, this thread be deleted since thera are 3 or 4 different things that are best addressed individually

 

[O Ilusionista]

Ah I was going to talk about some sort of antiwall script.

There are such scripts in the forum that shoud work on top of walls properly.The only problem i have with this theory is that why would you have an antiwall on idle/walking animations?

There are many reasons to. For example, characters bboxes aren't solid and can't interact against walls - OpenBOR will use the entity axis to determine how close you can get to a wall. This is to simulate a "width".

Without it, the characters can look strange when close to walls like here:

So I added an antiwall script in some animations like idle and walk

And keep in mind: some versions of antiwall script will trigger if you are OVER a wall (like when we use a wall as a platform) and not near it only.

This was the old antiwall script I was using (I've renamed it to antiwall_old). Notice that It doesn't care about the entity "a" :

void antiwall_OLD(int Dist, int Move, int Distz)
{// Checks if there is wall at defined distance
// If there is wall, entity will be moved away with defined movement
   void self = getlocalvar("self");
   int Direction = getentityproperty(self, "direction");
   int x = getentityproperty(self, "x");
   int z = getentityproperty(self, "z");
   float H;
   float Hz;


   if (Direction == 0){ //Is entity facing left?                 
      Dist = -Dist; //Reverse Dist to match facing
      Move = -Move; //Reverse Move to match facing
   }


   H = checkwall(x+Dist,z);
   Hz = checkwall(x+Dist,z+Distz);


   if(Hz > 0)
   {
     changeentityproperty(self, "position", x, z-Distz);
   }


   if(H > 0)
   {
     changeentityproperty(self, "position", x+Move);
   }

}

Then Bloodbane had helped me fixing it:

void antiwall(int Dist, int Move, int Distz)
{// Checks if there is wall at defined distance
// If there is wall, entity will be moved away with defined movement
   void self = getlocalvar("self");
   int Direction = getentityproperty(self, "direction");
   int x = getentityproperty(self, "x");
   int y = getentityproperty(self, "a");
   int z = getentityproperty(self, "z");
   float H;
   float Hz;
   float Hw;


   if(Direction == 0){ //Is entity facing left?                 
      Dist = -Dist; //Reverse Dist to match facing
      Move = -Move; //Reverse Move to match facing
   }


   H = checkwall(x+Dist,z);
   Hz = checkwall(x+Dist,z+Distz);
   Hw = checkwall(x+Dist,z-Distz);


   if(Hz > y && Hw <= y)
   {
     changeentityproperty(self, "position", x, z-Distz);
   }


   if(H > y)
   {
     changeentityproperty(self, "position", x+Move);
   }
}

This code won't trigger when you are on top of a wall like this:

 

[O Ilusionista]

for example during my elevator experiments, i used this code:
@script
void self = getlocalvar("self");
if(frame == 0){
changeentityproperty(self, "base", -500);
changeentityproperty(self, "subject_to_gravity", 0);}
@end_script

with this code i would make a platform entity appear, and noticed that it would make a "hole" or dip in a stage 500 pixels deep, so that is why, if "ramp entities" where a thing, maybe a ramp entity that makes the stage "sink or dip" 37 pixels would work better.

As @DCurrent told me long time ago (and I've experienced it myself) its a bad idea to turn off gravity like this. Because you will need to turn it on back later and if you don't, your character will fly

Also, why you are changing the base for this? It's not a good idea either.

From what I see, you are using this method to simulate a pit:

and to simulate the lower area/pit, you are changing the base to -500, right? Beware, if you go with a higher number, the engine can kill entity, because when you fall on a hole, the engine treats it like you have now base -1000.

I would suggest you to use the stage like this:


If you want to simulate an elevator going up (like SOR2 last boss), you can play with the z setting and it will look the same.

 

[oldyz]

please delete this post

 

[oldyz]

deleted this post, another topic was a better fit.

 

[oldyz]

i have deiced to mark this topic as solved, since all issues have been solved.

other issues are related to grabs, tosses and throws, that will probably take another approach