View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000234 | LDMud 3.5 | Runtime | public | 2004-11-26 22:39 | 2011-03-01 17:41 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | feedback | Resolution | open | ||
| Summary | 0000234: Faster callouts | ||||
| Description | Short: 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 | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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... |
|
|
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. |
|
|
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. |
|
|
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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-11-26 22:39 |
|
New Issue | |
| 2004-11-27 00:12 |
|
File Added: p-010707.gz | |
| 2009-10-02 08:04 | zesstra | Note Added: 0001422 | |
| 2009-10-02 08:04 | zesstra | Status | new => feedback |
| 2009-10-05 07:18 | Gnomi | Note Added: 0001453 | |
| 2009-10-05 08:04 | zesstra | Note Added: 0001457 | |
| 2009-10-05 08:41 | Gnomi | Note Added: 0001459 | |
| 2009-10-05 09:16 | zesstra | Note Added: 0001461 | |
| 2009-10-27 07:56 | zesstra | Project | LDMud => LDMud 3.5 |
| 2011-02-24 00:05 | Coogan | Note Added: 0002029 | |
| 2011-03-01 17:41 | nik | Note Added: 0002046 |
