Sorry for the double post, this is just in response to the previous mail.
The way that I tell immortals to do it, is to go ahead and add if checks in
there for the steps. Always add an if check before setting the character to
the next step:
if zqstep $n 2 // are they on the second step?
Mob zqstep $n 3 // set em on the third step!
Else
// they aren't on the second step, so they shouldn't advance to the
third step.
As well as with finishing the quest....
If it's a 5 part quest, before the mob zqfinish, make a check for their
step, if they aren't on step 5, then how could they have done the quest?
It's really about getting the immortals to write in their mobprog code to
prevent those kind of things.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Hill
Sent: Thursday, June 10, 2004 9:37 PM
To: [email protected]
Subject: Re: Quest and files
You know, that's kind of a fun, neat way of doing it. I applaud your
creativity. Saves a shitton of behind-the-scenes code, can use existing
mobprog code to check stuff, etc.
Only problem I could see is someone could drop the item to play the
quest again or give it to someone else to give them a head start. Would
take a little bit of code to ensure once a person has an item, they will
have it forever. How do you do this without having inventories full of
quest items?
-- Jeremy
Rick St Jean wrote:
> 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
