22 Jun, 2009, JohnnyStarr wrote in the 1st comment:
Votes: 0
in special.c, i've noticed this is the path that the mayor uses to go unlock the city gates etc.
I'm curious what the logic is behind the path information? is this some sort of hex-code for exits?
why not something less complex / readable like: "w,n,n,s,e" = west, north , north, south, east?

anyway, i'm planning on creating a bunch of specials for my mud, so naturally i may want to hardcode a path,
do i need to learn anything else?
bool spec_mayor (CHAR_DATA * ch)
{
static const char open_path[] =
"W3a3003b33000c111d0d111Oe333333Oe22c222112212111a1S.";
static const char close_path[] =
"W3a3003b33000c111d0d111CE333333CE22c222112212111a1S.";
22 Jun, 2009, Runter wrote in the 2nd comment:
Votes: 0
staryavsky said:
in special.c, i've noticed this is the path that the mayor uses to go unlock the city gates etc.
I'm curious what the logic is behind the path information? is this some sort of hex-code for exits?
why not something less complex / readable like: "w,n,n,s,e" = west, north , north, south, east?

anyway, i'm planning on creating a bunch of specials for my mud, so naturally i may want to hardcode a path,
do i need to learn anything else?
bool spec_mayor (CHAR_DATA * ch)
{
static const char open_path[] =
"W3a3003b33000c111d0d111Oe333333Oe22c222112212111a1S.";
static const char close_path[] =
"W3a3003b33000c111d0d111CE333333CE22c222112212111a1S.";


Looks pretty ugly and I'm not sure why it's in that format. (I seem to remember seeing something based on rom that had something readable there.?)
22 Jun, 2009, JohnnyStarr wrote in the 3rd comment:
Votes: 0
(sigh)

Well, yes i know Rom has allot of crummy stuff, but honestly, it is my endevor to rise above it and
rewrite some of this funky stuff. I have evaluated how long it would take to either start a new codebase from
scratch, start over with SMAUG or stick to it and recode everything i dont like to create my own Rom derivative, and
really, it seems that the latter is going to be the best for me and the time i've dumped into this project.

Hopefully with the aid of our very smart community :cool:
22 Jun, 2009, Zeno wrote in the 4th comment:
Votes: 0
Can you show us where open_path is used, it would help figure out how it is being applied.
22 Jun, 2009, Davion wrote in the 5th comment:
Votes: 0
It's definitely not hex code ;). ROM uses a switch statement a little farther down to determine which each one of those values mean. 0-3 are nesw respectively, then the characters (SWabcdeE, etc) all do something different outlined in the switch statement. It does more than just move him around, it makes him say things and complain a lot!
22 Jun, 2009, Runter wrote in the 6th comment:
Votes: 0
staryavsky said:
(sigh)

Well, yes i know Rom has allot of crummy stuff, but honestly, it is my endevor to rise above it and
rewrite some of this funky stuff. I have evaluated how long it would take to either start a new codebase from
scratch, start over with SMAUG or stick to it and recode everything i dont like to create my own Rom derivative, and
really, it seems that the latter is going to be the best for me and the time i've dumped into this project.

Hopefully with the aid of our very smart community :cool:


You might look at some of the stripped out versions of rom with bug fixes and improvements if you're looking for a good compromise. (Also I hear NakeMUD is pretty good without having to reinvent wheels.)
22 Jun, 2009, JohnnyStarr wrote in the 7th comment:
Votes: 0
OK, I'm kinda dumb for not seeing this earlier, it appears it is a custom switch statement:

switch (path[pos])
{
case '0':
case '1':
case '2':
case '3':
move_char (ch, path[pos] - '0', FALSE);
break;
case 'W':
ch->position = POS_STANDING;
act ("$n awakens and groans loudly.", ch, NULL, NULL, TO_ROOM);
break;
case 'S':
ch->position = POS_SLEEPING;
act ("$n lies down and falls asleep.", ch, NULL, NULL, TO_ROOM);
break;
case 'a':
act ("$n says 'Hello Honey!'", ch, NULL, NULL, TO_ROOM);
break;
case 'b':
act
("$n says 'What a view! I must do something about that dump!'",
ch, NULL, NULL, TO_ROOM);
break;
case 'c':
act
("$n says 'Vandals! Youngsters have no respect for anything!'",
ch, NULL, NULL, TO_ROOM);
break;
case 'd':
act ("$n says 'Good day, citizens!'", ch, NULL, NULL, TO_ROOM);
break;
case 'e':
act ("$n says 'I hereby declare the city of Midgaard open!'",
ch, NULL, NULL, TO_ROOM);
break;
case 'E':
act ("$n says 'I hereby declare the city of Midgaard closed!'",
ch, NULL, NULL, TO_ROOM);
break;
case 'O':
/* do_function(ch, &do_unlock, "gate" ); */
do_function (ch, &do_open, "gate");
break;
case 'C':
do_function (ch, &do_close, "gate");
/* do_function(ch, &do_lock, "gate" ); */
break;
case '.':
move = FALSE;
break;
}
22 Jun, 2009, Runter wrote in the 8th comment:
Votes: 0
Yeah, I'm assuming each time it is called pos gets bumped up one.
22 Jun, 2009, Sandi wrote in the 9th comment:
Votes: 0
Given how often the exit numbers are used, it's worth memorising them even if you're not a builder.

If you're going to write more paths, you might consider writing a 'return_path' function that would take a path, reverse the order, and convert the exit numbers so you have a utility that could handle guards on rounds, etc., by only writing half the path, then copying it into the function.
22 Jun, 2009, Runter wrote in the 10th comment:
Votes: 0
Sandi said:
Given how often the exit numbers are used, it's worth memorising them even if you're not a builder.

If you're going to write more paths, you might consider writing a 'return_path' function that would take a path, reverse the order, and convert the exit numbers so you have a utility that could handle guards on rounds, etc., by only writing half the path, then copying it into the function.


It's pretty easy to remember. I think it's like 0 - 3 clockwise and then 4 is up and 5 is down?
22 Jun, 2009, David Haley wrote in the 11th comment:
Votes: 0
It might also be nifty to simply specify points on a patrol, and have a path-finding algorithm do the rest of the work. More work at first than just writing paths manually, but it's fun (which is worth something in and of itself sometimes), but also has a practical application: if you plan on writing a lot of paths in the future, it will end up saving you time to not have to track the rooms yourself. There's also the added benefit of the path finder not getting confused by slight changes in exits, for instance. Note that specifying every node along the path is basically a trivialized problem for the path finder, so if you want total control, you can still do that.
22 Jun, 2009, Lyanic wrote in the 12th comment:
Votes: 0
David Haley said:
It might also be nifty to simply specify points on a patrol, and have a path-finding algorithm do the rest of the work.

That's the approach I use for NPCs in my game. It allows for much more dynamic paths. An example of one I'm quite fond of is an NPC that pathfinds to a set of locations (in random order) where it can procure various food stuffs, then pathfinds back to its leader (who also changes locations) to give the stuff it has collected. I also use it in the static manner of: pathfind to vnum X, then pathfind to vnum Y. That one can serve two purposes: 1) You can prevent the NPC from taking the most direct route, such as it would if you did a pathfind to vnum Y only (comes in handy for circuits and navigating around traps) and 2) It works well for NPCs that should remain at a certain location, but are not forced to (ie: player intervention moves the NPC and steals its stuff, so NPC determines where it has been transplanted to, goes to retrieve its stuff, then goes back to the spot it normally stays at and resumes non-pathfinding behaviors).
0.0/12