You are using an out of date browser. It may not display this or other websites correctly.

You should upgrade or use an alternative browser.

You should upgrade or use an alternative browser.

- Thread starter SuperZambezi
- Start date

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

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

to looking like this

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

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

You actually can save in mid-turn and that's so weird!

I restarted because I picked the wrong way for exemple and restarted at the split and got thrown back to the beginning of the board

That is such an odd glitch!!

Edit: I should have read the Readme which stated the memory needed to be set to 8 mb

Here's the map, does anyone know what's wrong? It's for Mario Party 2.

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

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

Greets

Have you tried using a different video plugin in your emulator?

I came here tho edit my recent post as solved ^^

I just solved it by "luck".

Yes this was what i needed.

Thank you

When I save my custom rom, it shifts all the spaces and paths down by like 10%, and the paths/spaces move off the screen.. how do I avoid this? The game still works, just party planner cuts off the bottom in the editor