Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mapper - handheld portals #35

Closed
fiendish opened this issue Feb 14, 2014 · 6 comments
Closed

Mapper - handheld portals #35

fiendish opened this issue Feb 14, 2014 · 6 comments

Comments

@fiendish
Copy link
Owner

From musidan@gmail.com on December 24, 2010 17:25:30

The mapper needs to understand handheld portals and be able to use them.

I've started something along these lines, but don't have quite enough knowledge of the mapper to complete it yet...

So here's my strategy...

1 - we add a room to the rooms table with uid '*', name '_HERE_', area '_EVERYWHERE'. This room is there to prevent the foreign key constraint from exits into rooms from being violated.

2 - for each handheld portal, we add an exit with fromuid '*', touid 'vnum of the portal destination room', direction 'portal keywords'. This function will probably have to be manually invoked. Right now, I am using "mapper portal " to do this. The command maps the portal as an exit from * to the current room.

3 - I don't have this done yet... the mapper needs to be modified to recognize * as the current room, so that when it's going through its recursion to find a path, the first match for * or the actual vnum of current room will trigger a found condition.

4 - Maybe this should be 2.999... the mapper needs to be modified so that if it is trying to run FROM * (ie, starting room for the path matched * instead of the actual room vnum), then the mapper sends commands to get portal from its container if applicable, dual remove or unhold something as appropriate, hold portal (hold 'keywords'), enter, remove portal, dual wield or rehold held item as appropriate, stuff the portal back into its container. I currently have an alias (goport ) to do this, but having the mapper invoke it is not yet implemented.

5 - I'm attaching my updated aardwolf_gmcp_mapper.xml with items 1-3 and a couple other tricks added...

6 - Custom exits should actually be easier, but probably still requires mapper modifications to send the custom exit commands to the mud. What to do is create an alias (I'll call it CEXIT for now). When the player types CEXIT CLIMB TREE (for example), the plugin should store the passed arguments(CLIMB TREE), and the starting room vnum in local variables, then send the command to the mud and wait for the next gmcp rooms.info broadcast. If the room vnum changes in response to the command, then insert a row into exits; fromuid = , touid = , dir = (eg. CLIMB TREE). Then the mapper just needs to send CLIMB TREE in the speed walk to move from the starting room to the ending room.

To do:
Edit the mapper fuctions to use the portals in the DB.
mapper portal delete --> Delete a specific hh portal from the exits table
mapper portal purge --> Confirm then delete all hh portals

Original issue: http://code.google.com/p/aardwolfclientpackage/issues/detail?id=35

@fiendish
Copy link
Owner Author

From musidan@gmail.com on December 24, 2010 14:36:47

Ok - now I'm attaching the one that works. The match pattern in the mapper portal alias would not capture things like (114732), which is a valid portal keyword ;)

Attachment: aard_GMCP_mapper.xml

@fiendish
Copy link
Owner Author

From musidan@gmail.com on December 24, 2010 14:43:31

One more time - had made a change to my de-duping code and typo'ed a variable name...

Attachment: aard_GMCP_mapper.xml

@fiendish
Copy link
Owner Author

From musidan@gmail.com on December 26, 2010 21:16:29

Here's my idea on how to find a path... we start at the destination, and find the set of all exits to that room. The we find the set of all exits to the fromuids of those exits, and repeat until the returned set contains our starting room or * for a handheld portal. Then we work our way forward, using the newest exit from the current room to the next closest set to the destination... pseudo code attached.

Attachment: pathfinderPsuedoCode.txt

@fiendish
Copy link
Owner Author

From musidan@gmail.com on December 28, 2010 12:58:00

Another fix here for unmapped... This should be the last one...

It now formats correctly and it handles not knowing the current area correctly. Options:

mapper unmapped --> shows all unmapped exits in current area
--> if area unknown, summarize unmapped exits by area
mapper unmapped % --> summarize unmapped exits by area
mapper unmapped --> all unmapped exits in the named area - if it exists

typos are the user's worry... ;)

Attachment: aard_GMCP_mapper.xml

@fiendish
Copy link
Owner Author

From musidan@gmail.com on January 08, 2011 07:23:46

Let's declare this thread at an end... I'm going to start a new issue for pathfinder...

@fiendish
Copy link
Owner Author

From Fiendi...@gmail.com on January 26, 2011 22:52:24

added in r292 and r294

Status: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant