Where Is NM - A Limbus NM & ??? Tracker

Alright, fair enough, if it's that easy to get the section and floor data in a human readable format, it's reasonable to do it. I don't like to carry redundant data, but since there's no actual meaningful restriction on data transfer and storage here there's no reason to make my weird design aesthetics somebody else's problem.

That does remind me of something though. Had somebody telling me about Project Silmaril telling them where the teleporters were in Sortie, and how it would give them the exact distance to them. When I said that sounds awful and I'd definitely find coordinates more useful, I was told I was wrong and I couldn't find anything with coordinates, only distance. But the important thing is I had an onion on my belt, which was the style at the time.

So... giving users coordinates for points of interest is useful, but maybe have an optional ping on entering a new floor, giving a direction and distance ("Floor alert! Bihu 120 yalms northwest!") would be a handy feature? It's not perfect, see the whole voidwalker NM system, but it'd be a nice user-friendly touch.

Optional and disabled by default, please. With plenty of "use at your own risk" disclaimers for anyone who turns it on.

This kind of feature usually involves injecting outgoing 0x016's for specific targets that aren't within normal detection range, and reading the 0x0E the server returns to get the target's location. You may or may not get banned, but it's very easy for SE to detect if they care to.

You could show an alert when close to an NM's previously-reported position without packet shenanigans, though, and that would be nearly as effective without the risk. An extra minute or two looking for an NM isn't as big a deal in Limbus as it is in Sortie.

I was kind of envisioning something a bit more based on reading the information the addon server was feeding you: This is the distance and bearing to the latest reported location of an NM or ??? on this floor, as of the last time you synced.

The NMs move around though, theres no need for a precise XYZ coordinate

Oh, so this is "What Floor Is An NM On."

Yeah, could also passively read incoming packets and do a ping as soon as the player moves into range of the NM.

Would only work with normal detection range, but still useful; With all the side rooms and trees and such there's a lot of sight obstruction in Limbus.

Just wanted to drop in with a progress update.

I have examined most of the addons suggested here for context to improve the project.

Some of the implementation was already some of the ideas I had so it's nice we are not all reinventing the wheel so to say.

I've spent most evenings all week on this between my busy life but should have everything deployed sometime next week.

What I have managed to implement in my dev version:

- Automatic reporting
- Automatic reporting TOD
- Automatic floor detection
- Streamlined some of the commands. Really only that is left is a TOD report as a fallback and enable/disable HUD and send (if you want to opt-out not contribute data).
- Some refactoring in backend and frontend client.

Thank you for all your input and suggestions.

Where Is NM v0.0.7 is live!

Website:
- Will now display all killed NM for the week - hidden by default ("Show Killed NM") button will display them
- Killed NMs and ??? will get hidden on weekly reset
- Documentation revised for changes in addon (see below).
- Various UX updates

Addon:
Bumped to v0.0.7
- Automatic reporting of NM and ???
- Automatic detection for floors/towers
- Automatic reporting of TOD
- Updated and removed commands - See full list on
https://whereisnm.com/documentation#commands

v0.0.7 is a requirement for most of the new functionality to work, it's highly recommended to upgrade asap. You will get a notification when you load the addon if you're behind a version and the old commands will most likely generate error messages.

Get latest version at https://whereisnm.com/addon

Experience any bugs or issues?
- Open an Issue report! See more information on https://whereisnm.com/issues

This is great addon, thank you.

Just updated the Phoenix NMs for today. For some reason it didn't post the ??? location even tho it said 5 reports for the zone.

One thing I'd like to see added if possible, is keeping a weekly tally of number of NMs killed in each of the 2 zones, since we know 22 in each is the max each week.

ps. the //nm command isn't working for me since doing the Apollyon update. It just says "No recent data found for Phoenix" even if I unload and reload it.

The website does that, it's more of a challenge to get it dynamically in-game. Though I probably have to change it to monthly after next week... Thanks SE.

As for your other points, it's hard without seeing your log.txt output. Open an issue ticket and I can look at the logs.

Not really a bug per se, but it seems like the API is returning an "error" if a specific NM has been reported on that floor already.

If the report was received, it might be better to log that silently(if at all), rather than surfacing a bright red error to the user, regardless of what you do with that report on the back end.

I do think there's value in updating stale timestamps whenever an NM is spotted to indicate it has not been killed, as not everyone killing NM's will be using the addon.

It have been added to a beta version that is being tested. It will silent most messages but keep the full log in the log file and keeping a history.

Someone were making a suggestion to have it update the timestamp on seeing it, I haven't seen the benefit from it but if more people want it i might consider adding it. Updated the backend so it will update it and frontend reflect this.

Is there a way to tell the HUD to only show current NMs (ie, hide killed NMs)?

It's the first blue button at the top left.

This app for discord is the bees knees!

I assume you mean HUD as the in-game texts box.
Currently no, it's basically just doing a GET request to the server and displays (based on settings.api_limit - or whatever I called the variable) how much data is returned.

The website can show it as Mcdoogle pointed out.

I added an alert box on the website that it currently isn't displaying the data correctly. This is due to a change I implemented but have been spending the week of refactoring the addon and backend after that.

The API still works though so the addon command //nm and discord bot should still return relevant data. It just a frontend (website) display issue.

From my testing of the refactoring, it will no longer need floor input and will be more efficient.

I'll update when it goes live which I hope later next week after some testing.

By then we probably have more insight in the changes but from my own understanding it no difference to what I expected, once a NM spawns its dead and won't respawn until next period. In theory a server could kill all their NMs within a week.

Development follow-up.

I've rewritten a large part of all components and will deploy it later today or tomorrow Monday.

I'm happy to report that it will be more automated now and tested with and without Superwarp (I've gotten reports some part of the old version wouldn't behave as expected in certain scenarios).

It will automatically detect the NM from afar, where I got some ideas from https://codeberg.org/svanheulen/limbus

It will also update the backend automatically if a second scan no longer detect a NM/??? but are still active in the database and mark them expired - This require more testing but we ran out of NMs on Shiva... Lol

I've tried to retain as much as possible so it will be backward compatible but an addon update will be required long-term.

I'll make another update when everything is live and you will notice when loading the addon since it will run a version check on load.

Thank you for all feedback and patience.

So I/my group/many people don’t run the addon (yet?!?) is there a way to update the data on website?

- Phoenix ??? Is apo SW3, display as 2 atm, this is a new one as we spawn it yesterday, it shown the previous one but timestamp show recent.

- Also, we took down 2 NM, and would like to mark them.

So is there an option or that was ruled out because of saboteurs?

No, that's why the addon exist, lol.
It could get pretty messy if I opened a form for anyone to enter data when it can't be validated/verified.

For TOD, there is a command for it, see the website for documentation: https://whereisnm.com but it will be deprecated when the new version go live.

12 Oct
Deployed updates to:

- Backend service
- Website client
- Packaged new addon beta

https://whereisnm.com/release-notes

I dont see anywhere in your 0.0.10 code for this to be an opt-out function. Considering this involves the client doing things its not supposed to be able to do natively, can I suggest defaulting this to off and making it an opt-in function? While I dont believe anyones ever been banned for using the 0x016 packet in such a way, there are still some things people may feel less comfortable doing.

At minimum, there needs to be a pretty significant warning about this; if people want to use it, that's on them, I'm not their real dad. But, if you would like to talk about it here, this aspect of it needs to be pointed out.

There is an implicit understanding that plugins and tools discussed here are (relatively) safe; anything that falls outside of that needs to have a pretty obvious disclaimer. Thanks.

That's fair. I'll implement a opt-in setting for this.

Do note that whether people got banned for it or not, using packets this way 100% qualifies as an exploit, so make the disclaimer REALLY BIG and make sure users know what they're using.

I've added a warning message when enable - explaining the risks, a clear disclaimer in the addon code and readme, there will also be clear on the documentation sub-page.

I feel that should be more than suffice and opt-in as mentioned in my previous comment.

An updated beta is live for testing. Ran some initial tests on my end without any hiccups.

https://whereisnm.com/release-notes

No, your disclaimer is not enough:


This does not make it clear to a layuser that the packet injection happens in a way that is completely impossible to trigger with normal gameplay, that is extremely detectable on SE's part should they wish to do so, and is effectively an exploit of the widescan system.

Plenty of addons inject packets in a way that is more or less undistinguishable from normal game operation. Scanning the entire zone programmatically for possible NMs, far beyond possible widescan range, does not fall under this case.

Your addon is no longer a QoL utility (like WhereisDI is), it's now a cheating tool.

Not to mention that the mechanism it uses was, until now, relatively obscure and not used by any major tool. SE has a tendency to notice this stuff (especially at the frequency at which your code is spamming detection packets...), and patch it out when it starts getting too widespread - similarly to when they patched server-side the ability of the old superwarp to warp you to still-locked homepoints.

This stuff is not innocent, don't think for a single second that it is.

In that case, I think its best to remove the functionality altogether and only use the mob array that Windower makes available without the packet injection.

Is the mob array the one that pulls all available entities ids into table
Alive or not?

The innocent way to do the auto-detection-when-getting-into-range is to monitor incoming NPC Update packets (0x00E). You get one of those anytime a mob pops in your render range (50 yalms), then for anything they are involved in thereafter (spawn/despawn, hp change, movement, claim/unclaim, etc etc). The zones are really not that big and you'll still get a steady stream of updates.

The addon you got inspiration from has a manual function to run that very command.

I dont think the function is terrible per se, even if it is doing stuff the client cant natively do (which as far as I understand, gearswap also does things the client cant natively do with precise pre and mid swaps for example). It just shouldnt be enabled by default without the ability to disable.


Information on kill-counts over the month and active NM's in the area should be given to the player by the detector in the lobby anyways, not that this justifies anything but still.



Also I dont see the point of needing to run the scan multiple times? If I'm looking at the code properly, it does the scan, reports all live NM's (or just the closest one to your position, or the first one in the ID list) and which floor they're on? Is there any need to spam it every 30 seconds you're in a limbus area?