OpenBOR v3.0 Build 4316 (Windows/Wii/Android)

Status
Not open for further replies.
do not compare that script with hardcoded script.
I improved that script and so just you need for just these params:
#basemap xpos zpos xsize zsize ymin ymax
 
White Dragon said:
do not compare that script with hardcoded script.
I improved that script and so just you need for just these params:
#basemap xpos zpos xsize zsize ymin ymax
Click to expand...

Ok, then how do I change the basemap direction and prevent from getting stuck at the top where the basemap connects to the wall?
 
direction is automatic now. it's defined by ymin ymax
ymin ymax = 0 5 -> down to up (dir 1)
ymax ymin = 5 0 -> up to down (dir 0)
so, simply, write right values
 
White Dragon said:
direction is automatic now. it's defined by ymin ymax
ymin ymax = 0 5 -> down to up (dir 1)
ymax ymin = 5 0 -> up to down (dir 0)
so, simply, write right values
Click to expand...

Ah, I see. I like that! There is still one problem though. Try this level:

Levels.txt
Code: 
set Test
z 416 416 160
file	data/stages/test.txt
end

test.txt
Code: 
Wall  0 417 0 0 96 96 30 96
basemap 96 416 96 2 96 0

Now try walking up the basemap onto the wall with player speed 30. Most of the time, you will get stuck. If the player speed is a lower value like 10, you don't get stuck.
 
updated openbor to conform  basemap parameters with hole/wall params
tested, but it works well for me..
with new version try to use:
Wall  0 417 0 0 96 96 30 96
basemap 94 417 96 2 99 0

not because generate_basemat doesnt work well... but for a better visual effect
 
All these engine updates have me hyped to work on my mod again so DC and WD thank you for all your hard work its very much appreciated !
 
msmalik681 said:
All these engine updates have me hyped to work on my mod again so DC and WD thank you for all your hard work its very much appreciated !
Click to expand...

thanks to you and your support!
W OpenBOR and our community!!  ;)
 
White Dragon said:
updated openbor to conform  basemap parameters with hole/wall params
tested, but it works well for me..
with new version try to use:
Wall  0 417 0 0 96 96 30 96
basemap 94 417 96 2 99 0

not because generate_basemat doesnt work well... but for a better visual effect
Click to expand...

I tried the new build 4388 with those values, but the problem is still there:
https://gfycat.com/SparklingCookedIberianemeraldlizard

Alucard has a walk speed of 20.
 
ok, try to increase max_y
or better make a new basemap with min_y == max_y of 1 or 2 pixels out the wall to connect to it, if you want you can use x_cont too
 
You mean like this, right?

Code: 
Wall  0 417 0 0 96 96 30 96
basemap 94 417 96 30 96 0 #basemap
basemap 96 417 2 30 96 96 #x_cont

I don't like increasing max_y because the character appears slightly higher above the wall and drops down on it.
Creating a second basemap for x_cont seems to work (I think I did right), I can walk and run up the basemap no problem!
However doing moves that makes the player move quickly (dash, backdash, etc) can still cause the player to get stuck, the results are inconsistent. Sometimes the player gets stopped:
https://gfycat.com/GiftedDrearyHummingbird
 
try:
Wall  0 417 0 0 96 96 30 96
basemap 94 417 96 30 99 0 #basemap (stair)
basemap 96 417 2 30 96 96 #square basemap

you need to play with params.
ps. fixed x_cont in new build
 
I tried build 4389 with those values and nothing changed.

Changing the y_max to 99 or higher in the basemap makes the chance of getting stuck lower but it looks bad to walk higher than the wall's height of 96.
 
Yes because if you are front a wall in basemap y=5 and wall is y=7 your speed skip the some you (and the last y=7 too)  range and you will be directly from 5 to 7. But 7>5 so you player recognize it with a wall and it stucks. So in this case connect a stair basemap with a square basemap and not with a wall
 
I think I understand now, just replace a part of the wall with a square basemap? It does seem to solve the stuck problem.
Either build 4378 or 4379 broke the opposite direction for basemap, try this:

At the bottom of the basemap in this direction you rise sharply to the max height of 96 for a brief moment:
Code: 
basemap 96 417 96 3 0 96

The other direction works fine:
Code: 
basemap 96 417 96 3 96 0
 
However doing moves that makes the player move quickly (dash, backdash, etc) can still cause the player to get stuck, the results are inconsistent. Sometimes the player gets stopped:
https://gfycat.com/GiftedDrearyHummingbird
Click to expand...

nice work on the afterimages
 
Viper Snake said:
I think I understand now, just replace a part of the wall with a square basemap? It does seem to solve the stuck problem.
Either build 4378 or 4379 broke the opposite direction for basemap, try this:

At the bottom of the basemap in this direction you rise sharply to the max height of 96 for a brief moment:
Code: 
basemap 96 417 96 3 0 96

The other direction works fine:
Code: 
basemap 96 417 96 3 96 0
Click to expand...

thanks, improved the generate algorithm
 
Thanks for the fix! I tried using a square basemap instead of a wall to connect both directions and it works perfectly!

Code: 
basemap 96 417 96 3 0 96 
basemap 192 417 96 30 96 96 
basemap 288 417 96 30 96 0

Having a lot of fun with this!

https://www.youtube.com/watch?v=nBMkkGnRQj0

O Ilusionista said:
nice work on the afterimages
Click to expand...
Thanks!  :)
 
Something is wrong with load game. I don't know what build broke it.

1) Make sure you have no save data and start a new game
2) In the first level.txt have this line:
Code: 
nosave 0
3) Pause, return to title screen and go to load game.
4) It will say there is no save data, but if you press ENTER on the back option, the screen will turn black and openbor will be "not responding". Pressing ESC instead of ENTER will return you to previous screen safely.
 
Guys, I've found something and I would like to know if this is the normal behaviour.

I have an enemy projectile with CHASE as subtype, so it chases the player. But I have a player with a DUCK animation without bbox (I forgot to set one) and I noticed the chase projectile will just ignore the player on that animation. The same happens if you forgot to add a bbox in other animation and an enemy come closes: it won't attack the player.

Is this intentional? I think this is fine and it should work this way, I am just curious about this.
 
Status
Not open for further replies.
Back
Top Bottom