I'll let you know a secret, I suck with C too... :)
----- Original Message -----
From: "Boh-Ahz" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, December 04, 2002 11:15 PM
Subject: More on Delayed Progs
> I want to quick thank everyone who posted when I asked about this the
> first time (a couple weeks back). Unfortunately, I'm still having some
> problems.
>
> Here is a quick rehash of what I would like to do. I would like to
> implement delays in progs such that the program would continue where it
> left off after a certain, builder defined, delay (just a quick fyi, I'm
> using mobprogs by Newt and obj and room prog additions by Ralgha). For
> example:
>
> say Hello.
> delay 2
> say Nice day isn't it.
>
> When the prog executes, the mob would say "Hello.", there would be a 2
> second delay, and then it would say "Nice day isn't it."
>
> Now, conceptually this seems pretty simple from the answers you all gave
> me previously (though this is obviously a little simplified). Copy the
> prog code somewhere (I am thinking that doing this right in the
> char_data object may be a good idea). To do this, I was thinking that a
> new struct might be in order, which would hold the prog code as well as
> a pointer to the line directly after the "delay" line (and possibly some
> other program_flow originating variables)(this saves me from having to
> modify all the previous code in order to reach that execution line, I'm
> not the best with C style char array manipulation so I stay away from
> that as much as possible). Once the delay is over, load up the new code
> struct and let it rip.
Heres some of the main problems with this...
if check_thats_true
make_check_false
delay #
do_blah
else
do_blah
endif
>
> My main concern is that I may have to have a special program_flow type
> method to finish things off, though in the best case I will be able to
> make some minor modifications to program_flow. The unfortunate point is
> that I am having a difficult time really understanding program_flow, and
> am therefore having a problem coming up with a solid design.
>
Program flow is a monster of a function. I spent a very long time, merely
following the code and figuring our what it did.
actually its done in ways that are specifically hard to read, for example
all that guck in the beginning with As, Bs, Cs and Ds,
is actually very similar to one_argument()
> So, what is it that I'm really asking? First, does the brief
> explanation above seem to make sense? Just one more clarification, I
> was planning removing/modifying the current 'delay' prog to handle the
> timing issues, and rather than triggering a different prog altogether,
> it would pick up where it left off.
>
I removed the delay trigger too. See blow for some problems to the concept.
> I guess the next would be if anyone would be willing to help more of a
> one on one basis if I continue to have problems. I don't want to spam
> the list with particulars that most are going to care nothing about.
Give me a personal email, or a aim (ParagonII) if you still want/need help,
I'd be glad.
>
> Thanks for your time.
>
> Boh
>
>
> --
> ROM mailing list
> [email protected]
> http://www.rom.org/cgi-bin/mailman/listinfo/rom
Alright, look at the mobprog above... if you get into the delay, it will
give you serious conceptual problems, when you
just poiunt to a specific line and say, "go from here" because of the way
nested levels and such work.
program grabs a line and checks it for if/else/and/or
then it checks in cmd_eval whether the if is true, or if the if on the
nested level is true it doesnt do the else etc...
if its not an fi/else whatever, and the current nested level is set TRUE,
then it just does the command.
now the only things you need to worry about are the if/else stuff.
the code string will have all the rest of the prog, you need to worry about
the ifs...
if(the_nested_level == TRUE)
strcpy(if true)
else
strcpy(if false)
thats what I did, and I'm sure theres better ways of doing it, for ands/ors
i merely erased the last if, then
redid it whether to 'go' or not, that way it knows what level its on, and
such. not you could mess with all
the nested level stuff if you really wanted, but I dont know how to do that
without sitting down and having
an intimate candle light dinner with program_flow.
where it does the checks for "if" and such, merely add a check for "delay"
under that add:
delay = new_delay()
strcat(new_code, code);
delay->mob = mob
delay->ch = ch
delay->everything_else = everything_else
then set the delay somehow, in update.c, check to make sure the CH doesnt
quit/move and your in buisness
No, its not that simple, but its a start.
Oh btw... dont paste that code, I did above, i heard it has some nasty parse
errors;)
Paragon
