User Name:


Forgot your password?
Vote for Us!
tintin++ ogg sound player script for linux
Author: Robert Smith
Submitted by: Vladaar
6Dragons ogg Soundpack
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.4
Author: Vladaar
Submitted by: Vladaar
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
Users Online

Members: 0
Guests: 29
Newest Member
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » AFKMud Support & Development » Skill Round Time
Forum Rules | Mark all | Recent Posts

Skill Round Time
< Newer Topic :: Older Topic > An idea made reality

Pages:<< prev 1 next >>
Post is unread #1 May 19, 2003, 7:33 am
Go to the top of the page
Go to the bottom of the page

The Null Value
GroupAFKMud Team
JoinedFeb 23, 2003

I posted in the idea forum about the possibility of moving skill beats to a seperate counter away from wait state. The reason was that what the waitstate does is just delay the character's input. In code, if a character has a waitstate, then the game_loop just waits to parse the player's input. What I've done is created a round_time. The game_loop decriments it, but it does not stop it from processing commands. Instead, I've also modified the skills and spells to apply the correct round_time (skill[gsn]->beats) to the player, and also check to see if a player has a round_time.

I've noticed though that some skills didn't apply a waitstate before, thus I didn't change it now. These skills include some of the various 'Blade' skills, except Deathblade. Curious, was this intentional?

Now the point of this post. First, would anyone be interested in the work I've done to accomplish this, and second - Do you think it's more worthwhile to put a 'Roundtime' in the actual command setting? Meaning: cedit kick roundtime 10 would apply 10 seconds of roundtime every time it's used, regardless of what the skill has set. Perhaps there could be a way to check what the skill currently has and keep them equal? Or perhaps I could just keep it all hard-coded and force creators of new skills to put the hard-coded checks in themselves? What do you think?
(Note: In theory, commands that don't rely on round_time would have a round_time of -1. Commands that would be disallowed if a player had round_time, but did not give round_time would be set to 0, and any number higher would be the number of rounds to make a player wait for recovery)

Input welcomed
Post is unread #2 Jun 3, 2003, 2:02 pm
Go to the top of the page
Go to the bottom of the page

JoinedMar 8, 2005


Came at this from the other forum... sooo.... go check that one!

In brief, my idea was to not just ignore command for the entire wait_state period, but to queue them up and show you the list of pending commands (and their time-to-fire as it were).

Commands that don't deal with the game world as actions (score, ansi, tell, etc...) would be executed immediately (perhaps -1 being the trigger for that). Now that I think about it, you could tie some of these into the event system as well, in case you wanted the command to run as a callback, but still impose the limitation on the player's actions.

IE: cast 'cause disease' smurf

could print a message, but automatically be shoved WAIT_STATE/2 ticks onto the queue with a WAIT_STATE of the original WS/2+1 (half the delay is in casting, half in recovery?)

I guess that would mean you'd have a startable_time, before which commands don't run but stay queued (with lower cost commands being able to run before them), and a wait_state timer as well... anyways, check the other posting too
Pages:<< prev 1 next >>