Bug #143: Adding maps without map limit
| ID | #143 |
|---|---|
| Submitter | Hollows |
| Product | EOSERV |
| Severity | Feature Request |
| Status | OPEN, CONFIRMED |
| Submitted | 26th Sep 2012 |
| Updated | 26th Sep 2012 |
12 years, 14 weeks ago
I would like to see a way of adding maps without the need of adding Maps = 278 in config.ini just like the way it's done with quests.
Comments
12 years, 14 weeks ago
There's no standard filesystem API that can scan the directory for maps, so without writing a filesystem abstraction layer (over the top for using only to detect the number of maps, but for automatic mutation it could be a nice addition), it has to load using a sequential order from 1 to n. EOSERV could stop trying to read at the first not-found map checking from 1 to infinity, but that means one missing map wipes out half the maps on your server (and if people rush to log in, as EO players do, getting mass-warped to their home locations, or worse, default home locations)...
Quests have their maximum implied by the maximum vendor ID in your NPC pub files, which is effectively an implied "Quests = X" option.
A fun way to go about automatically adding maps could be trying to load them on demand (if someone gets warped to map 1234, it will try load 01234.emf if the map doesn't exist), but that has problems such as what to do about chest spawn timers, and if that's decided, things like timed events in map-bound EO++ scripts (when/if they ever get implemented).
I think I'd lean more towards doing the auto-loading than the filesystem scan. Seems like an elegant way to add new maps and, if replacing pre-loading all maps, it could shave a lot of the startup time of EOSERV off, too!
Updated Status to CONFIRMED
12 years, 14 weeks ago
Hmm, I see. I didn't think it would cause problems.
12 years, 14 weeks ago
You could just have chests spawned on map load, or just create the timer on load. Making a player wait for a spawn isn't totally unfair... You could probably load maps on-demand when a script calls for it too. I thought of doing this same thing if/when I ever (re)write my server software.
I'm not too sure about file API, unless you mean compatibility between windows/linux. WinAPI has a fairly standard File search routine. FileFirst, FileNext or something like that. Take note though, that I have seen file name sorting differences. between file system formats, I.E. FAT32/NTFS. FAT32 appears to sort them via creation date, while NTFS more often appears to be sorted alphabetically.
12 years, 14 weeks ago
It might be unfair or not, but it would be a huge change to have chests suddenly not spawn because noone left their alt afking for 20 hours in the hall of pain.
Chests are easily done by starting the timer at (seconds since server start), and scripts should be fine since they'd be referencing the map, therefore loading it.
The only real downside is that the second a file named xxxxx.emf exists, the map will attempt to load in to EOSERV without any further interaction if accessed, though it could be an accidentally placed file, a half-saved file, etc. It's also not consistent in that replacing old maps won't immediately update them.
12 years, 14 weeks ago
Ah yeah, well that makes more sense. I suppose you read the request differently and thought that file scanning for new maps to load (during run-time) was a thought. You could do it on start up to get a maximum map value, but map load on request really is the way to go.
As for the chest problem, maybe you could add chests to the lists of things that load maps. Would solve that problem nicely, except that you'd still probably have to do a file scan, and process the maps to find these said chests...
Add Comment
Please don't post unless you have something relevant to the bug to say.
Do not comment to say "thanks" or "fix this please".
Please log in to add comments. EOSERV Bug Tracker > Bug #143: Adding maps without map limit