27 Jan, 2010, chaoticus wrote in the 1st comment:
Votes: 0
Hello,

I have created some code for crafting items, and would like to change how it works, instead of using a series of arguments, to be more menu driven.
for example: blacksmith epic helmet "if all required items are in inventory, it creates the helmet"
instead, I would like to have players type craft, which enters a menu system, somewhat like an olc editor.

the code:
void do_craft (CHAR_DATA *ch, char *argument)
{
if(IS_NPC(ch))return;
char arg;

send_to_char("Welcome to the crafting menu.\n\r",ch);
send_to_char("Please make a selection from the following options.\n\r",ch);
send_to_char("1. Create a new Item.\n\r",ch);
send_to_char("2. Edit an item that has already been crafted.\n\r",ch);
send_to_char("3. Destroy a crafted item, and recieve partial creation points.\n\r",ch);
send_to_char("Enter any key to leave this menu.\n\r",ch);

arg = getchar();
{ switch(arg)
{
case '1':
create_item();
break;
case '2':
edit_item();
break;
case '3':
destroy_item();
break;
default:
send_to_char("Leaving the crafting menu.\n\r",ch);
return;
}
}
return;
}


The code compiles, but, when the craft command is issued, it prints all the send_to_chars, and returns, it does not wait for an input character.

Do I need to add an ED_CRAFT, to change the player's state?
Or, should I mimic the OLC editors?

Aleister
27 Jan, 2010, Lyanic wrote in the 2nd comment:
Votes: 0
Not to sound argumentative, but why? I noticed this is posted in the GodWars forum, and as such, a menu driven system seems oddly out of place. What happens if a player gets attacked while in the menu system? Or will that system temporarily transplant the character out of the game world in a similar fashion as to the discussion boards and OLC? Furthermore, I've never seen a GodWars derivative with a menu driven OLC either. Of course, it's entirely possible that there is one, or even that you've written a custom one. More information would be helpful.
27 Jan, 2010, JohnnyStarr wrote in the 3rd comment:
Votes: 0
Most OLCs do not use the descriptor->connected (or what have you) as the identifier for alternate
menus. In other words CON_PLAYING is the same, what you want is to add something like: int altmenu
to your descriptor structure / class. If it is set to say 0, then you are not on an alternate menu. Then,
somewhere in comm.c you would add a conditional to check the status of d->altmenu. As mentioned above, if you are CON_PLAYING and there are important things that you must be aware of while in-alt-menu, you will be made aware. With this model, you can also add things like being "kicked" out of alt-menu state. Once the interuption ceases, you can resume your crafting, smelting, etc while still being
aware of your surroundings. I happen to love menus, IMO it only adds to the gameplay.
27 Jan, 2010, David Haley wrote in the 4th comment:
Votes: 0
getchar() reads from the program's standard input, not from the character. You will need to emulate the other menu systems one way or another by using the substate etc.
27 Jan, 2010, chaoticus wrote in the 5th comment:
Votes: 0
The olc is not truly menu driven, rather, it allows you to hit enter, and what not, to view the obj/mob/room being edited, and whats set.
Reason behind the menu, is to allow for more player freedom on gear that they craft. instead of a set hit/dam roll, ac, bonuses and such.
Each piece, would have an amount of points alloted, that can be used to set things.

As for players being attacked, it will be similar to editing notes.
27 Jan, 2010, JohnnyStarr wrote in the 6th comment:
Votes: 0
{       switch(atoi(arg)) // change this and you are set, just make sure you put this in an alternate menu function
// and have some sort of case statement elsewhere to determaine the state
{
case '1':
create_item();
break;
case '2':
edit_item();
break;
case '3':
destroy_item();
break;
default:
send_to_char("Leaving the crafting menu.\n\r",ch);
ch->desc->altmenu = ALTMENU_NONE; // do this to return to standard input mode ;)
return;
}
}
return;
}
27 Jan, 2010, Lyanic wrote in the 7th comment:
Votes: 0
chaoticus said:
Reason behind the menu, is to allow for more player freedom on gear that they craft.

Whether the system is menu based or a command with arguments has no effect on what can be crafted. It's just a UI decision. Admittedly, menus might make for a more user friendly experience if there are more than 4-5 types of options (each of which would be arguments with the alternate system).
28 Jan, 2010, elanthis wrote in the 8th comment:
Votes: 0
The way I handle these scenarios is to have a separate state struct for various UIs. For example, the trade UI creates a trade state struct that tracks who you are trading with, what the traded items/coins are, whether each side has accepted the current offer, etc. There are then a series of commands that interact with the state struct separate from regular MUD commands, so the state does not interfere with the regular game. The 'cancel' command is generally always used to cancel out of any state. Other than that, other various commands can intereact with the states as necessary, including commands like 'accept' or 'select'. You could have simple number commands for interacting with basic menues. I usually make the empty command (just hitting enter) re-display the states' basic info (trade offer, current crafted item, OLC object being edited, whatever).

It's relatively trivial to add such a setup to any MUD codebase so long as you've got a decent grasp on C/coding. You need a new struct for storing the general state information, a callback function for each state to deal with commands and state display, any per-state structs for the specific data each state has, and then just make sure they're all cleaned up when exiting or changing states to avoid memory leaks.
28 Jan, 2010, Kline wrote in the 9th comment:
Votes: 0
I'd recommend looking at existing examples just to give yourself an idea of what to build on, or how to build it. All ACK! based games used a menu-driven character creation system, and I think Circle MUDs do too (but I'm not 100% there). While those are both handled in nanny() at the character's connection state, they're still good examples. I'm sure someone could also point you to a menu-based OLC game to look at, since that would be closer to what you're attempting to do. tbaMUD comes to mind off the top, but I haven't used it myself so I can't verify that.
28 Jan, 2010, chaoticus wrote in the 10th comment:
Votes: 0
Thanks for the responses, thoughts, and ideas.

Aleister
28 Jan, 2010, Kjwah wrote in the 11th comment:
Votes: 0
I was also doing a custom OLC system that was menu driven years ago. I'm afraid to post the code as I don't feel like being flamed for how crappy of a programmer I am but if you're interested, send me a PM with your email and I'll send you a tarball of the code with some details on which files to look in and which line numbers.

I handled mine in the game loop function like was said earlier in this thread. I believe Davion used some parts of the OLC at some point so maybe he even has the code laying around cleaned up a bit but don't quote me on that. :p

Only reason I mention my old code is that it'll be easier to pick out for a budding programmer as my code has a lot less code to go through making it easier for you to figure out how/why it's working like that. :p

But if you want to dig through something with 100k lines of code, have fun. :) It really is fun.
0.0/11