Bug/Error Reports

[MarioComix]

Alright, here's my issue. Let me begin...

I'm currently using Project 64 to emulate MP2, which opens its .n64 file fine. Is Project 64 a good emulator for the custom boards though? Because when I use it to open a .z64 file (which is what Party Planner saves its ROMs as, after overwriting with a custom board), it doesn't work. Any suggestions for solutions?

Also, when I reopen these .z64 files in Party Planner, all the MP2 boards are re-listed as being for MP1, even though they have the right spaces. What's the work-around for that?

[NintendoFan]

You just need to find an original MP2 rom in the .z64 file format. I can't link it here, because, well, piracy issues. You should be able to find one via some google searching.

You should also be sure that the default memory size is set to 8 MB, otherwise the game won't run either way.

[PartyPlanner64]

It may be the case that an emulator cannot handle .z64 format (which is the real deal format IMO) but PP64 was written to be able to read .n64 and other endian varieties, although I haven't tested it much.

all the MP2 boards are re-listed as being for MP1, even though they have the right spaces.

I wasn't sure what this meant, which part of the editor is listing something wrong?

[Spongyoshi]

Here are two errors I noticed by now.
- In Mario Party 2, there's a lava-based minigame (dunno which one) that usually crash the game.
- In Mario Party 3, when the AI goes on a intersection point, the game have a chance of crashing.
Except that, it's pretty good  (Besides the AI sucks but that can hardly be helped..)

[MarioComix]

It may be the case that an emulator cannot handle .z64 format (which is the real deal format IMO) but PP64 was written to be able to read .n64 and other endian varieties, although I haven't tested it much.

all the MP2 boards are re-listed as being for MP1, even though they have the right spaces.

I wasn't sure what this meant, which part of the editor is listing something wrong?

I can't quite replicate what happened, but when I clicked the "Overwrite" button, and those little ! icons pop up to say what's wrong with the board, there would be a red ! saying it's a board for MP1, despite the MP2 ROM, as well as the board actually being in MP2. But I can't seem to replicate it anymore.

[RandomPG]

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]

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]

MP2 (Mupen64++): Hexagon Heat, Tipsy Tourney. Bowser Bomb or Bowser's Appearing Act (After Bowser rolled three dice)

[PartyPlanner64]

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

The MP3 computer players should no longer get stuck with tonight's changes.

I also believe I have fixed at least one of the MP2 mini-game crashes, although I have not verified it myself.

Bowser Bomb or Bowser's Appearing Act (After Bowser rolled three dice)

I had not heard about this before, I will try to look into it. The fix may be similar to what I did for MP3 to fix some items.

[Spinda]

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

Spoiler (click to show/hide)

to looking like this

Spoiler (click to show/hide)

DL Link of the original map

[PartyPlanner64]

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.

[Dark Boo]

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.

Is there a set formula for going from XY to XYZ plane?


EDIT:
Viewing your code

EDIT X2:
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)

Code: [Select]

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";
}
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...

EDIT X3:
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?

[PartyPlanner64]

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: [Select]

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 are probably not true inverses. I just ran them through Wolfram Alpha when I was done.

[Dark Boo]

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: [Select]

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 are probably not true inverses. I just ran them through Wolfram Alpha when I was done.

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)...

[PartyPlanner64]

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)...

Please do!

While I think it would be best to try and get everything set up like the Github README suggests, you could also patch the function live in the browser to see changes.

Pressing F12, you could paste this in the console for example, and all boards, even DK, would parse without perspective changes. It will wear off when refreshing the page, but you can also just keep changing it and close/open ROM to see the effects.

Code: [Select]

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)];
};