On two different custom boards in MP3, I've had the game freeze partway through a game after rolling the die. If it matters, I was controlling all four players with one controller.
MG03 said:Just some problems I've run into, all of these have been on netplay with mupen64++, some of these have been noted before:
-In MP2 the game will freeze on a black screen right before Hexagon Heat and Tipsy Tourney, haven't had any problems with any other games
-In MP3 the CPUs will get stuck at branching paths and not do anything
bluesun said:Bowser Bomb or Bowser's Appearing Act (After Bowser rolled three dice)
Spinda said:So to get used to the program I decided to start off by making an injokey MP2 map (so dont mind the general badness) and everything works except when I overwrite a map it goes from looking like this
PartyPlanner64 said:Spinda said:So to get used to the program I decided to start off by making an injokey MP2 map (so dont mind the general badness) and everything works except when I overwrite a map it goes from looking like this
The issue that is mostly tracking this is here:
https://github.com/PartyPlanner64/PartyPlanner64/issues/20
But how the editor parses boards that have already been written is overall a lower concern, because what really matters is how the game actually plays.
The space alignment issue in-game is probably the most annoying bug right now, and the one I want fixed the most, but it's a huge bore just to think about it. It's really daunting to try to solve it in a reasonable way, and very time consuming to solve in a bruteforce way.
onGetBoardCoordsFromGameCoords(x, y, z, width, height, boardIndex) {
// The following is a bunch of crappy approximations.
let newX, newY, newZ;
switch (boardIndex) {
case 0: // DK's Jungle Adventure
newX = (width / 2) + (x * (1 + (y * 0.13 / (height / 2))))
+ 30 * (x / (width / 2));
newY = (height / 2) + ((y + 0) * 0.90);
if (newY < (height / 2))
newY += Math.abs(y) / 10;
else
newY += Math.abs(y) / 40;
newZ = 0;
break;
case 1: // Peach's Birthday Cake
case 2: // Yoshi's Tropical Island
case 3: // Wario's Battle Canyon
case 4: // Luigi's Engine Room
case 5: // Mario's Rainbow Castle
case 6: // Bowser's Magma Mountain
case 7: // Eternal Star
case 8: // Training
case 9: // Mini-Game Stadium
case 10: // Mini-Game Island
newX = (width / 2) + x;
newY = (height / 2) + y;
newZ = 0;
break;
default:
throw "onGetBoardCoordsFromGameCoords called with bad boardIndex";
}
Dark Boo said:Can you explain the significance of these values:
0.13 (Setting the newX variable)
0.90 (Setting the newY variable)
(And the condition where if the newY variable is greater than half the height (On the higher half-plane)
I would like to know how you got those approximations because they seem to work for the interior of the boards but for the exterior, they become WAY off...
I probably know this, but onGetBoardCoordsFromGameCoords and onGetGameCoordsFromBoardCoords are simply inverse functions, correct? And boardCoords from gameCoords is getting the coordinates from the actual game where gameCoords from boardCoords get the coordinates from the editor board?
newX = (width / 2) + x;
newY = (height / 2) + y;
newZ = 0;
PartyPlanner64 said:Dark Boo said:Can you explain the significance of these values:
0.13 (Setting the newX variable)
0.90 (Setting the newY variable)
(And the condition where if the newY variable is greater than half the height (On the higher half-plane)
I would like to know how you got those approximations because they seem to work for the interior of the boards but for the exterior, they become WAY off...
I probably know this, but onGetBoardCoordsFromGameCoords and onGetGameCoordsFromBoardCoords are simply inverse functions, correct? And boardCoords from gameCoords is getting the coordinates from the actual game where gameCoords from boardCoords get the coordinates from the editor board?
There really is no rhyme or reason to any of the numbers in those functions.
The minimum conversion required is the following, which is needed because the coordinates are stored differently in the game vs in the editor. In the game, X and Y are zero at the center of the board, and they grow outward. I wanted the editor to start X and Y at 0 in the upper left corner. So that's what I use right now for every board but DK right now for example.
Code:newX = (width / 2) + x; newY = (height / 2) + y; newZ = 0;
From there I just kept messing with it until it reached what it is today . I would tweak it and reload the ROM and see how close it made the spaces line up with an image of the board.
The overall idea is that X needs to shrink inwards at the top and expand outwards at the bottom. Y probably has some scaling involved. I'm sure there is some sort of mathematical thing that could help, like a transformation matrix or some perspective math. The truth of it lies in the ROM somewhere.
You're correct that the one should be an inverse of the other, one for parsing and one for overwriting. They areprobablynot true inverses. I just ran them through Wolfram Alpha when I was done.
Dark Boo said:Would you mind if I take a look at this please? I will TRY to see the kinks of it (Hopefully whenever I have free time MINUS work)...
PP64.adapters.MP1.onGetBoardCoordsFromGameCoords = function(x, y, z, width, height, boardIndex) {
let newX, newY, newZ;
newX = (width / 2) + x;
newY = (height / 2) + y;
newZ = 0;
return [Math.round(newX), Math.round(newY), Math.round(newZ)];
};