0000531: Lag Compensation for Monsters

(0002661)
TIHan (reporter)
2012-02-21 03:03
edited on: 2012-02-22 01:05

I guess I should mention it here. I've got monster unlagged added. This also might be a cleaner changeset than before hopefully making it easier to use.'https://bitbucket.org/TIHan/tst/changesets/tip/branch(%22unlagged_monsters%22) [^]'

(0002670)
StrikerMan780 (reporter)
2012-02-22 19:47

This won't significantly increase CPU load or bandwidth usage, will it?

(0002674)
TIHan (reporter)
2012-02-22 21:28
edited on: 2012-02-23 01:23

Bandwidth usage, none. Everything done here is entirely server-side. There may be some increased memory. Memory usage will increase for each actor by roughly 436 bytes in theory according to the added properties of the AActor class. So, a good worst case scenario of 20000 actors in game, memory usage will increase roughly 8mb :). (As for CPU, it should have no issues dealing with it, completely unnoticeable.) <- I was ignorant here.

Please correct me if I'm totally missing a concept that I don't know.

(0002675)
Torr Samaho (administrator)
2012-02-23 00:16

> Please correct me if I'm totally missing a concept that I don't know.

If there is something to worry about I'd say it's TThinkerIterator<AActor>. I don't know how well this iterator scales for large amounts of monsters /actors. Try a wad with several thousands of monsters and you should get an impression.

(0002677)
TIHan (reporter)
2012-02-23 01:21

I tested Sunder.wad map08 with about 2600 monsters. CPU with unlagged on, disconnected me from the game as it was using my entire CPU core. This was using the super shotgun with sv_fastweapons set to 2.

Yea this is a big issue. Not exactly sure what I would do. Spleen mentioned back in the day we needed to use some sort of binary tree.

(0002678)
TIHan (reporter)
2012-02-23 03:11

I attempted to use std::set and stored each unlagged actor in it when they spawned. I still get the same issue :(.

(0002679)
TIHan (reporter)
2012-02-23 04:09
edited on: 2012-02-23 05:10

Ok! I fixed the CPU issues. See changeset'https://bitbucket.org/TIHan/tst/changeset/d5a6cd023be2 [^]'

To explain, every single call to P_AimLineAttack and P_LineAttack caused the whole cycle of unlagged to take place. The TThinkerIterator was just getting slammed in such a short amount of time. So if I fired my super shotgun that had 25 puffs of spread - UNLAGGED_Reconcile is going to try to run 25 times in a tic causing all that CPU load.

-- To fix this problem, use UNLAGGED_Reconcile before all the P_LineAttacks get called on a weapon (essentially making UNLAGGED_Reconcile only fire once), then do UNLAGGED_Restore, viola! The only downside to this is that I will have to do this manually for pretty much all the heretic/hexen/strife weapons, and maybe others. But, in this case, performance takes precedence over maintenance.

In sunder map08 analysis (with fastweapons 2 - super shotgun):
-Without unlagged, cpu usage was around 7%-9%.
-With unlagged, cpu usage maxed out at 25% (100% for one core, which halted everything).
-With unlagged optimizations, cpu usage stayed at 11%. =D

(0002680)
Torr Samaho (administrator)
2012-02-23 12:33

> The only downside to this is that I will have to do this manually for pretty much all the heretic/hexen/strife weapons, and maybe others.

This kind of approach can only be a last ditch effort. Before you do this, we should make sure that there really is no other way to do this and decide whether the maintenance nightmare is really worth the benefit.

(0002681)
TIHan (reporter)
2012-02-23 17:40

I'll look into an alternative way. It will have the meet this single criteria: UNLAGGED_Reconcile and UNLAGGED_Restore can only be ran once in a tic.

(0002682)
Torr Samaho (administrator)
2012-02-24 00:30

One thing one could investigate is whether it's feasible to handle the unlagged stuff in server_ClientMove before / after thinking and or ticking the player, independently of which weapon the player is using.

(0002683)
TIHan (reporter)
2012-02-24 03:21
edited on: 2012-02-25 08:32

> One thing one could investigate is whether it's feasible to handle the unlagged stuff in server_ClientMove before / after thinking and or ticking the player, independently of which weapon the player is using.

I'm not sure what you mean here. Can you explain this some more? I don't feel warm and fuzzy by trying to leave the weapon attacks. The best practice for lag compensation seems to center on weapon firing.'https://developer.valvesoftware.com/wiki/Lag_compensation#Invocation [^]' which is very similar to what we are doing now.

I don't think modifying all the weapon attack functions is a maintenance nightmare, but it could be better if we had precise events of weapon firing before and after.

(0002685)
Torr Samaho (administrator)
2012-02-26 00:41
edited on: 2012-02-26 00:42

> The best practice for lag compensation seems to center on weapon'firing.https://developer.valvesoftware.com/wiki/Lag_compensation#Invocation [^]' [^] which is very similar to what we are doing now.

Under this premise you may want to go where the action functions of the weapons are called, i.e. "if (state->CallAction(player->mo, player->ReadyWeapon)" in P_SetPsprite.

In case we need to restrict the unlagged stuff to certain code pointers, you can check there if state->ActionFunc is one of those that need unlagged treatment, e.g. A_FireBullets, and call the unlagged code accordingly. This at least centralizes the changes and just needs the list of code pointers to be updated if new ones are added.

(0002691)
TIHan (reporter)
2012-02-26 20:29

> Under this premise you may want to go where the action functions of the weapons are called, i.e. "if (state->CallAction(player->mo, player->ReadyWeapon)" in P_SetPsprite.

This works! :D Thank you. I'll have to iterate through a list so the ActionFunction gets checked against all possible ActionFunctions.

(0002704)
TIHan (reporter)
2012-02-27 01:44

Here you go! I'm really proud of this. Thank for the help!'https://bitbucket.org/TIHan/tst/changesets/tip/branch(%22unlagged_monsters_new%22) [^]'

It uses a little less CPU than my previous optimization attempt (9%-10% in the sunder map08 super shotgun analysis) and is more maintainable than before.

(0002822)
TIHan (reporter)
2012-03-17 20:37

I've updated the unlagged_monsters_new branch to the latest codebase.

Is there anything that doesn't make you warm and fuzzy with the changes to unlagged? I've been testing this with someone for the past few weeks, we haven't experienced anything out of the ordinary.

(0003234)
TIHan (reporter)
2012-04-13 06:14
edited on: 2012-04-13 07:16

'https://bitbucket.org/TIHan/tst/changeset/b366b6912446 [^]'
Managed to decrease a little more CPU usage, not a whole lot, but noticeable.

Edit:
Did probably the most intense test you could do to ST, besides nuts.wad ( that wad will never work online ;) ).

Sunder map11 has 5000+ 'active'/'non-dormant' monsters. To test this, I combined monster lag compensation and monster bandwidth mitigation to see how it all performed.

I never disconnected. This is with fastweapons 2, infiniteammo, and any of the hitscan weapons being fired. While my CPU was maxing itself out, it was able to hold its own and not disconnect me :)

(0005733)
Watermelon (developer)
2013-01-10 21:45

This may be a bit outdated of a post, but I always wondered if you could use the GLPVS (or even the reject table) to determine if the monster can be seen from the sector the actor is in. While going around corners with high ping will cause some possible problems, at least it'd send a whole lot less data in more closed maps.

(0005735)
Torr Samaho (administrator)
2013-01-11 18:45

0000757 is a better place to discuss how to reduce bandwidth usage. This ticket is about unlagged support for monsters, 0000757 is about monster bandwidth reduction.

(0010398)
Watermelon (developer)
2014-10-09 00:11

Do you know if there's any Tihan links left around? All his are dead and it'd be nice to not have to start this from scratch... though I may not have a choice.

(0010401)
TIHan (reporter)
2014-10-09 01:04

Hey Watermelon,

Unfortunately, I do not have the repository anymore. :(
Though, getting this to work wasn't that bad.
The idea was to only compensate between when the player shot, rather than for each bullet. ex: super shotgun

(0010405)
ZzZombo (reporter)
2014-10-09 03:20
edited on: 2014-10-09 03:21

Quote
In case we need to restrict the unlagged stuff to certain code pointers, you can check there if state->ActionFunc is one of those that need unlagged treatment, e.g. A_FireBullets, and call the unlagged code accordingly. This at least centralizes the changes and just needs the list of code pointers to be updated if new ones are added.

Wouldn't the better place to do such things be A_FireBulletsHelper() in thingdef_codeptr.cpp? Since ultimately all weapon firing functions call it there will be no need in a list of codepointers.

There is also A_CustomFireBullets().

(0010406)
Watermelon (developer)
2014-10-09 03:30

Hi Tihan, I don't know if you're still around -- if you get a free chance and could pop on IRC I'd be glad to talk to you if you remember where you left off ;)
If you're not busy that is. If so, no worries

(0010411)
Torr Samaho (administrator)
2014-10-09 06:07

I think I still have a clone of TIHan's repository. Will check and report back.

(0010413)
Torr Samaho (administrator)
2014-10-09 06:29
edited on: 2014-10-09 06:29

I actually had two old repositories of TIHan. I created a "salvage yard" repository and shoved all of TIHan's code changes in there. I also added AlexMax's gametic unlagged code, since it seems to be gone from his repository. This is the repo.

(0010415)
TIHan (reporter)
2014-10-09 08:56

Watermelon,

I'm not around at all and haven't been in ages; but I'd thought I would pop in just for a bit here. I doubt I'll have time to help. :(

Torr seems to have found most of the code; that should help.

Best wishes to you guys.

(0010423)
Watermelon (developer)
2014-10-09 15:16

Cool code dumps. Time to read.

It's ok Tihan, good luck with your RL endeavors!

(0010605)
Watermelon (developer)
2014-10-15 23:28

Torr (or anyone):
Is there any reason we unlag once for each bullet? It sounds like an insane waste of CPU time. I thought we'd just unlag before firing, and then undo the unlag after the firing function is finished.

There's no way this ticket can proceed until that is done.

Though first I need to know if there's a reason why it was done this way... any known reasons?

(0010627)
Torr Samaho (administrator)
2014-10-18 16:51

Quote from Watermelon
I thought we'd just unlag before firing, and then undo the unlag after the firing function is finished.

If you manage to do this in a centralized manner, please go ahead. The way ZDoom handles the firing, I don't see any feasible way to do this in a centralized manner though. The advantage of the current implementation is that it is properly centralized.

Keep in mind, the actors are only supposed to be unlagged for the purpose of hitscan attacks. For any other game logic aspect, the actors need to be at their true position, not at the unlagged one.

(0010729)
Watermelon (developer)
2014-10-30 03:32

Torr, is there a reason this wasn't implemented:
'https://bitbucket.org/Torr_Samaho/zandronum-misc/commits/1d9c736bff9a5d2dd2b2736334ac41e969fd728e?at=monster_lag_compensation [^]'

I pretty much did exactly what TIHan did and so far it's working great. Is there any reason this wasn't accepted?

What I'll probably do if there's nothing wrong with it... is port it over to 1.4 and update any missing attack functions. That way it'll save me time as well.

(0010791)
Torr Samaho (administrator)
2014-11-02 10:23

This looks pretty much like the solution I suggested you to use (and is also what I already proposed two years ago 0000531:0002685, that's just so long ago I forget we actually already had a prototype for this). So it should be a good staring point. Whether it is good enough to be included has still to be thoroughly tested though.

(0010828)
TIHan (reporter)
2014-11-04 18:21

Watermelon,

To note on that implementation, there was no reason to use a "set". I would either use a "vector" or a fixed array to iterate through the actors.

Only registered users can voice their support. Click here to register, or here to log in.
Supporters:	ZzZombo Combinebobnt unknownna
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2011-07-26 17:03	TIHan	New Issue
2012-02-21 03:03	TIHan	Note Added: 0002661
2012-02-22 01:05	TIHan	Note Edited: 0002661	View Revisions
2012-02-22 19:47	StrikerMan780	Note Added: 0002670
2012-02-22 21:28	TIHan	Note Added: 0002674
2012-02-22 21:29	TIHan	Note Edited: 0002674	View Revisions
2012-02-22 21:34	TIHan	Note Edited: 0002674	View Revisions
2012-02-22 21:36	TIHan	Note Edited: 0002674	View Revisions
2012-02-23 00:16	Torr Samaho	Note Added: 0002675
2012-02-23 01:21	TIHan	Note Added: 0002677
2012-02-23 01:23	TIHan	Note Edited: 0002674	View Revisions
2012-02-23 03:11	TIHan	Note Added: 0002678
2012-02-23 04:09	TIHan	Note Added: 0002679
2012-02-23 05:10	TIHan	Note Edited: 0002679	View Revisions
2012-02-23 12:33	Torr Samaho	Note Added: 0002680
2012-02-23 17:40	TIHan	Note Added: 0002681
2012-02-24 00:30	Torr Samaho	Note Added: 0002682
2012-02-24 03:21	TIHan	Note Added: 0002683
2012-02-24 03:22	TIHan	Note Edited: 0002683	View Revisions
2012-02-25 00:52	TIHan	Note Edited: 0002683	View Revisions
2012-02-25 08:23	TIHan	Note Edited: 0002683	View Revisions
2012-02-25 08:32	TIHan	Note Edited: 0002683	View Revisions
2012-02-26 00:41	Torr Samaho	Note Added: 0002685
2012-02-26 00:42	Torr Samaho	Note Edited: 0002685	View Revisions
2012-02-26 20:29	TIHan	Note Added: 0002691
2012-02-27 01:44	TIHan	Note Added: 0002704
2012-03-17 20:37	TIHan	Note Added: 0002822
2012-04-13 06:14	TIHan	Note Added: 0003234
2012-04-13 07:16	TIHan	Note Edited: 0003234	View Revisions
2012-04-13 07:45	unknownna	Priority	low => normal
2012-04-14 06:11	TIHan	Assigned To	=> TIHan
2012-04-14 06:11	TIHan	Status	new => assigned
2013-01-10 21:45	Watermelon	Note Added: 0005733
2013-01-11 18:45	Torr Samaho	Note Added: 0005735
2014-10-09 00:10	Watermelon	Assigned To	TIHan => Watermelon
2014-10-09 00:11	Watermelon	Note Added: 0010398
2014-10-09 01:04	TIHan	Note Added: 0010401
2014-10-09 03:20	ZzZombo	Note Added: 0010405
2014-10-09 03:21	ZzZombo	Note Edited: 0010405	View Revisions
2014-10-09 03:30	Watermelon	Note Added: 0010406
2014-10-09 06:07	Torr Samaho	Note Added: 0010411
2014-10-09 06:29	Torr Samaho	Note Added: 0010413
2014-10-09 06:29	Torr Samaho	Note Edited: 0010413	View Revisions
2014-10-09 06:29	Torr Samaho	Note Revision Dropped: 10413: 0005625
2014-10-09 08:56	TIHan	Note Added: 0010415
2014-10-09 15:16	Watermelon	Note Added: 0010423
2014-10-15 23:28	Watermelon	Note Added: 0010605
2014-10-15 23:28	Watermelon	Status	assigned => needs review
2014-10-18 16:51	Torr Samaho	Note Added: 0010627
2014-10-18 16:51	Torr Samaho	Status	needs review => feedback
2014-10-25 03:00	Watermelon	Status	feedback => assigned
2014-10-30 03:32	Watermelon	Note Added: 0010729
2014-10-30 03:32	Watermelon	Status	assigned => needs review
2014-11-02 10:23	Torr Samaho	Note Added: 0010791
2014-11-02 10:25	Torr Samaho	Status	needs review => feedback
2014-11-02 19:06	Watermelon	Status	feedback => assigned
2014-11-04 18:21	TIHan	Note Added: 0010828
2014-12-01 13:27	Watermelon	Target Version	=> 1.4
2015-01-06 08:15	Dusk	Target Version	1.4 =>
2016-04-10 19:25	Dusk	Status	assigned => new
2016-04-10 19:26	Dusk	Assigned To	Watermelon =>

Notes
(0002661) TIHan (reporter) 2012-02-21 03:03 edited on: 2012-02-22 01:05	I guess I should mention it here. I've got monster unlagged added. This also might be a cleaner changeset than before hopefully making it easier to use.'https://bitbucket.org/TIHan/tst/changesets/tip/branch(%22unlagged_monsters%22) [^]'

(0002670) StrikerMan780 (reporter) 2012-02-22 19:47	This won't significantly increase CPU load or bandwidth usage, will it?

(0002674) TIHan (reporter) 2012-02-22 21:28 edited on: 2012-02-23 01:23	Bandwidth usage, none. Everything done here is entirely server-side. There may be some increased memory. Memory usage will increase for each actor by roughly 436 bytes in theory according to the added properties of the AActor class. So, a good worst case scenario of 20000 actors in game, memory usage will increase roughly 8mb :). (As for CPU, it should have no issues dealing with it, completely unnoticeable.) <- I was ignorant here. Please correct me if I'm totally missing a concept that I don't know.

(0002675) Torr Samaho (administrator) 2012-02-23 00:16	> Please correct me if I'm totally missing a concept that I don't know. If there is something to worry about I'd say it's TThinkerIterator<AActor>. I don't know how well this iterator scales for large amounts of monsters /actors. Try a wad with several thousands of monsters and you should get an impression.

(0002677) TIHan (reporter) 2012-02-23 01:21	I tested Sunder.wad map08 with about 2600 monsters. CPU with unlagged on, disconnected me from the game as it was using my entire CPU core. This was using the super shotgun with sv_fastweapons set to 2. Yea this is a big issue. Not exactly sure what I would do. Spleen mentioned back in the day we needed to use some sort of binary tree.

(0002678) TIHan (reporter) 2012-02-23 03:11	I attempted to use std::set and stored each unlagged actor in it when they spawned. I still get the same issue :(.

(0002679) TIHan (reporter) 2012-02-23 04:09 edited on: 2012-02-23 05:10	Ok! I fixed the CPU issues. See changeset'https://bitbucket.org/TIHan/tst/changeset/d5a6cd023be2 [^]' To explain, every single call to P_AimLineAttack and P_LineAttack caused the whole cycle of unlagged to take place. The TThinkerIterator was just getting slammed in such a short amount of time. So if I fired my super shotgun that had 25 puffs of spread - UNLAGGED_Reconcile is going to try to run 25 times in a tic causing all that CPU load. -- To fix this problem, use UNLAGGED_Reconcile before all the P_LineAttacks get called on a weapon (essentially making UNLAGGED_Reconcile only fire once), then do UNLAGGED_Restore, viola! The only downside to this is that I will have to do this manually for pretty much all the heretic/hexen/strife weapons, and maybe others. But, in this case, performance takes precedence over maintenance. In sunder map08 analysis (with fastweapons 2 - super shotgun): -Without unlagged, cpu usage was around 7%-9%. -With unlagged, cpu usage maxed out at 25% (100% for one core, which halted everything). -With unlagged optimizations, cpu usage stayed at 11%. =D

(0002680) Torr Samaho (administrator) 2012-02-23 12:33	> The only downside to this is that I will have to do this manually for pretty much all the heretic/hexen/strife weapons, and maybe others. This kind of approach can only be a last ditch effort. Before you do this, we should make sure that there really is no other way to do this and decide whether the maintenance nightmare is really worth the benefit.

(0002681) TIHan (reporter) 2012-02-23 17:40	I'll look into an alternative way. It will have the meet this single criteria: UNLAGGED_Reconcile and UNLAGGED_Restore can only be ran once in a tic.

(0002682) Torr Samaho (administrator) 2012-02-24 00:30	One thing one could investigate is whether it's feasible to handle the unlagged stuff in server_ClientMove before / after thinking and or ticking the player, independently of which weapon the player is using.

(0002683) TIHan (reporter) 2012-02-24 03:21 edited on: 2012-02-25 08:32	> One thing one could investigate is whether it's feasible to handle the unlagged stuff in server_ClientMove before / after thinking and or ticking the player, independently of which weapon the player is using. I'm not sure what you mean here. Can you explain this some more? I don't feel warm and fuzzy by trying to leave the weapon attacks. The best practice for lag compensation seems to center on weapon firing.'https://developer.valvesoftware.com/wiki/Lag_compensation#Invocation [^]' which is very similar to what we are doing now. I don't think modifying all the weapon attack functions is a maintenance nightmare, but it could be better if we had precise events of weapon firing before and after.

(0002685) Torr Samaho (administrator) 2012-02-26 00:41 edited on: 2012-02-26 00:42	> The best practice for lag compensation seems to center on weapon'firing.https://developer.valvesoftware.com/wiki/Lag_compensation#Invocation [^]' [^] which is very similar to what we are doing now. Under this premise you may want to go where the action functions of the weapons are called, i.e. "if (state->CallAction(player->mo, player->ReadyWeapon)" in P_SetPsprite. In case we need to restrict the unlagged stuff to certain code pointers, you can check there if state->ActionFunc is one of those that need unlagged treatment, e.g. A_FireBullets, and call the unlagged code accordingly. This at least centralizes the changes and just needs the list of code pointers to be updated if new ones are added.

(0002691) TIHan (reporter) 2012-02-26 20:29	> Under this premise you may want to go where the action functions of the weapons are called, i.e. "if (state->CallAction(player->mo, player->ReadyWeapon)" in P_SetPsprite. This works! :D Thank you. I'll have to iterate through a list so the ActionFunction gets checked against all possible ActionFunctions.

(0002704) TIHan (reporter) 2012-02-27 01:44	Here you go! I'm really proud of this. Thank for the help!'https://bitbucket.org/TIHan/tst/changesets/tip/branch(%22unlagged_monsters_new%22) [^]' It uses a little less CPU than my previous optimization attempt (9%-10% in the sunder map08 super shotgun analysis) and is more maintainable than before.

(0002822) TIHan (reporter) 2012-03-17 20:37	I've updated the unlagged_monsters_new branch to the latest codebase. Is there anything that doesn't make you warm and fuzzy with the changes to unlagged? I've been testing this with someone for the past few weeks, we haven't experienced anything out of the ordinary.

(0003234) TIHan (reporter) 2012-04-13 06:14 edited on: 2012-04-13 07:16	'https://bitbucket.org/TIHan/tst/changeset/b366b6912446 [^]' Managed to decrease a little more CPU usage, not a whole lot, but noticeable. Edit: Did probably the most intense test you could do to ST, besides nuts.wad ( that wad will never work online ;) ). Sunder map11 has 5000+ 'active'/'non-dormant' monsters. To test this, I combined monster lag compensation and monster bandwidth mitigation to see how it all performed. I never disconnected. This is with fastweapons 2, infiniteammo, and any of the hitscan weapons being fired. While my CPU was maxing itself out, it was able to hold its own and not disconnect me :)

(0005733) Watermelon (developer) 2013-01-10 21:45	This may be a bit outdated of a post, but I always wondered if you could use the GLPVS (or even the reject table) to determine if the monster can be seen from the sector the actor is in. While going around corners with high ping will cause some possible problems, at least it'd send a whole lot less data in more closed maps.

(0005735) Torr Samaho (administrator) 2013-01-11 18:45	0000757 is a better place to discuss how to reduce bandwidth usage. This ticket is about unlagged support for monsters, 0000757 is about monster bandwidth reduction.

(0010398) Watermelon (developer) 2014-10-09 00:11	Do you know if there's any Tihan links left around? All his are dead and it'd be nice to not have to start this from scratch... though I may not have a choice.

(0010401) TIHan (reporter) 2014-10-09 01:04	Hey Watermelon, Unfortunately, I do not have the repository anymore. :( Though, getting this to work wasn't that bad. The idea was to only compensate between when the player shot, rather than for each bullet. ex: super shotgun

(0010405) ZzZombo (reporter) 2014-10-09 03:20 edited on: 2014-10-09 03:21	Quote In case we need to restrict the unlagged stuff to certain code pointers, you can check there if state->ActionFunc is one of those that need unlagged treatment, e.g. A_FireBullets, and call the unlagged code accordingly. This at least centralizes the changes and just needs the list of code pointers to be updated if new ones are added. Wouldn't the better place to do such things be A_FireBulletsHelper() in thingdef_codeptr.cpp? Since ultimately all weapon firing functions call it there will be no need in a list of codepointers. There is also A_CustomFireBullets().

(0010406) Watermelon (developer) 2014-10-09 03:30	Hi Tihan, I don't know if you're still around -- if you get a free chance and could pop on IRC I'd be glad to talk to you if you remember where you left off ;) If you're not busy that is. If so, no worries

(0010411) Torr Samaho (administrator) 2014-10-09 06:07	I think I still have a clone of TIHan's repository. Will check and report back.

(0010413) Torr Samaho (administrator) 2014-10-09 06:29 edited on: 2014-10-09 06:29	I actually had two old repositories of TIHan. I created a "salvage yard" repository and shoved all of TIHan's code changes in there. I also added AlexMax's gametic unlagged code, since it seems to be gone from his repository. This is the repo.

(0010415) TIHan (reporter) 2014-10-09 08:56	Watermelon, I'm not around at all and haven't been in ages; but I'd thought I would pop in just for a bit here. I doubt I'll have time to help. :( Torr seems to have found most of the code; that should help. Best wishes to you guys.

(0010423) Watermelon (developer) 2014-10-09 15:16	Cool code dumps. Time to read. It's ok Tihan, good luck with your RL endeavors!

(0010605) Watermelon (developer) 2014-10-15 23:28	Torr (or anyone): Is there any reason we unlag once for each bullet? It sounds like an insane waste of CPU time. I thought we'd just unlag before firing, and then undo the unlag after the firing function is finished. There's no way this ticket can proceed until that is done. Though first I need to know if there's a reason why it was done this way... any known reasons?

(0010627) Torr Samaho (administrator) 2014-10-18 16:51	Quote from Watermelon I thought we'd just unlag before firing, and then undo the unlag after the firing function is finished. If you manage to do this in a centralized manner, please go ahead. The way ZDoom handles the firing, I don't see any feasible way to do this in a centralized manner though. The advantage of the current implementation is that it is properly centralized. Keep in mind, the actors are only supposed to be unlagged for the purpose of hitscan attacks. For any other game logic aspect, the actors need to be at their true position, not at the unlagged one.

(0010729) Watermelon (developer) 2014-10-30 03:32	Torr, is there a reason this wasn't implemented: 'https://bitbucket.org/Torr_Samaho/zandronum-misc/commits/1d9c736bff9a5d2dd2b2736334ac41e969fd728e?at=monster_lag_compensation [^]' I pretty much did exactly what TIHan did and so far it's working great. Is there any reason this wasn't accepted? What I'll probably do if there's nothing wrong with it... is port it over to 1.4 and update any missing attack functions. That way it'll save me time as well.

(0010791) Torr Samaho (administrator) 2014-11-02 10:23	This looks pretty much like the solution I suggested you to use (and is also what I already proposed two years ago 0000531:0002685, that's just so long ago I forget we actually already had a prototype for this). So it should be a good staring point. Whether it is good enough to be included has still to be thoroughly tested though.

(0010828) TIHan (reporter) 2014-11-04 18:21	Watermelon, To note on that implementation, there was no reason to use a "set". I would either use a "vector" or a fixed array to iterate through the actors.

Relationships