Hello everyone,
I'm mostly a lurker here, however I wanted to share a project some community members and I have been working on for a couple of weeks. With the introduction of the new version of Limbus, it was to me missing a good way to consolidate reports for NM and ???.
So the result of a couple of weeks work is https://whereisnm.com/ which might remind some of you of https://whereisdi.com/ (no affiliation, but we took inspiration from it, big kuddos to Aphung for it).
To accompany the website, I also wrote a Windower addon, which is used to send and show data. When you spot an NM or ???, you run an addon command that sends the data to our service, and it shows up on the website.
I hope you'll find it useful. If you spot any issues or inaccuracies, please open an issue or feature request on the website/Github. The more users who contribute data through the service and addon, the more accurate it will become.
- Meliora
Where Is NM - A Limbus NM & ??? Tracker
|
Where Is NM - A Limbus NM & ??? Tracker
Will this addon be implemented into the windower addons and autoloader tab at some point? The easiest way to make this work would be for your addon to automatically detect whenever someone targets any of the limbus NMs, and then send the appropriate zone, floor, NM name, and server data to your database. Distribution would be much easier if it were available directly via windower, but I'm sure plenty of people would be happy to run it once it was confirmed safe if given the opportunity.
[+]
I just happened across this yesterday and got the addon, then sent the temenos location for asura!
It would be great if there were a way to auto-detect interaction with the ??? to eliminate the need to state "t central 4" so the addon can run passively instead of requiring intentional interaction to submit data. Banger idea
Would be cool if the addon detected the NMs and ??? though instead of relying on someone to input the command on detection Great questions and suggestions.
Asura.Melliny said: » Will this addon be implemented into the windower addons and autoloader tab at some point? I'd be open to it, I'm not sure on Windower team stance when you have an addon which communicates with an external backend but once the addon reach a point where I feel its fully developed, I could open a dialog with the team for a discussion. paladinepsot said: » It would be great if there were a way to auto-detect interaction with the ??? to eliminate the need to state "t central 4" so the addon can run passively instead of requiring intentional interaction to submit data. This was the original idea but I noticed quickly that the zone data only consists of Temenos and Apollyon and inside has no position data. I'd imagine it maybe is possible with Packets but to be honest, I'm not very familiar with that. You can periodically scan for mobs by name and automatically send info based on that instead of having the user manual signal when they see a NM
[+]
MelioraXI said: » This was the original idea but I noticed quickly that the zone data only consists of Temenos and Apollyon and inside has no position data. https://github.com/Selindrile/iSpy I used this addon back when keying Sheol boxes was the way to get lusties (before segs had a purpose) to find boxes since they blended in with the background. Theres code in the Spy function that shows how to scan for targets. Coupled with the players XYZ information, you could tabulate what floor they're on and an approximation of what area they're at. I think the biggest issue with that though is all the dead NM's likely have their corpses laying around until sunday reset, since someone confirmed that only one of each job will spawn per week, and its possible to have 0 NM's on Saturday (22 jobs, 7x4 = 28). I havent run through Limbus with ASE running to confirm if dead NM's stick around for the week.
[+]
Yep, that's what I was thinking too. Thanks for the code example it gives me some ideas of an implementation. I should have something ready later this week.
[+]
Carbuncle.Nynja said: » I think the biggest issue with that though is all the dead NM's likely have their corpses laying around until sunday reset, since someone confirmed that only one of each job will spawn per week, and its possible to have 0 NM's on Saturday (22 jobs, 7x4 = 28). I havent run through Limbus with ASE running to confirm if dead NM's stick around for the week. That's not a big issue, you can filter by valid_target in the entity's attributes, that should hide any invisible NPCs like inactive ??? marks and dead NMs.
[+]
You want the tool to automate itself for several reasons. The first has already been stated; convenience for the user. It's a hassle to expect the player to have to type in a specific command to report a nm when they see it. But there's another more important reason that also stems from having the players self-report sightings, and that's data accuracy.
If you allow players the freedom to report NMs and expect them to be the ones adding the data to your database then you're relying on the honor system, and when you're working with data you never want to do that. While the majority of players would be honest with the tool, all it takes is one person to false-report a bunch of NM sightings to fill up the database with bad and inaccurate information. "Report dancer NM in temenos east floor 3, report blue mage NM in temenos west floor 2, report Apollyin sighting of warrior in NE floor 4"... when none of those nms are actually there and you're just going to send players on a wild goose chase hunting for something that doesn't exist. Some people get a kick out of making others lives difficult and playing pranks like that. So automating the process so the tool is capable of handling all the data collection by itself and then distributing it so it runs passively is actually critical if you want the info it collects to be reliable.
[+]
Oh, another point in favor of automated checking: you can have outdated information corrected basically as soon as someone gets close enough to find out it's gone stale.
If you track the ID of each reported ??? and NM, you can have the addon put any that are flagged as active on a verification shortlist; if someone with the addon running happens to pass by something with that ID in that zone which isn't visible to players, it can be unflagged. Not sure if that'll work as well with the ??? spots since they probably move when they deactivate, but it'll let the system change coordinates for a given ??? instead of flagging a duplicate. (NMs tend to stay where they die until it's time to respawn, Limbus could be an exception but that would have required SE to put in extra work so probably not.) If you can't count 100% on people accurately reporting that they found something, imagine how much worse it would be to get accurate reports on finding nothing. I think the floor tower information might be capturable from the text value in the upper left corner
I think I recall seeing that field was parsable in the windower discord Also might be able to piggy back on the jingle code for detection direction and pass it for posting Don't forget the nms can also walk up the porter Dunno if they can go downstairs like elephants? Cows? I see the value in the last sighted field however I have found a somewhat reliable way to detect floor/tower when you jump around which require more testing.
I have skimmed through the referenced addons in this thread and have a good understanding how I can make a automatic to semi-automatic way to report the findings. Only thing I'm little hesitant on is running into the same problem some users (myself included) had with WhereIsDI where it can cause micro-stutter from requests being sent periodically automatically, so I want to test it properly first to not cause other issues. Having it semi-automatic via something like //[command] report - where automatically fills in the headers for the API for both NMs and ??? findings would be a fine compromise I think, if micro-stutter is an issue. Similar idea for reporting the TOD. I appreciate the good suggestions. Could it trigger a outgoing report on zone or floor up?
MelioraXI said: » Having it semi-automatic via something like You could only send reports when the player is in a city zone, where a stutter won't hurt them. Meaning once you see an NM in Limbus, store the location and once the character warps to a city zone, send that off and reset the stored NM location. What if they log out in limbus
What if their power cuts off and they don't get a chance to report an NM.
Log out can be handled though - send any stored location when the addon is unloaded - windower has hooks for it. MelioraXI said: » the same problem some users (myself included) had with WhereIsDI where it can cause micro-stutter from requests being sent periodically automatically I haven't looked at the code for either addon, but if it's stuttering on reports my guess would be the lua function that's sending the request is waiting for a response rather than using some form of await. I'm not too familiar with lua's coroutine based async stuff, though. Could store the data in the settings file, or even create a separate storage file (my preference, imo easier in most cases to store and use lua data than converting to/from the xml format used in the settings file), then when you're back in town send it. This way if you d/c, lose power, log out in Limbus, whatever, it will still have the data to then report once you're back in town. Leaderboard does this with live score data so crashes don't nuke it all. Could even send it it while zoning, or while in a CS (porting between floors), to do it sooner while still masking it, or both actually would be better to cover in case you warp out after a sighting. Create something like a sendData() function that runs once every time you zone, are in a CS, or however you want to do it, that checks if there's any data stored and send it if there is.
[+]
Asura.Melliny said: » If you allow players the freedom to report NMs and expect them to be the ones adding the data to your database then you're relying on the honor system, and when you're working with data you never want to do that. While the majority of players would be honest with the tool, all it takes is one person to false-report a bunch of NM sightings to fill up the database with bad and inaccurate information. "Report dancer NM in temenos east floor 3, report blue mage NM in temenos west floor 2, report Apollyin sighting of warrior in NE floor 4"... when none of those nms are actually there and you're just going to send players on a wild goose chase hunting for something that doesn't exist. Some people get a kick out of making others lives difficult and playing pranks like that. So automating the process so the tool is capable of handling all the data collection by itself and then distributing it so it runs passively is actually critical if you want the info it collects to be reliable. It's just industry best practices. Data integrity is one of the top priorities you keep in mind when you're working with databases. Designing a clean UI and eliminating as many variables as possible where the end user to break a program are always important considerations. This addon may be a simple program, but those concepts still apply.
Stutter shouldn't be too bad if you're not sending a lot of data at once, should it? When the user synchronizes with the server - either manually, or automatically on zoning into Temenos/Apollyon - store all the relevant data in an array and keep it in memory; you should be looking at like a kilobyte or two, even potato machines shouldn't suffer from that. Then just passively scan mob_array periodically, looking for known NM names (for now) and IDs (once they're all identified) and ??? spots. If one's encountered and there's a conflict with what's known (ID reported inactive but is active, location is not consistent with stored data), then ping the server with just that ID and name, the server, the state, and the location if relevant. Just a small string of data: 99 (server), 999 (zone), 999999 (ID), "Pillager's" (NPC name), "12345 67890" (coordinates) or "down".
Actually recording subzones probably isn't even necessary; someone should confirm this to be sure, but all of Temenos and all of Apollyon are probably just two big zones with floors spread out through them. Search You would probably also want a reverse lookup for any ??? flagged as active: if the user's in the correct zone, if their location is within 50 yalms of this set of coordinates, check for this ID in mob_array; if it's still there and valid_target, remove from verification list, otherwise send an update to the server marking the ??? as down. Fenrir.Zenion said: » Actually recording subzones probably isn't even necessary; someone should confirm this to be sure, but all of Temenos and all of Apollyon are probably just two big zones with floors spread out through them. Search things so if nothing else. That would mean you could basically just record raw coordinates and then have the addon translate: If it's inside this range, it must be on West F1, and so on. Code local floor = {
[37]={ -- Temenos
['Northern Tower - 1st Floor']={ 340.0, 71.62, 376.0},
['Northern Tower - 2nd Floor']={ 220.0, -82.38, 376.0},
['Northern Tower - 3rd Floor']={ 20.0, 71.62, 376.0},
['Northern Tower - 4th Floor']={-100.0, -82.38, 376.0},
['Northern Tower - 5th Floor']={-300.0, 77.62, 376.0},
['Northern Tower - 6th Floor']={-420.0, -82.38, 376.0},
['Northern Tower - 7th Floor']={-620.0, 77.62, 376.0},
['Western Tower - 1st Floor']= { 340.0, -2.38, 96.0},
['Western Tower - 2nd Floor']= { 220.0,-162.38, 96.0},
['Western Tower - 3rd Floor']= { 20.0, -2.38, 96.0},
['Western Tower - 4th Floor']= {-100.0,-162.38, 96.0},
['Western Tower - 5th Floor']= {-300.0, -2.38, 96.0},
['Western Tower - 6th Floor']= {-420.0,-162.38, 96.0},
['Western Tower - 7th Floor']= {-620.0, -2.38, 96.0},
['Eastern Tower - 1st Floor']= { 340.0, 71.62,-184.0},
['Eastern Tower - 2nd Floor']= { 220.0, -82.38,-184.0},
['Eastern Tower - 3rd Floor']= { 20.0, 71.62,-184.0},
['Eastern Tower - 4th Floor']= {-100.0, -82.38,-184.0},
['Eastern Tower - 5th Floor']= {-300.0, 77.62,-184.0},
['Eastern Tower - 6th Floor']= {-420.0, -82.38,-184.0},
['Eastern Tower - 7th Floor']= {-620.0, 77.62,-184.0},
['Central Tower - 1st Floor']= { 540.0, -2.38,-544.0},
['Central Tower - 2nd Floor']= { 300.0,-162.38,-504.0},
['Central Tower - 3rd Floor']= { -20.0, -2.38,-544.0},
['Central Tower - 4th Floor']= {-264.0,-162.38,-500.0},
},
[38]={ -- Apollyon
['NW #1']={-400.0,-0.5, 80.0},
['NW #2']={-560.0,-0.5, 360.0},
['NW #3']={-280.0,-0.5, 360.0},
['NW #4']={-520.0,-0.5, 640.0},
['NW #5']={-240.0,-0.5, 520.0},
['SW #1']={-400.0,-0.5,-520.0},
['SW #2']={-520.0,-0.5,-320.0},
['SW #3']={-280.0,-0.5,-280.0},
['SW #4']={-120.0,-0.5,-440.0},
['NE #1']={ 400.0,-0.5, 80.0},
['NE #2']={ 560.0,-0.5, 360.0},
['NE #3']={ 280.0,-0.5, 360.0},
['NE #4']={ 520.0,-0.5, 640.0},
['NE #5']={ 240.0,-0.5, 520.0},
['SE #1']={ 400.0,-0.5,-520.0},
['SE #2']={ 520.0,-0.5,-320.0},
['SE #3']={ 280.0,-0.5,-280.0},
['SE #4']={ 120.0,-0.5,-440.0},
},
}
There's probably a lazier way to do it, since I'm noticing patterns in the placement of each section, but eh, the "lazy" way means more work for the programmer and less for the machine in this case.
Apollyon definitely seems to be easy to narrow down though: if the x coordinate is positive, skip the west options, if it's negative skip the east. For z, negative skips north, positive skips south. Check the distance to five teleporters instead of seventeen. So yeah, no need to explicitly record the section and floor if keeping communication lean is a factor in preventing stutter when talking to the server (though... actually remembering that the x, y, and z coordinates are all important would help, oops. Kinda forgot that towers tend to be built in an up and down kind of shape.) The floor name must be viewable in data, since it's shown on the UI on the top left corner.
Dodik said: » The floor name must be viewable in data, since it's shown on the UI on the top left corner. Maybe... or maybe it's a UI-only thing that gets triggered by teleporting to a given floor. Only way to be sure would be to have someone pos hack from one section/floor to another and see if the UI updates without the teleporter interaction. Dodik said: » The floor name must be viewable in data, since it's shown on the UI on the top left corner. Using the addon Radec made, it'll report what the floor you're on alongside the bar data. Fenrir.Zenion said: » maybe it's a UI-only thing that gets triggered by teleporting to a given floor. Only way to be sure would be to have someone pos hack from one section/floor to another and see if the UI updates without the teleporter interaction.
[+]
Carbuncle.Nynja said: » You'd have to be pretty stupid to illegally POS around floors when theres a teleporter that will legally POS you around floors. You'd have to be pretty stupid to illegally pos hack around in Mordion Gaol but somebody tried that too. In this case, it would at least be an interesting "let's figure out how the game works" application. That said, just knowing that it's something that has to be sniffed out of packets is enough. That's saying it's not something we know how to retrieve from a player or NPC directly; we can only get it as a side effect when the user changes floors or kills a mob, updating the bar and causing that packet to fire. So, very plausible use case: User jumps into Limbus, goes to Temenos F2, sees an NM. Says "oh yeah, that's right, I have that addon that tracks those, I should fire it up and send a report." User loads the addon, has no floor data to feed it, data being sent out is malformed. If the database is set up to handle nulls for floor value, you get a reported NM at x coordinates on no floor; if it's not, something experiences an exotic error. It's a bit more processing to decode the section and floor from the coordinates, but it's more reliable and if it's done correctly the user won't know the difference.  I left me being an idiot doing "load limbus" instead of "lua l limbus" because I enjoy the reminder that I'm an idiot sometimes. Anyways, the "very plausible" usecase is debunked. You could have loaded the addon and verified it yourself in two minutes by doing exactly what I did: Unload addon zone to Limbus area Port to a floor load addon Look at data presented
[+]
|
All FFXIV and FFXI content and images © 2002-2025 SQUARE ENIX CO., LTD.
FINAL FANTASY is a registered trademark of Square Enix Co., Ltd.