An error at v1.6.0 saying that minimap is not found. extremely harmless, will not break your game, so don't worry, it's just a logging error.
If you've updated to v1.5.2, you can ignore this message. Under the Radar is not fully compatible (another oversight on my end) if pins don't disappear when searching, reenable my mod (but will happen again when going far from a pin made by both my mod and under the radar's temporary pins
If you've started at v1.5.1, you can ignore this message. Do not modify Object IDs for now, but instead delete and create a new entry. I've made some oversights at v1.3.0 that breaks it. (if ever you do attempt it, reload your tracked objects by relogging or pressing the reload key).
If you've started at v1.3.0, you can ignore this message. For the people out there who has set some entries with blacklist words and updated from 1.2.2 to 1.3.0, even if the blacklist word is filled, it will not work, so I advise you all to click modify at least once with each entries with Blacklist words fillled as I accidentally broke it by changing the variable name.
Sadly nope :/ That is the limitation that I mentioned in the past. If I made those trackable, you'd be able to track auras such as the heat dome of torches, campfires, and other auras like light. If it was enabled, this would lead to not being able to track most of the objects you want. Surtlling Spawners are considered as aura and has no physical object that you can track.
haha, thanks, it was honestly a mod for me as well who likes to track all the things, but I lost the motivation to play Valheim once more after developing it, ironic.
It would be really useful if tags for portals updated with the name of the portal once the portal's name changed. Huge quality of life improvement there :)
Basically to make the Track Object UI pre-fill the data, you must be looking at an ore that's not struck with a pickaxe (tin/obsidian excluded) You will know if the ore is invalid if it's saying "Invalid" on the object id, that's a clear indicator that you need to find an ore that's undamaged.
There's some mod limitation that's going to be extra work if I made it work on a damaged ore, but I figured I would just skip it as it works normally on an undamaged ore.
There a small pin frustration that I wish could be resolved, but I'm unsure if it's possible without use of more code than it's worth. Currently, if the player manually creates a pin in the same location that Pin Assistant will also create one, then the two pins confusingly overlap. Most often it involves a "home base" pin that I need to create in the same location as a Troll Cave or Crypt; since I've created a rule for Pin Assistant to always pin those when visited, those pins fight for attention with my manually created pins. I can't simply remove the Pin Assistant pin, since the next time that I visit the pin will be recreated according to the rule. (I disable the building restriction for those locations.)
What I would of course like to happen is that Pin Assistant somehow notices my pin and removes or doesn't create a pin in the same location. I've been trying to work around it by creating my pins always just above those created by Pin Assistant and/or Under The Radar.
Is there a low-impact means to detect another persistent pin in the same location and not display or create another pin that would compete?
odd, I was sure that I made it so it's impossible to pin the same location twice and Pin Assistant will ignore any subsequent pin on that location. Hence why automatic pinning isn't constantly pinning the same object more than twice.
Altho I made the exception on Under the Radar's temporary pins.
Sorry, but can you expound it a bit more? When you say "play manually creates a pin in the same location" are you using a mod or just your own double click to create. What do you mean by confusingly overlap?
The latter, double-clicking to create, is what I meant by "manually creates". "Confusingly overlap" describes the visual result if I attempt to do this in a location that Pin Assistant (or another mod) has already targeted for pin creation, either now or in the future. In the case of Pin Assistant, a rule for an object like a Crypt ensures that it will continue to "confusingly overlap" the next time that I visit even if I explicitly remove the pin that was already created by the rule; there is no means to create exceptions to a rule for specific locations of any given object. I've been trying to compensate by offsetting my manually created pins, but it's a compromise between offsetting far enough to be readable an any magnification and being close enough to the intended location to still be useful.
I'm just restating things, but semantics so often matter to understanding.
ahhh, I understand your point now, basically manual pin creation and pin assistant hot pin/auto pin, would conflict cause if manual pin is too close to a prior or potential object PinAssistant have/will pin, it will create regardless.
So what you need is a different kind of pin redundancy where Pin Assistant will not pin when there's a nearby random pin. As the mod's redundancy pin only accounts for pins with similar name.
I can do something about it by adding another type of redundancy pin distance but for random pins this time.
For now a workaround is to name the manual pin the same with PinAssistant's tracked object pin name (I accidentally made it case sensitive so be sure to consider that as well)
ex. you manually pinned with the name Dungeon | Track Object 1 -> Pin Name: Dungeon, Object ID: Crypt PinAssistant will avoid pinning the crypt if it's nearby with your manual pin.
I'm looking forward to a solution you can conceive. If I rename the pins the same or similar, then they lose their ability to descriptively mark the location for my purpose (portals, mostly). I've been trying to move my pins just above the Pin Assistant pins, but at some map magnifications they'll still overlap and be confusing to read. I might try relocating my pins just below the Pin Assistant ones with the goal of leaving both readable and shorten mine, e.g.:
Crypt Portal nn
as opposed to
Crypt Portal nn Crypt
But having not to worry about the overlap at all would be much better.
Would really like to work on an update to solve this and fix the annoying fake error at the very beginning of the game. but I'm still working on my programming commission which will take around 2 months or so, maybe when I take a break from the work, I'll think about updating this mod.
Well, I'm almost going to release the next update to add your suggestion and some other QoL, looks like everything is in order, so I might just release without player base test.
It may take me a while to weaken my obsession with BG3 and get back to Valheim, but when I do I will certainly be candid if I think of anything interesting. Candid has no off switch for me. :-)
Hey. I got a suggestion for an added feature if you are interested. The ability with a keypress to place a pin at your current location to pin something exactly while on the move (In case of enemies or something similar)
I know its update day, but with game update I get [Error :WxAxW.PinAssistant.Utils.Debug] Minimap not found, this should not happen unless Debug Mode is enabled while in main menu
yeah, ignore that, I made a mistake when logging errors, it's a harmless one, it's actually supposed to be a warning as well, but I fixed it in the next patch.
This specific issue, at least, is still an issue. Mushrooms and magecap and perhaps others get confused.
Also, it will create pins for items inside dungeons, notably mushrooms. We KNOW they're in there and don't need to have extra pin congestion around crypts to remind us.
Yes, I'm careful to pay attention to the state of Exact Match.
I have a bigger problem now: I experimented with the addition of the mod Under The Radar, and it seems that it overrides PinAssistant and prevents it from auto-adding pins. I don't know why that would be, since they don't seem to have identical purpose. I had hoped that PinAssistant could manage the creation of permanent pins for some objects and then allow Under The Radar to create temporary pins for other nearby objects that don't need to have permanent pins. I substantially reduced the number of automatic pins, but even what's left don't get generated.
--edit-- On first assumption it may be that under the radar's temporary pins are counted as permanent pins, but removes it after being away. which is probably a way to efficiently cache them. Meaning I'll have to make some compatibilities for it. Should be possible by just ignoring Under the Radar's "temporary pins". since my mod adds all pins created by Valheim and other mods, to avoid overlapping pins, but in this case, seems like an exception has to be made.
Although, again, on first assumption, what may happen is that temporary pins and permanent pins might overlap (when I do the compatibility patch). Unless their mod has a detection if a nearby pin exists near an object. --end edit--
also the magecap and mushroom (plus other mushroom related things) I can't seem to replicate it.
I can only replicate the issue if I track "Pickable_Mushroom(Clone)" and then not set it to "Exact ID Match". which would lead to magecap, yellow, blue, and jotun puffs, be pinned.
--another edit-- made an update that fixes both the issues you've found.
I have a few issues with the mod. I am not able to make it pin certain things. It works with crypts and boar runestones, but it won't work for copper veins, beehives or portals. I have tried several IDs for all of them, and I don't know what is wrong. If I try to track them while looking at them, it ends up blank, as opposed to boar runestones that have it prefilled.
I never added the ability to track portals, unsure about beehives (natural / manmade) but if it's not prefilling that means it's not in the possible trackable types, I can make an option for it in the next update. Reason that I ignored other types was to save up some processing (albeit negligible) as I initially made this mod before I had the option to disable auto pinning, so it was trying to look for all possible types, different object layers, etc. every x tick rate. Although now that I've made config options for disabling autopin and choosing the necessary types you want to detect, I can add other types now.
Nice. Sorry I forgot to respond to you. I got it working after disabling and reenabling Destructibles and MineRock. And when you say almost anything... How crazy can I go I wonder... Hahaha. Gonna have fun testing it now.
Enjoy! this version is much more efficient at finding things compared to type searching, which was the reason why I made some stuff optional to not be performance impacting even if it's negligible.
Mod looks great, would like to use it - your installation instructions are not exactly clear with regards to the json.net framework that needs to be installed.
Do you just drag and drop this into your plugins folder, as you would normally for any other mod? So you will have in your bepinex folder, JOTUNN, the dll for auto map pins and the json.net dll's too?
Sorry just not clear, your installation instructions do not match the mod requirements, I guess it assumes you already have the json.net framework installed.
right, forgot that I had dependencies, sorry., yes that's correct, json.net should have its own .dll files you just put those in the plugins folder as well, either in another folder called "jsondotnet" or something or just leave the .dll in the plugins folder.
note: looks like the json.net zip file has "plugins" folder in it, just merge them both and it should be good to go.
54 comments
extremely harmless, will not break your game, so don't worry, it's just a logging error.
If you've updated to v1.5.2, you can ignore this message.
Under the Radar is not fully compatible (another oversight on my end)
if pins don't disappear when searching, reenable my mod (but will happen again when going far from a pin made by both my mod and under the radar's temporary pins
If you've started at v1.5.1, you can ignore this message.
Do not modify Object IDs for now, but instead delete and create a new entry. I've made some oversights at v1.3.0 that breaks it. (if ever you do attempt it, reload your tracked objects by relogging or pressing the reload key).
If you've started at v1.3.0, you can ignore this message.
For the people out there who has set some entries with blacklist words and updated from 1.2.2 to 1.3.0, even if the blacklist word is filled, it will not work, so I advise you all to click modify at least once with each entries with Blacklist words fillled as I accidentally broke it by changing the variable name.
That is the limitation that I mentioned in the past. If I made those trackable, you'd be able to track auras such as the heat dome of torches, campfires, and other auras like light. If it was enabled, this would lead to not being able to track most of the objects you want.
Surtlling Spawners are considered as aura and has no physical object that you can track.
When I plan on working on an update, I'll be sure to add it in.
You will know if the ore is invalid if it's saying "Invalid" on the object id, that's a clear indicator that you need to find an ore that's undamaged.
There's some mod limitation that's going to be extra work if I made it work on a damaged ore, but I figured I would just skip it as it works normally on an undamaged ore.
What I would of course like to happen is that Pin Assistant somehow notices my pin and removes or doesn't create a pin in the same location. I've been trying to work around it by creating my pins always just above those created by Pin Assistant and/or Under The Radar.
Is there a low-impact means to detect another persistent pin in the same location and not display or create another pin that would compete?
Altho I made the exception on Under the Radar's temporary pins.
Sorry, but can you expound it a bit more? When you say "play manually creates a pin in the same location" are you using a mod or just your own double click to create. What do you mean by confusingly overlap?
I'm just restating things, but semantics so often matter to understanding.
So what you need is a different kind of pin redundancy where Pin Assistant will not pin when there's a nearby random pin. As the mod's redundancy pin only accounts for pins with similar name.
I can do something about it by adding another type of redundancy pin distance but for random pins this time.
For now a workaround is to name the manual pin the same with PinAssistant's tracked object pin name (I accidentally made it case sensitive so be sure to consider that as well)
ex. you manually pinned with the name Dungeon | Track Object 1 -> Pin Name: Dungeon, Object ID: Crypt
PinAssistant will avoid pinning the crypt if it's nearby with your manual pin.
Crypt
Portal nn
as opposed to
Crypt Portal nn
Crypt
But having not to worry about the overlap at all would be much better.
but I'm still working on my programming commission which will take around 2 months or so, maybe when I take a break from the work, I'll think about updating this mod.
Thank you !!
If I'd said "keep up the good work" I'd feel like I was exploiting you.
Instead I thank You for Your commitment.
I can't wait to see what will this mod become and what other marvels will you create.
I'll work on it next time, maybe starting December.
This specific issue, at least, is still an issue. Mushrooms and magecap and perhaps others get confused.
Also, it will create pins for items inside dungeons, notably mushrooms. We KNOW they're in there and don't need to have extra pin congestion around crypts to remind us.
I have a bigger problem now: I experimented with the addition of the mod Under The Radar, and it seems that it overrides PinAssistant and prevents it from auto-adding pins. I don't know why that would be, since they don't seem to have identical purpose. I had hoped that PinAssistant could manage the creation of permanent pins for some objects and then allow Under The Radar to create temporary pins for other nearby objects that don't need to have permanent pins. I substantially reduced the number of automatic pins, but even what's left don't get generated.
Do you suppose that can be worked out?
--edit--
On first assumption it may be that under the radar's temporary pins are counted as permanent pins, but removes it after being away. which is probably a way to efficiently cache them. Meaning I'll have to make some compatibilities for it. Should be possible by just ignoring Under the Radar's "temporary pins". since my mod adds all pins created by Valheim and other mods, to avoid overlapping pins, but in this case, seems like an exception has to be made.
Although, again, on first assumption, what may happen is that temporary pins and permanent pins might overlap (when I do the compatibility patch). Unless their mod has a detection if a nearby pin exists near an object.
--end edit--
also the magecap and mushroom (plus other mushroom related things) I can't seem to replicate it.
I can only replicate the issue if I track "Pickable_Mushroom(Clone)" and then not set it to "Exact ID Match".
which would lead to magecap, yellow, blue, and jotun puffs, be pinned.
--another edit--
made an update that fixes both the issues you've found.
As for copper / silver / boulders, see here for a detailed explanation: Ore tracking not working. ยท Issue #1
Mod looks great, would like to use it - your installation instructions are not exactly clear with regards to the json.net framework that needs to be installed.
Do you just drag and drop this into your plugins folder, as you would normally for any other mod?
So you will have in your bepinex folder, JOTUNN, the dll for auto map pins and the json.net dll's too?
Sorry just not clear, your installation instructions do not match the mod requirements, I guess it assumes you already have the json.net framework installed.
note: looks like the json.net zip file has "plugins" folder in it, just merge them both and it should be good to go.
Awesome, thank you for clarifying I will install now and test :)