HTML5 [SOLVED?] Does mp_grid_path work on HTML?

[solarcrispz]

**UPDATE : THIS IS AFTER A MONTH OF NO PROGRESS ON THE ISSUE AND NO WORD FROM YOYO**
Help! mp_grid_path works absolutely fine on the windows client version of my game. However, on HTML I frequently get this error:



Above happens when the player collides with a wall, presumably because the player clips into it a bit.
The collision code is simple; just a check to see if the player is place_meeting with the relevant collision objects ("wallmid1_object") and if not, it does your typical x/yadd stuff.
Additionally, I made a collision event where if the player is touching a wall, said wall turns temporarily solid (NOTE: I've disabled and enabled feature many times to get around this crash with no avail).

This is the line of code in question:

var mx = (nearestplayer.x div 16) * 16 + 8;
var my = (nearestplayer.y div 16) * 16 + 8;
if path_exists(path){
      path_delete(path);
}
path = path_add();
if mp_grid_path(global.grid, path, x,  y, mx, my, 1){
      path_start(path, pathspd, 0, false);
}
else{
      path_destroy(path);
}

//This is the create event (in separate object obviously):

//Grid Create event
var cellwidth = 16;
var cellheight = 16;
var hcells = room_width div cellwidth;
var vcells = room_height div cellheight;
global.grid = mp_grid_create(0, 0, hcells, vcells, cellwidth, cellheight);
//Add the things to avoid
mp_grid_add_instances(global.grid, wallmid1_object, false);

I've tried forming requisites like position checks with mx / my and collision objects (place_meeting and what not), have tried enabling precise hit boxes for the collision objects, have gone in and made sure that the collision objects match up with the 16x16 grid, have changes mx / my to various things like (nearestplayer.x div 16) * 16, have increased and decreased grid size. I've tried alot of things.
One thing I've noticed, though, that increasing the player size (scale) seems to mitigate the collision issue alluded to above where a crash occurs if the player touches / clips into the collision wall slightly. But the problem still persists.

Am I missing something? I know this is a complex issue, but I figure I'd see if it weren't something more systemic to HTML that I was unaware of that community might be aware of.

TLDR: mp_grid_path seems to not work on HTML, resulting in crashes every time my player slightly clips a wall. I've tried a lot of things. It works just fine on client version.

 

[solarcrispz]

bump
Does anyone have any advice? Yoyo is completely silent a month after my help inquiry request (I suppose the virus might be complicating things)

 

[Roldy]

TLDR: mp_grid_path seems to not work on HTML, resulting in crashes every time my player slightly clips a wall. I've tried a lot of things. It works just fine on client version.

I would imagine your problem is with the math you are passing into mp_grid_path or create.

What are the values for:

var mx = (nearestplayer.x div 16) * 16 + 8;
var my = (nearestplayer.y div 16) * 16 + 8;

And how do they differ between HTML and windows platforms.

Output the mp_grid and verify they are the same on both platforms. If they are not then remedy this issue there.

If they are then step through the code and verify your goal positions are being calculated the same on both platforms.

There are certainly differences between HTML and windows platforms. You will need to identify exactly what is causing your problem before anyone could really help you.

 

[solarcrispz]

I would imagine your problem is with the math you are passing into mp_grid_path or create.

What are the values for:

var mx = (nearestplayer.x div 16) * 16 + 8;
var my = (nearestplayer.y div 16) * 16 + 8;

And how do they differ between HTML and windows platforms.

Output the mp_grid and verify they are the same on both platforms. If they are not then remedy this issue there.

If they are then step through the code and verify your goal positions are being calculated the same on both platforms.

There are certainly differences between HTML and windows platforms. You will need to identify exactly what is causing your problem before anyone could really help you.

Thank you for your reply.
I checked for the potential differences between the mx/my values between the client and browser versions and found no differences. The HTML version in my experience has a hard time handling float values, so I thought that might've been it. No dice though.
I also went and showed debug messages for the bool return of the mp_grid_path check. I found that the browser version does return false (0), but for some reason STILL attempts to make a path as if it were true.
I verified this by recreating a symmetrical crash in the client version, same scenario and values etc, and the client version went to the
else{
path_destroy(path);
}
just fine. The browser version just crashes.

 

[Roldy]

Thank you for your reply.
I checked for the potential differences between the mx/my values between the client and browser versions and found no differences. The HTML version in my experience has a hard time handling float values, so I thought that might've been it. No dice though.
I also went and showed debug messages for the bool return of the mp_grid_path check. I found that the browser version does return false (0), but for some reason STILL attempts to make a path as if it were true.
I verified this by recreating a symmetrical crash in the client version, same scenario and values etc, and the client version went to the
else{
path_destroy(path);
}
just fine. The browser version just crashes.

Right but it is mp_grid_path function that is throwing the error based on mx, my.

Put a mp_grid_get_cell before that and test that your end position is not blocked https://docs2.yoyogames.com/source/_build/3_scripting/4_gml_reference/movement and collisions/motion planning/mp_grid_get_cell.html

Something like:

var _pathSuccess = false;
// Test first that end position is not blocked
if (mp_grid_get_cell(global.grid, mx, my) == -1) {
  // something is wrong
  show_debug_message("Something wrong: " + string(mx) +  "  " + string(my));
} else {
     // If you still get here then there probably is something wrong with mp_grid_path on HTML
     _pathSucess = mp_grid_path(global.grid, path, x,  y, mx, my, 1);
}

if (!_pathSuccess) {
    path_destroy(path);
} else {
      path_start(path, pathspd, 0, false);
}

And like I said before possibly verify the grid looks the same on Windows and HTML, just print out the grid quickly and see that they match.

var cellwidth = 16;
var cellheight = 16;
var hcells = room_width div cellwidth;
var vcells = room_height div cellheight;
global.grid = mp_grid_create(0, 0, hcells, vcells, cellwidth, cellheight);
//Add the things to avoid
mp_grid_add_instances(global.grid, wallmid1_object, false);

//Print out the grid

for (var _j = 0; _j < vcells, _j++) {
    for (var _i = 0; _i < hcells, _i++) {
        show_debug_message(string(_i) + ":" + string(_j) + "=" + string(mp_grid_get_cell(global.grid, _i, _j)));
    }
}

There is going to be a difference somewhere. Maybe it is internal in mp_grid_path and you can't do much about it... but check everything else as well.

 

[solarcrispz]

Right but it is mp_grid_path function that is throwing the error based on mx, my.

Put a mp_grid_get_cell before that and test that your end position is not blocked https://docs2.yoyogames.com/source/_build/3_scripting/4_gml_reference/movement and collisions/motion planning/mp_grid_get_cell.html

Something like:

var _pathSuccess = false;
// Test first that end position is not blocked
if (mp_grid_get_cell(global.grid, mx, my) == -1) {
  // something is wrong
  show_debug_message("Something wrong: " + string(mx) +  "  " + string(my));
} else {
     // If you still get here then there probably is something wrong with mp_grid_path on HTML
     _pathSucess = mp_grid_path(global.grid, path, x,  y, mx, my, 1);
}

if (!_pathSuccess) {
    path_destroy(path);
} else {
      path_start(path, pathspd, 0, false);
}

And like I said before possibly verify the grid looks the same on Windows and HTML, just print out the grid quickly and see that they match.

var cellwidth = 16;
var cellheight = 16;
var hcells = room_width div cellwidth;
var vcells = room_height div cellheight;
global.grid = mp_grid_create(0, 0, hcells, vcells, cellwidth, cellheight);
//Add the things to avoid
mp_grid_add_instances(global.grid, wallmid1_object, false);

//Print out the grid

for (var _j = 0; _j < vcells, _j++) {
    for (var _i = 0; _i < hcells, _i++) {
        show_debug_message(string(_i) + ":" + string(_j) + "=" + string(mp_grid_get_cell(global.grid, _i, _j)));
    }
}

There is going to be a difference somewhere. Maybe it is internal in mp_grid_path and you can't do much about it... but check everything else as well.

Thank you. I'll implement what you've suggested and report back tomorrow.

 

[solarcrispz]

Well Roldy it looks like I *may* have fixed the problem thanks to your help.
I tried printing out the grid like you said, noting the number of occupied / unoccupied spaces. The count was identical for both client and browser versions.
This would indeed imply (but not confirm) that mp_grid_path is not a sufficient check for initiating paths on HTML.
Enemies don't like STARTING or ENDING paths in occupied spaces, resulting in a crash. So, I had to implement your above fix and customize it to suit my some of my game quirks:

var mx = (nearestplayer.x div 16);
var my = (nearestplayer.y div 16);

if path_exists(path){
    path_delete(path);
}
path = path_add();

//check for BOTH where the enemy ends the path (player's grid location) and the enemy's start location (their grid location)
var _pathSuccess = 0;
if (mp_grid_get_cell(global.grid, mx, my) == 0) && (mp_grid_get_cell(global.grid, x div 16, y div 16) == 0){
    _pathSuccess = mp_grid_path(global.grid, path, x,  y, nearestplayer.x, nearestplayer.y, 1);
}

if _pathSuccess{ //shoutsout to Roldy
    path_start(path, pathspd, path_action_reverse, false);
}
else{ //if end or start are blocked
    path_delete(path); //you can actually put any action here, personally I've put a move_towards_player on the event the player is close to the enemy anyway
}

I'm PRAYING above works in the long run. I'm making a multiplayer browser and client game so if one person triggers the crash glitch ALL client players will crash (enemies all path find client-side).
Thanks again Roldy. I'll post here if something goes wrong, but it seems for now you helped me zero-in on an effective (albeit inefficient to only the fault of the HTML port) solution!