Yeah, well I can safely say I wasn't thinking about memory when I wrote it, I'm not held back by memory limits on my server, so I'm not usually worried about how much memory something is going to take.
I was going to send another e-mail saying something along the lines of "if you are trying to save memory, this isn't the way to do it" but I didn't want to go ahead and double-post. I do have the Unlimited Bits installed on my MUD, and actually I have converted EVERY flag that saves in the A B C D format, over to the unlimited bits format (I was thinking for the future). Let me get this right, when you say less efficient memory wise, do you mean just the fact of having to store: FLAG zq_flags[ZQ_FLAGS]; Instead of: bool zqdone[MZQ]; ? The only reason I put a Max Zone Quest in it all, was just so that I didn't put in like 2500 and have it use -ALL- that memory, and initialize 2500 different TRUE/FALSE statements, when I only have a certain amount of quests. If you could elaborate a little more, you are suggesting that I would store them using SET_BIT, and have them save/load like PLR/IMM/etc flags? Would this still be more efficient for a step system as well? FLAG zqs_flags[ZQS_FLAGS]; And define like step 1, step 2, step 3, etc and use a SET_BIT to set their step? Or does using an integer not make as much difference? I figured it was a lot easier to go ahead and just do ch->zqstep = num; as opposed to a REMOVE_BIT for the previous step, then another SET_BIT to set their step flag. Also then, wouldn't it make identifying the zone quest a little harder as well? When in a mobprog command, and things like, the if statement for checking which step they are on? I am a newbie coder, I have about 8 months of experience in my MUD only and I have had no formal coding teaching, only what I have taught myself just from trial and error and writing code, I would really appreciate if you could help me learn a better and more efficient way to do this. Although memory use isn't a concern to me at all, I would still like to be able to code things, if in the future it ever does become a concern, or I'd still like to be able to write a more "complicated" code that works a little bit better. This was just something I happened to just think of on a whim, and decided it would be good enough, and it would work, but I don't really want to settle just for "good enough". Would you be suggesting just basically using the idea of Thri's mobprog driven quests, converted over to an unlimited bits system? Then wouldn't I have to add a new #DEFINE for every time someone wanted to add in a zone quest? I liked the way I had it set up, because by identifying them only by numbers, we don't have to set up names, or any other thing, or any special #DEFINE for them, they are just identified by their #, and taken care of. All an immortal would have to do, is just let me know they are wanting to create a zone quest, then I tell them, alright, the next available number is, x, go ahead and use that, and then its all done and ready for them. I was also going to add an immortal command like a zqlist that would show all zone quests created by the immortal who made them, and list ALL zone quests for implementers, so they wouldn't even have to ask me which numbers were available. I haven't had any practice with mySQL or anything, so I would like to avoid using that system, until I have properly learned the ins and outs of it. But I would like to try it some day. It just seems to me, that the way I'm doing it, easier to add new quests I guess, if I use up the allotted amount of quests, all I gotta do is raise one number, and we can add however many more quests, don't gotta add any #defines, or anything specific to THAT zone quest. I'm not sure on what else I had to say, I just lost my train of thought, but I'll leave it here for now, and go watch the second half of Game 3 in the NBA Finals :). Thanks in advance for all your help and responses, even though this wasn't initially even my question. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Barton Sent: Thursday, June 10, 2004 9:10 PM To: [email protected] Subject: Re: Quest and files Nothing wrong with it. I wish I could italicize wrong in that sentence. It's just less efficient, memory wise, than using an unlimited bits system. Specifically, it uses 1/8th the memory of a simple array of bytes. And if you already have all the functions and macros for unlimited bits in your game, most of the work is already done. And it's less flexible than using an SQL database. For example with an SQL database, you could let the builders give a name to their quests, and store it in the db based on that name. This would allow builders to make a virtually unlimited number of quests without worrying about assigning quest numbers to builders, not having MAX_ZONE_QUEST set high enough, etc. ----- Original Message ----- From: "Krayzie K" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, June 10, 2004 7:14 PM Subject: RE: Quest and files > I'm a newbie coder, but what's wrong with doing it like this? > > This is how I run it on my MUD and I have had no problems, works like a > charm. > > #define MAX_ZONE_QUEST 10 // Of course needs to be updated, I just assign a > // person a quest # when they want to write one > > bool zqdone[MAX_ZONE_QUEST]; // TRUE/FALSE whether you have completed that > // quest or not. > > Upon character load, set all zqdone as FALSE, then read in something like > "ZqDone #" to flag which ones they have done as completed. > > int zqstep; > > Very easy to just go ahead and save which step they are in as an int, no > need to make it more complicated than it should be. > > int zqcurrent; > > What zone quest they are currently on, they can only be on one at a time, > and if a quest is not completed, and another is started, progress will not > be saved. > > Although, if you do not attempt any other zone quest, it should save your > progress. > > That is just the basics of what I use on my MUD, I'd rather not give out any > more information than that, you would need to code in the saving/loading and > all the mobprogram manipulation yourself, but really it's quite simple. > > If zqcurrent $n [#zqnum] > > If they are on quest x. > > If zqdone $n [#zqnum] > > If they have completed that quest. > > Mob Zqstart $n [#zqnum] > > Set their current quest to the num, default > Sets them on first step of the quest > > Mob zqstep and if zqstep $n [#zqnum] > > Check which step they are on, or set them on a step. > > Mob zqfinish $n [#zqnum] > > Finishes their quest, sets that quest as done, as well > As sets their current and step to 0. > > Stored which quests are done in pfiles as "ZqDone #", > Then on load, just set ch->zqdone[#] = TRUE; > > Of course you'll need to do some type of fread_number to get that from the > file and set a variable of some sort, or just do a flat out > ch->zqdone[fread_number(fp)] = TRUE; > > ^^ but I wouldn't do that > > Without completely writing a snippet for it, which I'd rather not to, this > is the basics and the jist of what I use for zone quests on my MUD system. > I did use Thri's mobprog driven quests to get an IDEA FOR THIS, I did not > rip his system off, and I custom coded every aspect of it myself. > > If there is some like, major flaw I'm missing why this won't work, let me > know, but as far as I'm concerned, and as far as the people and builders on > my mud are concerned, this system has been working out truly great. > > There's lots of other little random things, like making sure its set to 0 on > a load_char_obj and just the little things that I suppose anyone who has > been working with code for a while knows. > > If you do choose to take this approach, I can help you and am willing to > give you a little more in-depth up close look of how I did things and maybe > even copy/paste it to ya if you e-mail me. ([EMAIL PROTECTED]) > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick St Jean > Sent: Thursday, June 10, 2004 6:33 PM > To: [email protected] > Subject: Re: Quest and files > > I am a bit of a hack and a simpleton, but I just make a quest item for each > of those quests. > I assign v0 as the quest number, and use v1 to track the different events > on the quest. > This means that each quest needs an item, but that is really not a big deal. > Then you do not have to make anything other than a quest object type. > > You would also need to code an mprog in there as well, but it really does > save > a lot of space .. and it will disappear when the player deletes. > > > At 06:43 PM 6/10/2004, you wrote: >>I'd generally not go with the file idea. Just too slow. >>Well, it could work (dbms's do it all the time), just probably not if >>you're a novice with I/O. >>The SQL idea is workable and certainly very flexible, but obviously you >>need a dbms and will have to do a little research if you haven't worked >>with it before. And it would take more hd space and cpu time than the >>unlimited bits method. >> >> >> >>----- Original Message ----- From: <[EMAIL PROTECTED]> >>To: <[email protected]> >>Sent: Wednesday, June 09, 2004 10:29 PM >>Subject: Quest and files >> >> >>>I am going to write my own custom quest code and I was wondering how I > could >>>easily keep track of the quests that players have done. I've decided that > it >>>would be the best way to have a master file that contains all the quests > done >>>by a player. In this file would be a listing of the player name and the > quest >>>number they've completed. When a quest is requested, the file will be > checked >>>and if they are not in the file they can do the quest, but if they are > then >>>they cannot. >>> >>>I am not exactly sure how efficent this will be, or if it'll cause > problems. >>>I don't want to have players become HUGE from the sheer amount of quests >>>that we >>>will be adding in, so I was thinking we can condense it into 1 master > file. >>> >>>Another option I suppose would be to have a secondary quest file, based >>>on the >>>player's name and it won't clutter up the player file. >>> >>>Or something else that you guys could suggest. >>> >>>Thanks. >>> >>>PS: When I write code I try to write in a way that I will learn >>>something. As of >>>right now I suck at file I/O in C so this will be a great learning >>>experience. >>>It does have a reason why I am doing it besides what I've said in my > previous >>>paragraphs. Thanks again! >>> >>> >>> >>>-- >>>ROM mailing list >>>[email protected] >>>http://www.rom.org/cgi-bin/mailman/listinfo/rom >> >> >>-- >>ROM mailing list >>[email protected] >>http://www.rom.org/cgi-bin/mailman/listinfo/rom > > > -- > ROM mailing list > [email protected] > http://www.rom.org/cgi-bin/mailman/listinfo/rom > > > -- > ROM mailing list > [email protected] > http://www.rom.org/cgi-bin/mailman/listinfo/rom -- ROM mailing list [email protected] http://www.rom.org/cgi-bin/mailman/listinfo/rom
