Bug/Error Reports

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

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.

bluesun said:
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.
 
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

mRKSGlH.png

to looking like this

EzgGzmZ.png

DL Link of the original map
 
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.
 
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.

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:
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?
 
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 :eek:. 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.
 
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 :eek: . 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)...
 
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)...

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:
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)];
};
 
First post here, thanks for working on PartyPlanner64! I'm having a great time learning how to design boards and etc. Quick side-note which is probably something I'm doing wrong, the roms produced with PartyPlanner64 work fine in Mupen64Plus, but not the latest version of Project 64. Any ideas? Thanks!

Edit: I should have read the Readme which stated the memory needed to be set to 8 mb :p
 
My Mario Party 2 Banjo Kazooie map is still crashing everytime it loads up the Tipsy Tourney mini-game. It's happening on hardware and emulator.  :-\
 
I'm actually having a similar issue as some of the folks above with both Mario Party 2 and 3 running on an actual N64 (Everdrive). On occasion the game will lock up randomly during play (usually on the board sections). The funny thing is, it doesn't just happen on the custom boards, but I was playing a normal game on Pirate Land in Mario Party 2 and it froze after a few turns as well.

I'm guessing for whatever reason the N64 or Everdrive just has issues running the altered ROM file?

Oddly enough, the games run just fine on N64 emulators (specifically Not64).
 
Hey Guys, I just experienced an issue, and I don't find any answer / help. I downloaded a custom map, provided by this site, and tryed it out on my own MP3. It works, but the screen is always flickering while the characters are moving. Can someone please help? ???

The standard rom does work pretty well, but not with the custom map inbound in it.

Greets :D
 
That's a bug with the current version. For now you have to do it by trial and error by offsetting the spaces to get the look you want.

https://github.com/PartyPlanner64/PartyPlanner64/issues/20
 
Back
Top