When kore stumbles onto a map without a .fld file it shits its pants. Spits out a bunch of red error text and terminates. While this might make some sense for those of you using kore as a bot to farm items and other evil crap, it doesn't make sense for people like me who use it as a platform to develop plugins for the official client.
I'm always running around in new areas like Eden quests on iRO. Every week there's a different set of maps and every week I need to make symlinks/copy files like gef_dun03.fld -> egef_dun03.fld. I don't care if Kore can't autopilot around on every map when I'm using XKore. Wouldn't a warning suffice?
A plugin would probably be a good compliment to this, prompting the user when this error occurs if they'd like to copy the file when one matches the e[map_name].fld pattern.
Another thing, how come kore needs an entry in maps.txt to move / follow? If it has the .fld file wouldn't it make more sense to have the map appear as "Unknown Map" instead of saying Map map_name does not exist?
That's all for now. Mostly I wanted to talk to you developers about this before I went and changed anything. More rants to come, I promise. <3
Does kore really need to crash on unknown maps?
Moderator: Moderators
-
itsrachelfish
- Developers

- Posts: 50
- Joined: 27 Feb 2012, 12:50
- Noob?: No
Does kore really need to crash on unknown maps?
Tired of waiting for answers on the forums?
Want to talk to OpenKore experts?
Hang out on the #OpenKore IRC!
Want to talk to OpenKore experts?
Hang out on the #OpenKore IRC!
-
Technology
- Super Moderators

- Posts: 801
- Joined: 06 May 2008, 12:47
- Noob?: No
Re: Does kore really need to crash on unknown maps?
"other evil crap"itsrachelfish wrote:When kore stumbles onto a map without a .fld file it shits its pants. Spits out a bunch of red error text and terminates. While this might make some sense for those of you using kore as a bot to farm items and other evil crap, it doesn't make sense for people like me who use it as a platform to develop plugins for the official client.
I'm always running around in new areas like Eden quests on iRO. Every week there's a different set of maps and every week I need to make symlinks/copy files like gef_dun03.fld -> egef_dun03.fld. I don't care if Kore can't autopilot around on every map when I'm using XKore. Wouldn't a warning suffice?
A plugin would probably be a good compliment to this, prompting the user when this error occurs if they'd like to copy the file when one matches the e[map_name].fld pattern.
Another thing, how come kore needs an entry in maps.txt to move / follow? If it has the .fld file wouldn't it make more sense to have the map appear as "Unknown Map" instead of saying Map map_name does not exist?
That's all for now. Mostly I wanted to talk to you developers about this before I went and changed anything. More rants to come, I promise. <3
Nooooo, did no such things, only used it to get tons of nonstackable items by batch from the storage and for upgrading gear, I swear
But yea, it doesn't make much sense that it terminates on a map without a fld imo. This behaviour should be at least hookable/overridable. (one might only just want to bwing out of such map)
At the very least, there should be a warning about how to update the .fld files, and other table files.
If the RO client does not bundle egef_dun03.rsw and such, then it has some sort of mechanism to know that this map is in fact the gef_dun03.
Ideally if the RO client does not duplicate its map files, then kore shouldn't have to either.
IIRC the mapalias system uses some kore table file to get the real map names (from server sent alias or instance names).
I seem to remember that we changed Field.pm from using hard coded mapalias values, back then it were only pvp maps, to a more general system, using the same table file as the RO client.
Yea, it seems like the resnametable.txt table file needs to be updated for iRO.
The follow/move also doesn't make sense, when you have the fld it should be possible imo.
However, the server can send mapnames (instance|alias) that are different from the names of the .fld (.rsw) files.
Then kore won't know what .fld file to use.
At first kore used to break OOP encapsulation a lot in this area real badly, accessing Field's attributes from the outside, which caused us quite some trouble & fallout to fix up.
These particular problems could also stem as a remnant of those days.
TL;DR
So my bet is that just updating resnametable.txt could solve some of the problems you are experiencing already.
One ST0 to rule them all? One PE viewer to find them!
One ST_kRO to bring them all and in the darkness bind them...
Mount Doom awaits us, fellowship of OpenKore!
One ST_kRO to bring them all and in the darkness bind them...
Mount Doom awaits us, fellowship of OpenKore!