 |
charneus
Wizard
Joined: 19 Jun 2005
Posts: 1876
Location: California
|
 Posted: Sun Aug 29, 2010 6:10 am
[3.23a]More GMCP/Mapper problems?
|
I'm not sure how to illustrate this problem. Running my scripts to run to certain rooms works wonderfully still, but the location always winds up in the wrong room, and actually in a different zone altogether.
I'd been trying to figure out what was causing this, going through my scripts to see any possible culprits, though I haven't touched the scripts in months. Then it occurred to me to turn off room info in GMCP protocols. The second I did that, it no longer teleported me to a different zone/location.
I have a second issue, and it's with mapping in general. Granted, 3.23a is out, which I'm using, and in mapping a new zone, I reconfigure/new configure the mapper, and it works for one room. After that, no other room gets mapped. If I want to map a new room, I must reconfigure again. And again. And... again.
Am I missing something here?
The MUD is Aardwolf, for those interested in testing it.
Charneus |
|
|
|
|
Anaristos
Sorcerer
Joined: 17 Jul 2007
Posts: 821
Location: California
|
Posted: Sun Aug 29, 2010 6:41 am
|
It happens because the mapper updates its location using the GMCP room.info, so while the speedwalk works because it is computed by the mapper using its internal vnums (ObjId) when it sets the current location the mud will send it's own vnum, causing the mapper to "correct" itself. There are workarounds to this problem, but ultimately, the best (and most tedious) solution will be to rewalk the entire mud and update the vnums explictly rather than allow the mapper to just simply autoincrement the ObjId (put in another words, it will be equivalent to creating a new mud map). One way to get out if this would be for the mapper to have a mode where it updates an alternate field in the database with the mud's vnum. This mode would also tell the mapper that functions returning room numbers would query this column rather than ObjId.
|
|
_________________
Sic itur ad astra. |
 |
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: Sun Aug 29, 2010 4:16 pm
|
If you step into a room and the vnum doesn't match it will teleport you to whatever room has the vnum that matches. Cmud doesn't take into account the proximity on your map, the name of the room, whether the exits match or the description, only the vnum of the room counts. If we all had perfect maps with vnums all correct and filled in then it would be a fool-proof way of doing things. As it is there are going to be a lot of people with incorrect vnums that are going to have the same issue.
|
|
|
|
|
dbosst
Apprentice
Joined: 15 Jun 2010
Posts: 121
|
Posted: Sun Aug 29, 2010 5:18 pm
|
The simplest thing to do is what Zugg suggested and reset all the vnum to 0.. that way the vnum will never match...
you can do it in cmud with something like
| Code: |
#forall %mapquery() {
#call %roomnum(%i,0)
}
|
you could probably do it faster with an sql query but this is the simplest way... NOTE ITS VERY SLOW... so it will take a long time if you have a large map (took my map of Achaea about half hour)
the ideal is to somehow script in a nonbuggy way so that the map also updates the vnum when it find a room with vnum of 0 but I haven't found a way to do it that isn't buggy (the way I had before was to use follow mode and the onroomenter event to unlock the map update the vnum, then lock it again but it was buggy/glitchy) |
|
|
|
|
Tech
GURU
Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA
|
Posted: Sun Aug 29, 2010 6:40 pm
|
I don't play any GMCP muds so I can't test this and honestly probably don't have a good grasp of the problem. Having said that, have you guys looked into using the RoomWalk events, specifically onRoomEnter to check if the Room Info and the GMCP info match up?
|
|
_________________
Asati di tempari! |
|
|
|
dbosst
Apprentice
Joined: 15 Jun 2010
Posts: 121
|
Posted: Sun Aug 29, 2010 7:42 pm
|
the problem is there are two different vnums for people with old maps.. the vnums in the original old map that are essentially cmud generated and random, and the actual vnum of the room according to the MUD. the new version of cmud can use the actual vnum of the room from the gmcp data to put you exactly in the correct place in your map, but you have to have the correct matching vnums (which is not the case for old/existing maps)... new maps don't have this problem and work fine... the issue is resetting all the vnums in your own vmap and updating them... its easy to reset them all to 0, its just updating them to the correct number is challenging and timeconsuming but probably very worth it if one can do it
|
|
|
|
|
charneus
Wizard
Joined: 19 Jun 2005
Posts: 1876
Location: California
|
Posted: Sun Aug 29, 2010 11:07 pm
|
That would explain why I'm having trouble mapping, I guess... if I move a room and the vnum is already in use by the mapper, why would it map a new room? To the Mapper, the room's already been mapped. *sigh*
29k rooms to remap if I want to use GMCP...
Tech: Might actually give that a try, not sure yet...
Charneus |
|
|
|
|
dbosst
Apprentice
Joined: 15 Jun 2010
Posts: 121
|
Posted: Mon Aug 30, 2010 1:50 am
|
you can still use gmcp, and your own matching... and just not use the feature that uses its built in vnums ... just mark all rooms vnums as 0 and you can use your original gmcp stuff
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Mon Aug 30, 2010 4:08 pm
|
Would be better to just wait for the next update later today which should fix all of this mess with the mapper. Sorry.
|
|
|
|
|
|
|
|
