Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
Bug in will_fall( )
Oct 23, 2017, 1:35 am
By GatewaySysop
Bug in do_zap( ), do_brandish( )
Oct 18, 2017, 1:52 pm
By GatewaySysop
Bug in get_exp_worth( )
Oct 10, 2017, 1:26 am
By GatewaySysop
Bug in do_drag( )
Oct 8, 2017, 12:40 am
By GatewaySysop
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Memwatch
Author: Johan Lindh
Submitted by: Vladaar
Beastmaster 6D sound files
Author: Vladaar
Submitted by: Vladaar
Users Online
CommonCrawl, Yandex, Yahoo!, DotBot

Members: 0
Guests: 4
Stats
Files
Topics
Posts
Members
Newest Member
476
3,704
19,231
608
LAntorcha
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

Xorith
The Null Value
GroupAFKMud Team
Posts254
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

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Eek!

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 >>