Journey Map Issue Tracker
TeamJM/journeymap#399

@gigaherz What do you need on my end for this?

@mysticdrew If people want cross-compatibility, two things could happen:

1. Journeymap could detect the presence of Hud Compass and choose to implement the waypoint & renderer, so it can add the waypoints to it if it's configured to do so, or
2. I could implement compatibility in my end, by implementing the waypoint & renderer myself.

I'm willing to do option 2, but I don't have the time to learn how all the internals work so I can design and PR an API for it. The features I would need are:

• Some API to list waypoints per dimension, with at least their position, title, and whether or not they are hidden, but also any other value the client might need in order to invoke the rendering.
• Some API to render a waypoint, that I can invoke every frame if the waypoint is visible on the compass.
• Optionally but would be nice for performance: it would be helpful if there was a callback/event thing so I could get notified of when waypoints are added/removed (and potentially modifications too if retreieving the info is non-trivial).

I don't know if Journeymap currently has any such API. I couldn't find any 2 years ago when I was working on the mod but I haven't kept track.

And just in case anyone thinks about this: no, accessing the internals directly is not an option. There's no expectation of the internals remaining binary-compatible. I already tried with another mod and it kept breaking every couple months. I don't have the time or interest to chase after someone's internal implementation.

We have a plugin style API that has some waypoint functionality.
https://github.com/TeamJM/journeymap-api

However, our API does not have a way to get all waypoints, only those created by the mod implementing the api. I will look at adding a way to get all waypoints as it has been requested in the past.

I will add a waypoint crud event and a way to get all waypoints.
You can create your own waypoints via our api and we will render them already, let me know if that does not fulfil the second bullet point.

Our documentation is a bit out of date, but you can use the example mod in the api for implementation details as I have tried to keep that up to date with new features.

To add the api to your project, here are the following this to add to your build.gradle
repo:
https://github.com/TeamJM/journeymap-additions/blob/c5dd2fc2f62771dcab5803c7203a6e67adfb493b/build.gradle#L80
and dependency:
https://github.com/TeamJM/journeymap-additions/blob/c5dd2fc2f62771dcab5803c7203a6e67adfb493b/build.gradle#L95

You can create your own waypoints via our api and we will render them already, let me know if that does not fulfil the second bullet point.

I meant so I can render your waypoints in my compass (the icons for them, that is), as they would appear on the minimap), so no that doesn't fulfill it. ;P

I'll take a look but I think that's what I already saw, which is a one-way api in the wrong direction from what I needed.

I'll take a look but I think that's what I already saw, which is a one-way api in the wrong direction from what I needed.

Ahh okay, I thought you meant your waypoints to render via JM. Yea, the getAllWaypoints or what ever I call it, each waypoint will have a getter for getting the icon.

So 5.8.0Beta17 when I release it for 1.18.2, 1.18.1, 1.17.1, and 1.16.5 will contain some new waypoint accessors and events.
In IClientAPI these methods for getting waypoints.
https://github.com/TeamJM/journeymap-api/blob/f96149575850c073e75c7be4be1814e5ede8ee86/src/main/java/journeymap/client/api/IClientAPI.java#L218-L249

List<Waypoint> getAllWaypoints(); // gets all waypoints loaded into memory
List<Waypoint> getAllWaypoints(ResourceKey<Level> dim); // all waypoints for a specific dimension
Waypoint getWaypoint(final String modId, final String displayId); // specific waypoint from a mod with a the provided id.
List<Waypoint> getWaypoints(final String modId); // all waypoints from a mod. 

https://github.com/TeamJM/journeymap-api/blob/f96149575850c073e75c7be4be1814e5ede8ee86/src/main/java/journeymap/client/api/event/WaypointEvent.java#L6
I am adding Waypoint Create/Read/Update/Delete events. These are not forge events, they are our ClientEvent. So you will need to register to the Waypoint event type in your plugin.

I am a bit reluctant to add a waypoint render event that fires every frame due to possible performance issues. You can get the icon ResourceLocation from the getWaypoint|s methods.

Nice! I'll take a look whenever I have time.

5.8.0beta17 is on curseforge now. Let me know if there are issues or you need more hooks.
Api 1.8 for mc1.18.1 works just fine with mc1.18.2 projects.

Was a bit awkward to make the two APIs fit, but I think I managed.

I still have to do some more testing before I publish. And add configs to disable the integration.

Very nice!

Was a bit awkward to make the two APIs fit, but I think I managed.

I still have to do some more testing before I publish. And add configs to disable the integration.

Is this for versions 1.16 - 1.18? and has this update been released to curseforge yet, if not when?
and thank you both for making it possible :D

No this hasn't been released yet.

I have been trying to figure out an issue where when I modify waypoints sometimes the textures become garbled.

and the log fills up with

[15:48:00] [Render thread/INFO] [mojang/GlDebug]: OpenGL debug message: id=1282, source=API, type=ERROR, severity=HIGH, message='GL_INVALID_OPERATION error generated. Texture name does not refer to a texture object generated by OpenGL.'

which strongly points at something freeing the texture location while the waypoint still exists,

No this hasn't been released yet.

I have been trying to figure out an issue where when I modify waypoints sometimes the textures become garbled.

and the log fills up with

[15:48:00] [Render thread/INFO] [mojang/GlDebug]: OpenGL debug message: id=1282, source=API, type=ERROR, severity=HIGH, message='GL_INVALID_OPERATION error generated. Texture name does not refer to a texture object generated by OpenGL.'

which strongly points at something freeing the texture location while the waypoint still exists,

Are those journeymap icons getting garbled? Those textures should not get freed from the texturemanager unless maybe the waypoint is deleted, even then they shouldn't since they are reused.

Edit:
Actually nevermind, that wouldnt matter. As that has nothing to do with binding them to opengl. Which is what this error is referring to.

Are those journeymap icons getting garbled? Those textures should not get freed from the texturemanager unless maybe the waypoint is deleted, even then they shouldn't since they are reused.

maybe the waypoint is deleted

deleted

OH CRAP, my logic is wrong.

EDIT: Fixing the logic didn't fix the issue, but it was still wrong.

I can't see any explicit issue with my logic. All I can think of points at Journeymap "fake:xxx" textures getting the wrong opengl texture ID.

Eg. right now, it's not erroring, but those waypoints, Using info read directly from Journeymap waypoints MapIcon data, gives me vanilla entity textures instead:

But it's not like Journeymap itself is wrong? and leaving the save and entering it again doesn't help, so it's not my mod caching old objects ........

If it's of any relevance:

            if (!data.jmwp.hasIcon())
                return;

            var m = data.jmwp.getIcon();
            var tex = m.getImageLocation();
            if (tex != null)
            {
                var w = m.getDisplayWidth();
                var h = m.getDisplayHeight();

                RenderSystem.setShaderTexture(0, tex);
                RenderSystem.setShaderColor(1.0F, 1.0F, 1.0F, alpha / 255.0f);

                blit(matrixStack, (float) (x - w / 2), (float) (y - h / 2), (float) w, (float) h,
                        m.getTextureX(), m.getTextureY(), m.getTextureWidth(), m.getTextureHeight(), m.getTextureWidth(), m.getTextureHeight());
            }

The baffling thing is that it works when the game starts, then breaks when leaving the big map screen after editing waypoints...

I do wish the mod was opensource so I could step through the code.

here's an example of it happening: https://streamable.com/ec2of4

I wonder if it's an issue specific to the 1.18.2 version. maybe I'll try to backport to 1.16 and see if it happens there...

ADDENDUM: if I hide a waypoint, and show it again, the glitch disappears. but leaving the save and opening it again, does not fix it.

setShaderTexture is supposed to take care of binding & loading as needed... I have never seen any issue like that before, when calling that method in 1.17+

I wish it was open source too, but I cannot open source it as I don't own the license.
Looks like you may need to bind that texture.

this issue looks slightly stale, but it looks like the best place to report my experience on 1.18.2 ( journeymap-1.18.2-5.9.0-forge.jar, HudCompass-1.18.2-0.5.3.jar) :

right now for me the waypoint textures are fine, but editing waypoints leaves a stale waypoint in hudcompass that doesn't get removed until i restart the session. example: if i quickly put down a waypoint with some placeholder like asdf in a location (such as while trying to find amethyst geodes using an ars nouveau dowsing rod), then later edit the Y level and name to correctly match, hud compass will continue to have the old name and position as well as the new name and position. for disparate y values, this will show as things like the waypoint up and down arrows boy showing on the icon (so the waypoint is now simultaneously above and below me).

this also comes up with waystone waypoints, where i will sometimes end up changing the randomized name for a worldgen waystone, and frequently hud compass will show the old name when i'm looking on either the left or right edge of the waypoint depending on viewing angle (which is particularly interesting since the position is unchanged; i'm not sure how it could show the old one so very slightly offset.)