25 Jul, 2009, boblinski wrote in the 1st comment:
Votes: 0
Currently, trip & bash both set the victims position to POS_RESTING… that's what I -want- to happen..

However, when I try to "stand" the victim char up.. it says "You are already standing."

I think this is because the combat code keeps setting the fighters position to POS_FIGHTING..

What problems will I encounter if I remove the reset to POS_FIGHTING?

Has anyone done this? I'm using QuickMUD.

Thanks,
Bob.
25 Jul, 2009, ATT_Turan wrote in the 2nd comment:
Votes: 0
Instead of doing something that might have repercussions beyond what you intend or desire (such as people getting the stuffing beaten out of them while sleeping and not knowing any better), why not change the functionality of trip and bash?

If they currently put the victim to POS_RESTING and don't stop combat, then they're probably making your next hit on the victim have no chance of missing - check that out. If they put them to POS_RESTING and do stop combat, then knocking them out of combat is the intended effect of the skill and if you want something different (such as combat continuing but the victim being defenseless for a period of time), then you want to change the functionality of the skill instead of the functionality of POS_RESTING.

On one code I ran, giving a character a WAIT_STATE prevented them from making attacks in combat (I don't remember if this is default functionality, and I would be polite and look it up but I have to get dressed and go to work). Therefore, tripping/bashing/groin-kicking people in combat would give them a certain number of rounds of WAIT_STATE in which their defenses were reduced and their own combat abilities nullified. It sounds like you might be wanting to do something like this.
25 Jul, 2009, Ssolvarain wrote in the 3rd comment:
Votes: 0
Trip and bash have 2 main points.

A) Take advantage of "pos_resting" ac deductions.
B) Force the character to a state where their commands will not work without taking the time to stand.

It's worked out on a few muds I've played, but the unanimous solution to this is to trigger "stand". Sort of boring and silly.
25 Jul, 2009, ATT_Turan wrote in the 4th comment:
Votes: 0
Ssolvarain said:
Trip and bash have 2 main points.

A) Take advantage of "pos_resting" ac deductions.
B) Force the character to a state where their commands will not work without taking the time to stand.

It's worked out on a few muds I've played, but the unanimous solution to this is to trigger "stand". Sort of boring and silly.


It appears from boblinski's original post that B) does not apply, as his commands sound like they don't stop combat and the next hit automatically stands them up. I maintain that these commands should either work as they do for him, where it simply gives your next attack bonuses against the target, or through a mechanic other than POS_RESTING since that is, as you say, boring and silly. :smile:
25 Jul, 2009, Ssolvarain wrote in the 5th comment:
Votes: 0
I hate when people are being right.
26 Jul, 2009, boblinski wrote in the 6th comment:
Votes: 0
The function works fine.. except I want to make the "auto-stand-up" stop happening.. however, by doing this.. will it cause problems with the rom combat system?
26 Jul, 2009, Runter wrote in the 7th comment:
Votes: 0
boblinski said:
The function works fine.. except I want to make the "auto-stand-up" stop happening.. however, by doing this.. will it cause problems with the rom combat system?


Seems to be problematic since I think rom sets it to pos_fighting anytime damage is dealt.
26 Jul, 2009, boblinski wrote in the 8th comment:
Votes: 0
Could I just remove that line of the code in damage()?

Or would that stuff other things up?
26 Jul, 2009, Runter wrote in the 9th comment:
Votes: 0
boblinski said:
Could I just remove that line of the code in damage()?

Or would that stuff other things up?


I don't know, but I have to assume it sets it for a reason. Perhaps for determining if certain commands can be used? (out of combat?)
26 Jul, 2009, Sandi wrote in the 10th comment:
Votes: 0
if (victim->timer <= 4 && victim->daze < 1 && victim->wait < 1)
victim->position = POS_FIGHTING;

Seems to work fine for me. Then again, my codebase is rather far from ROM at this point. It may create balance problems, making 'bash' too effective, but it may be worth balancing things out. Seeing a player resting in the middle of a fight might seem odd, however.
26 Jul, 2009, boblinski wrote in the 11th comment:
Votes: 0
What do -wait- and -daze- do exactly (what's the difference)? And how to I set them?
26 Jul, 2009, Runter wrote in the 12th comment:
Votes: 0
boblinski said:
What do -wait- and -daze- do exactly (what's the difference)? And how to I set them?
'

I think the difference is wait state lags input while daze state only may affect the success of some skills/rolls.
26 Jul, 2009, Kline wrote in the 13th comment:
Votes: 0
WAIT_STATE is that "artificial lag" you experience in most Diku-based games. Rather than put skills on timers or anything else, all commands just delay the processing of subsequent commands by a certain value. In most games 4 WAIT_STATE pulses is about 1 second due to the default PULSE_PER_SEC of the game.
26 Jul, 2009, Runter wrote in the 14th comment:
Votes: 0
I think they are set with SET_WAIT and SET_DAZE
27 Jul, 2009, Sandi wrote in the 15th comment:
Votes: 0
'wait' keeps players from spamming combat skills, while 'daze' gives the victim pause.

See do_bash for examples.

Kline is right, 'wait' causes the game loop to bail before commands are processed, a rather brute force method that also restricts OOC commands like WHO and channels. Note also that 'wait' is decremented in the game loop for players, in update_violence for mobs.
11 Aug, 2009, Elervan wrote in the 16th comment:
Votes: 0
Not sure if this would help but couldn't you do this?

in one_hit or the fighting part put a check for:

if (!victim->bashed)
ch->position = POS_FIGHTING;


then in do_bash after POS_RESTING; put

victim->bashed = TRUE;


I think I saw that piece somewhere before, not sure where. But it allowed the player to have to type "stand" to stand back up. However, after a fight was over the player auto-stood.
11 Aug, 2009, Tyche wrote in the 17th comment:
Votes: 0
The design is simply not adequate for what you wish to do.
Position is a single state. In order to allow multiple states,
you either have to use separate fields to track them, or
change position to allow multiple states (bit field).
Then modify the code to handle combination of states.
11 Aug, 2009, boblinski wrote in the 18th comment:
Votes: 0
What if I made an affect like.. AFF_DOWN for bash, trip tsunami etc.. Then just check..

if (!IS_AFFECTED (victim, AFF_DOWN))
ch->position = POS_FIGHTING;
11 Aug, 2009, Hades_Kane wrote in the 19th comment:
Votes: 0
boblinski said:
What if I made an affect like.. AFF_DOWN for bash, trip tsunami etc.. Then just check..

if (!IS_AFFECTED (victim, AFF_DOWN))
ch->position = POS_FIGHTING;


You could try it, but I think ultimately without rewriting the way the skills work or the way your combat works, you'll just be hacking together a sloppy solution. What might be better, if you are adding an affect specifically for the skill, is rather than making the character change position, have the affect otherwise mirror whatever things you are trying to accomplish by having the character being on the ground. Such as, maybe have the down affect reduce the hitroll of the character (or prevent them from attacking), make them considered prone and thus have lower evasion or armor class, restrict their use of certain manual skills (like bash, trip ought to work when on the ground), make it so that when the affect wears off they get a "You stand back up" message, make stop_fighting remove the affect, and probably have the timer on the skill not based on ticks, but rather have it decrease in your combat rounds (you can use the level or modifier value well like this)… Afterall, just because I'm knocked on my butt doesn't mean I wouldn't be still be fighting to some degree, just at a much lesser capacity.

Anyway, that's something to think about (and might be something I'll be considering, having fleshed out the idea in this suggestion :p )
11 Aug, 2009, Sandi wrote in the 20th comment:
Votes: 0
I just realised it works for me because I use a fighter_list. Like the char_list, but only for fighters, so the violence_update doesn't suck up so much cpu time. Hence, you're fighting if you're on the list regardless of your position.

I'd recommend a fighter_list for its own sake, and this is just a happy side effect. ;)
0.0/28