Hole issue

O Ilusionista

Captain 100K
Dunno if its intended to work this way or am I doing something wrong. I need to confirm before opening a report at GitHub.

but I've discovered that if you have a 2D level and set a hole, if you don't set an ALT for the hole, sometimes the engine fails to detect it. Some times, the engine will treat it like a hole. But sometimes it will treat it like a floor and while you can fall if you simple walk over it, if you use a script to change the velocity of the character with VELO001, DASHER, TOSS, etc, you will ending landing over the invisible floor.

Take a look at how my stage is (I've added only one hole to simplify it):
No2hwKD.png


The hole configuration:
hole 337 171 0 33 190 252 60

If you don't set an ALT, the character will land on the thin air (with zero Y velocity)...
5ZD3D4M.png


...but then will start to fall right after it
sSGouYa.png


But once you add ALT to the hole settings
hole 337 171 0 33 190 252 60 10
The move works pefectly and he will fall on the hole
JiOmCK8.png


Here is a video to make it easier to understand
https://www.youtube.com/watch?v=TwVgLLgmVIA&feature=youtu.be
I tried different builds (4432, 6315, 7061) and it happens in all of them.

magggas  Bloodbane Damon Caskey  have you guys already saw anything like that?
 
Hm.. i'm not sure if i remember correctly, but i think you was messing with some scripts about holes or hole-deaths and such. Are you sure that there are not any scripts there whhttp://www.chronocrash.com/forum/Smileys/default/embarrassed.gif :-\ich causing this issue? This because in my previous tests with the OpenBOR.v3.0.Build.6412 and 6510 i never experienced such thing. Even on an 2d level. BUT, the strange thing is that i have experienced an totally different issue instead. Which is that the ALT did not work or make any difference at all when setted up. Meaning, the holes always worked but not their ALT value.
Now about this issue i found, this is maybe not an issue at all and is just that this ability for setting an ALT on holes is also reversed alongside with other changes WD was made back then. Because really, i tried many times with the latest engine and the ALT on holes never worked. It acted always as it was the default 0 ALT. So, i think only DC can give us some light about this.

By the way, are you sure that the issue in second image is the hole and there is not an interruption from the wall/platform?

Edit: Okay, before i did not really understood your issue but now i do. So from my experience, it was always like when using some velocity script the char will perform/float first and then he will fall into the hole. Like on your first three images. But other than that, i did not really tested this behavior with  different ALT on holes because as i said above i found that the holes's ALT is not really working with normal movement.

Now about the velocity scripts overall, this behavior of floating when performing in the air, it was always there and it is actually normal. And taking this on consideration, i think what is actually happening here and in your video is actually normal. It actually means that the holes ALT is working in your case. But i'm really curious, what is happening when you set an ALT and just walk on the hole? Because From my tests The ALT when walking did not make any difference. And that is really important for the enemies AI actually  :-\

Edit2:
Okay good good, i see.. If this move is having a landframe and the animation is performing the landframe in mid air depended on how you set the hole ALT.. then yeah, that's not good or normal either  ???
 
That's strange

I don't think I've ever set hole with alt before so I'll have to try that parameter myself before understanding. I'm going to make some tests after this :)
 
This is the first I've heard of hole issues, or there being an alt attribute. If WD added it, I didn't notice and didn't undo, redo, etc., although I probably will if that is the culprit. Altitude on holes sounds exactly like the sort of pointless silliness that got him removed from the team. But again, I don't really know for sure and will need to look at the code this week to find out.

DC
 
Thanks everyone

magggas
I've tried this on the newest build I can test (7066) and I can confirm this still happens. Without Height set in hole, that strange behaviour will still happens. If you walk by over a hole with height, it will work normally.

Wd gave an explanation of how the HEIGHT would work and it makes sense to me (see bellow).
Personally, I like that. The only thing about hole that I don't like is that hole trigger onblockwscript/antiwallscript when something falls on it.
Altough this is not releated to this issue, this started to happen after WD had fixed the bomb bug https://github.com/DCurrent/openbor/issues/10

So from my experience, it was always like when using some velocity script the char will perform/float first and then he will fall into the hole. Like on your first three images. But other than that, i did not really tested this behavior with  different ALT on holes because as i said above i found that the holes's ALT is not really working with normal movement.
If this is what happens, them its not working properly.

If this move is having a landframe and the animation is performing the landframe in mid air depended on how you set the hole ALT.. then yeah, that's not good or normal either

Even if you don't set a landframe, this works on the same way. For example, I use a scripted TOSS function to use a bomb (dunno if OpenBOR set a landframe internally), it gets even worse - sometime it works, sometimes not.

Take a look (there is no wall at right side). In 4 throws, the 3rd one had landed on the air (and you can see the antiwall working inside the bug, because the bomb keep rebounding over and over)
https://www.youtube.com/watch?v=zgGgC1OcaiM

Altitude on holes sounds exactly like the sort of pointless silliness
Damon Caskey He made an examplation on this topic and that makes sense. He added it (HEIGHT not ALT) on the same time he had added Type to walls and holes - that THAT is very useful for sure.
http://www.chronocrash.com/forum/index.php?topic=3093.msg41887#msg41887
 
Back
Top Bottom