View Issue Details

IDProjectCategoryView StatusLast Update
0000234LDMud 3.5Runtimepublic2011-03-01 18:41
ReporterlarsAssigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status feedbackResolutionopen 
Summary0000234: Faster callouts
DescriptionShort: Faster callouts
From: "Dale Perkins" <elric@lpmud.com>
Date: 00/11/16
Type: Feature
State: New


I will make the diff, shoudl I email it to you or set it somewhere you can
ftp it from?
I just finished changing it so it will work on the new ldmud-23dev238
driver, there are a couple
of warnings but they may be warnings that show up anyways when compiling on
freebsd, I'm not sure. The code for fast_call_out is a bit of a cludge, I
just copied new_call_out to new_fast_call_out
and in new_call_out multiplied the time by 10. I didn't do much (translate
as any) documentation so let me explain a few things that might appear odd.
of to add tenths of a second to the tv_sec time you times tv_sec by 10 then
add tv_usec/100,000 but then its too big, so i added another variable called
big_time which is 90,000,000 hmm its always that i could prolly just define
it as that and remove that computation. Anyways the variable current_time is
now 10ths of seconds since teh epoch - 90 million. I fixed the efun time()
to get secs again but I still need to fix timestamp (actually I just
realized that i didnt) timestamps say its 1993 ;) ahh the good ol days :) hm
find_call_out, I have no idea what to do here. fast_call_outs and call_outs
are all together and there is no real way to tell them apart so
find_call_out returns 10ths of seconds left till its called

As for machine load, well i have been using the 'top' command and it still
doesnt even register as 1%
of cpu (an AMD K6-200) while using a slightly modified 2.4.5 lib and I am
not sure of any otehr way to test its usage.

Ok, this email is a mess, never write email while under the influence of
cold medicine, although coding this way is kinda neat ;'p

Elric
TagsNo tags attached.

Activities

2004-11-27 01:12

 

p-010707.gz (3,267 bytes)

zesstra

2009-10-02 10:04

administrator   ~0001422

Ok, the implementation here seems to a bit chaotic. But I suggest to decide first, if there is need enough for call_outs with a 0.1s delay. I am sceptical.

Gnomi

2009-10-05 09:18

manager   ~0001453

There is a discussion on this on lpmuds.net:
http://lpmuds.net/forum/index.php?topic=1004.0

I would not oppose this, but it's not a high priority for me.

zesstra

2009-10-05 10:04

administrator   ~0001457

I skimmed the linked thread and have some comments concerning the proposed combat use:
a) 1s delays are possible
b) anything less separated than 0.5s is basically simultaneous for me as player and even that is difficult to read, if there comes a bunch of text every 0.5s.
c) in case of 0.1s resolution between combat actions, combat gets chaotic if players have a latence of more than 0.1s second between them and the mud.

Gnomi

2009-10-05 10:41

manager   ~0001459

I don't know whether I'd use subsecond call_outs in our MUD (because of these reasons). But when somebody else wants to use them it's his decision...

zesstra

2009-10-05 11:16

administrator   ~0001461

Well sure. Once it is there, certainly. But its your, Fuchurs or my task to code and maintain it. ;-) And that requires that at least the one of us who does it, is convinced of the idea and really wants to do it. I am just trying to estimate the usefulness for the majority of muds.

BTW: There are two things to this:
a) allow callouts with delays < 1s
b) process callouts more often. Example:
call_out("fun1",1); // time 0.0s
...
call_out("fun2",1); // time 0.4s
So then fun1 should be called at 1.0s, fun2 and 1.4s, but in practice they are called a 1s and 2s and the two don't have 0.4s delay between them but 1s.

Coogan

2011-02-24 01:05

reporter   ~0002029

To cite Zesstra from above:

c) in case of 0.1s resolution between combat actions, combat gets chaotic if players have a latence of more than 0.1s second between them and the mud.

In case of a huge combat action where several players or/and NPCs are involved the combat actions better shall be delayed so one does not miss the really important parts of the scrolling text.

For my opinion, I do not support callouts with fractions of seconds.

nik

2011-03-01 18:41

reporter   ~0002046

MMORPGs generally operate on sub-second resolution for everything and I agree that it is a tricky subject in combination with latency. So there might be little reasons to move lower than 1 second. It could be nice to have 1.5 seconds, though.

I can imagine some use for higher callout resolution:
- WoW-style haste modificators that apply cast time modifications in the percent range
- Adapting the combat round duration to your combat system design (maybe 2.5 seconds would be ideal...)
- Remove round-based combat entirely
- Periodic damage / healing with combat-round-independent timing
- Shorten the delay of a periodic event with each repetition (e.g. slowly enraging enemies which do something increasingly often).

It generally could give game designers more tools.

On the other hand, I personally do not see something like this in the short to middle term in our mud and it would require at least some (fairly mechanizable) checking of all legacy mudlib code.

Issue History

Date Modified Username Field Change
2004-11-26 23:39 lars New Issue
2004-11-27 01:12 lars File Added: p-010707.gz
2009-10-02 10:04 zesstra Note Added: 0001422
2009-10-02 10:04 zesstra Status new => feedback
2009-10-05 09:18 Gnomi Note Added: 0001453
2009-10-05 10:04 zesstra Note Added: 0001457
2009-10-05 10:41 Gnomi Note Added: 0001459
2009-10-05 11:16 zesstra Note Added: 0001461
2009-10-27 08:56 zesstra Project LDMud => LDMud 3.5
2011-02-24 01:05 Coogan Note Added: 0002029
2011-03-01 18:41 nik Note Added: 0002046