Both halves of this are real, and they have the same root.

"On the Way to the Harbor" is one of the maps that has no minimap picture in the original v83 game files at all — the real client just shows the thin minimap bar there. Our version was pulling a substitute picture off the art server instead, and that substitute is drawn at a completely different scale and offset from the one the marker maths expects. With no real minimap data to work from, the game fell back to a generic placeholder centre point, so the player dot and the portal dots were computed way outside the picture and then clamped to its edge. That's why the dot sits buried in the dirt and never moves up when you stand on a higher platform.

The portal complaint is a second, separate bug. In real v83 only one kind of portal gets a marker on the minimap — the blue "proper" doorway type. This map has exactly one of those (the one to Nautilus, over on the far left), and we were drawing markers for two different portals instead while putting the Nautilus one in the wrong spot. So the marker you were looking for genuinely wasn't where it should be.

Fixes: when a map has no real minimap data we now show the small bar, exactly like the original client, instead of guessing coordinates over a borrowed picture; and portal markers are now restricted to the correct portal type. Thanks — the "player doesn't rise" detail is what pinned this down.

Reproduced and diagnosed, but this one can't be fixed safely in code alone — it needs map data. "On the Way to the Harbor" (map 120010000) genuinely has NO minimap in v83: the map has no miniMap node at all, so the real client would show only the slim minimap title bar, no picture. Our map renderer asks the art server for a minimap picture anyway and gets one from a much later version of MapleStory. Because the map carries no minimap coordinates, the marker maths falls back to hard-coded placeholder numbers (centerX 1338, centerY 635) that belong to some other map — which is why your dot and the portal rings are shoved down into the dirt instead of standing on the ground. The proper fix is two steps, in this order: (1) re-extract the miniMap node into the map bundles for the 52 maps that lost it (see report 202 — Free Market rooms and both party quests), then (2) change MiniMap.create so `forcedMin` keys off the ABSENCE of the authentic miniMap node (authCanvas) instead of off the image failing to load, so maps like this one show the MIN bar and never render a foreign minimap picture. Doing step 2 first would blank the minimap in the Free Market and in Kerning/Ludibrium PQ, so I'm not shipping it as a code-only patch.

Fixed — and it is the same underlying problem as the Free Market minimap report, from the other side.

'On the Way to the Harbor' genuinely has NO minimap in the original v83 game; the real client just shows the thin minimap bar there. We were drawing dots anyway, because our minimap picture is fetched per-map from a third-party art service which hands back a SUBSTITUTE image at a completely different scale and offset. Because an image existed, the 'this map has no minimap' path never triggered, and the dots were positioned using a placeholder centre over borrowed artwork — landing outside the picture and clamping to its edge. That is why your dot sat buried in the dirt and never moved up when you climbed.

It now decides on whether v83 actually gives the map a centre point, not on whether some image happened to load. 1,231 maps fall in that category and will show the slim bar, exactly like the original client.

Your portal observation was a separate real bug and stays recorded above.