Anonymous | Login | Signup for a new account | 2024-04-23 10:06 UTC |
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0002607 | Zandronum | [All Projects] Bug | public | 2016-02-01 00:21 | 2018-04-20 07:09 | ||||
Reporter | unknownna | ||||||||
Assigned To | Edward-san | ||||||||
Priority | urgent | Severity | major | Reproducibility | always | ||||
Status | resolved | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | 3.0-beta | ||||||||
Target Version | 3.1 | Fixed in Version | 3.1 | ||||||
Summary | 0002607: Weapon sync regression in 3.0 | ||||||||
Description | Sorry for opening up another can of worms here, but the weapon synchronization is badly broken in 3.0 again. IIRC, we fixed this in 2.1.2, but there were some issues with 3.0 that we put on hold. | ||||||||
Steps To Reproduce | * Gamer's Proxy : combined ping at 140 1. zandronum -iwad doom2.wad -host +sv_cheats 1 +sv_nomonsters 1 +sv_infiniteammo 1 2. Connect a client to the server with an emulated ping of 140 3. Join the game. 4. "give all" in the console. 5. Select between the chaingun and rocket launcher using weapprev/weapnext while rapidly pressing +attack, sometimes allowing the rocket launcher to fire a rocket. It will desync very quickly. Demo zandronum -iwad doom2.wad -playdemo 3.0_weapondesync.cld | ||||||||
Additional Information | I tested this with Zandronum 3.0-alpha-160131-2023. | ||||||||
Attached Files | 3.0_weapondesync.cld [^] (46,325 bytes) 2016-02-01 00:21 3.0_wepdesync_predict-off.cld [^] (59,643 bytes) 2016-04-15 06:58 3.0_wepdesync-71e5da2.cld [^] (108,836 bytes) 2016-06-07 01:13 3.0_wepdesync-473098b.cld [^] (127,064 bytes) 2016-06-07 01:14 3.0_wepdesync-756ec0a.cld [^] (284,106 bytes) 2016-06-07 16:39 3.0_wepdesync-756ec0a-predict-off.cld [^] (180,222 bytes) 2016-06-07 18:22 serverlog.txt__2016_06_07-12_05_36.log [^] (1,785 bytes) 2016-06-07 19:08 | ||||||||
Relationships | ||||||
|
Notes | |
(0014297) Torr Samaho (administrator) 2016-02-02 07:10 |
Does anybody know in which revision of 3.0 this started? |
(0014704) WaTaKiD (updater) 2016-04-13 01:38 |
ive narrowed it down to this commit as the cause:'https://bitbucket.org/Torr_Samaho/zandronum/commits/b42e043b67dd74442f4f5a293f3a8e89afead53b [^]' |
(0014705) Edward-san (developer) 2016-04-13 10:17 edited on: 2016-04-13 10:28 |
I guess the problem is caused by this specific commit. I'd like to mention that graf partially reverted that with this commit (which is, the standard weapons are fixed. not the customized ones). |
(0014717) Torr Samaho (administrator) 2016-04-15 06:30 edited on: 2016-04-15 06:31 |
Can you check whether the desync still happens if you set "cl_predict_players 0" on the client? If not, it's very likely that our player prediction needs to be adjusted to the ZDoom fix in question. Would also be great if you record a client side demo of the effect with the latest 3.0 version, i.e. changeset c4104ac76a0549c2bcb039384d7cb8bdc9b75b0b. |
(0014718) WaTaKiD (updater) 2016-04-15 07:00 edited on: 2016-04-15 07:00 |
attached a roughly 30 sec demo using changeset c4104ac (build here:'https://www.dropbox.com/s/udt5f65qz6pt2ek/zandronum-3.0-r160403-2002-c4104ac-windows.zip?dl=0 [^]' ) the server had sv_useticbuffer 1 and the client had cl_predict_players 0, desync was still reproducable |
(0014775) Edward-san (developer) 2016-04-30 17:02 |
The fix was ported in zandronum-zdoom-sync with this changeset, but the change must be propagated to the function A_CustomFireBullets ( probably with a new bool parameter 'calledbystockdoomweapon' ). |
(0014808) Torr Samaho (administrator) 2016-05-03 19:18 |
After a closer look, I'm not sure whether this fix applies to our handling of the stock weapons. A_CustomFireBullets does not even call P_SetPsprite. Our way should be equivalent to replacing the stock weapon function, e.g. A_FireShotgun, with A_FireBullets followed by A_GunFlash. Does the latter combination work properly in ZDoom? |
(0014809) Edward-san (developer) 2016-05-04 00:18 |
No idea, but then I saw the A_GunFlash code and tried this approach. Does this commit help at all with the desync? |
(0014810) WaTaKiD (updater) 2016-05-04 00:18 |
i dont know if its too early or not, but since'https://bitbucket.org/Torr_Samaho/zandronum/commits/54c5571372c0d03577509efb0da9f7f45aac080a [^]' was added, i went and tested it anyways with cl_predict_players 0 or 1, the desync was still reproducable i can provide the build used and demos, if necessary |
(0014811) WaTaKiD (updater) 2016-05-04 05:08 |
i tested'https://bitbucket.org/zandronum/zandronum-sandbox/commits/55ee9c1edec102e84625c89940e8b956b3576858 [^]' with cl_predict_players 0 and 1, and desync was still reproducable |
(0014812) Torr Samaho (administrator) 2016-05-04 05:59 |
Thanks for checking! Is there any background information on the original ZDoom fix? Like a bug report? Currently, I'm considering to simply deactivate the whole fix for the time being. |
(0014813) WaTaKiD (updater) 2016-05-04 06:28 edited on: 2016-05-04 06:31 |
i believe this is the thread for the original fix:'http://forum.zdoom.org/viewtopic.php?f=7&t=31689 [^]' and this is for the 'revert' commit:'http://forum.zdoom.org/viewtopic.php?f=7&t=50308 [^]' |
(0014814) Edward-san (developer) 2016-05-04 08:45 |
Can you try again with this changeset? |
(0014815) WaTaKiD (updater) 2016-05-04 15:29 |
with'https://bitbucket.org/zandronum/zandronum-sandbox/commits/e26addcb0345d4a5753c97bdf43d3f924e40b374 [^]' and cl_predict_players 0/1 i was still able to desync |
(0014816) Edward-san (developer) 2016-05-04 16:16 |
Urgh okay ... can you try this:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/65c9f13389dfe211a602647c8df0fd89cc3c350a [^]' ? |
(0014817) WaTaKiD (updater) 2016-05-04 16:52 |
with'https://bitbucket.org/zandronum/zandronum-sandbox/commits/65c9f13389dfe211a602647c8df0fd89cc3c350a [^]' i was unable to desync with cl_predict_players 0 or 1, i even cranked up the emulated ping from 140 to 300 and ran a couple more tests and while it was expectedly laggy, it still did not desync |
(0014818) Edward-san (developer) 2016-05-04 17:00 |
Of course, that contains the revert of the whole fix. We should try fixing the problem, though. |
(0014824) Torr Samaho (administrator) 2016-05-05 19:12 |
The only possible explanation I have so far is that the fix affects the timing on clients and server differently. Can somebody try to come up with an example wad based on the stock weapons that still has the sync problems, but reveals whether the flash state on server and client have effectively the same length? |
(0014839) Edward-san (developer) 2016-05-08 20:51 |
A workaround was added with this changeset:'https://bitbucket.org/Torr_Samaho/zandronum/commits/2ad9d0af90838a40076af4e7367f9954ab303d9c [^]' . |
(0015019) StrikerMan780 (reporter) 2016-06-05 06:57 edited on: 2016-06-05 21:54 |
I hope this can get solved without disabling the fix altogether, as this is breaking mods. (Most mods depend on the new behavior of allowing 1-tic flashes, otherwise we get misaligned flashes or flashes not showing at all, also fucking up timing for codepointers on the flash state). |
(0015032) Edward-san (developer) 2016-06-06 00:59 |
I'd like to know which mods are breaking, just for curiosity. |
(0015034) Torr Samaho (administrator) 2016-06-06 06:04 |
Unfortunately, ZDoom puts us in a difficult situation here. Since ZDoom's fix breaks backwards compatibility, this means we either break backwards compatibility with existing mods or we break compatibility with mods that rely on ZDoom's new behavior. Not to mention that we still don't know why the fix breaks c/s weapon sync yet. |
(0015035) StrikerMan780 (reporter) 2016-06-06 06:21 edited on: 2016-06-06 22:40 |
Keep in mind Graf *partially* reversed the fix to keep vanilla Doom behavior where it counts, while keeping the new behavior for A_GunFlash (Which, is MUCH preferred... the weird-ass behavior of old was infuriating in a lot of situations for modders.) EDIT: Edward-San, it Basically affects every mod designed for ZDoom 2.7.1 and later. By the way, this is the original code submission, dunno if there's anything that may hint what may have been overlooked. (Perhaps the stuff about BT_ATTACK? Or perhaps the behavior after A_Refire and such in the spoiler.)'http://forum.zdoom.org/viewtopic.php?f=2&t=31689 [^]' Someone should test if the de-synch happens right on the first shot, or only after consecutive shots while holding the fire button. |
(0015041) Edward-san (developer) 2016-06-07 00:29 |
Okay, I made a back out commit on top of the latest 3.0 upstream changeset:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/71e5da2d57a9a7e3bb0545ac6034cb3000dcad0b [^]' and on top of this I made this debug changeset:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/473098beccbbad53041a1e780ae0365335efc092 [^]' . Essentially it prints on the screen what the server and the client know about the player's sprite status. Torr, do you think it's feasible like this? |
(0015042) WaTaKiD (updater) 2016-06-07 01:13 edited on: 2016-06-07 01:14 |
as requested, here is a build with edward-san's backed out commit:'https://www.dropbox.com/s/hpiwu3myt6mn7xo/zandronum-3.0-r160606-2046-71e5da2-windows.zip?dl=0 [^]' and a demo using it:'http://zandronum.com/tracker/file_download.php?file_id=1820&type=bug [^]' and here is a build with the debug changeset:'https://www.dropbox.com/s/5cjfz581ib9lgme/zandronum-3.0-r160607-0020-473098b-windows.zip?dl=0 [^]' and a demo using it:'http://zandronum.com/tracker/file_download.php?file_id=1821&type=bug [^]' |
(0015043) Torr Samaho (administrator) 2016-06-07 05:58 |
Quote from Edward-san You may also want to include the current gametic in the output. I tried something similar locally a while back, but didn't get differing output on client and server. Does this show discrepancies? |
(0015044) Edward-san (developer) 2016-06-07 09:10 edited on: 2016-06-07 10:21 |
The demo'http://zandronum.com/tracker/file_download.php?file_id=1821&type=bug [^]' shows that when the processPending checking in P_MovePsprites is reached, the client has always its processPending 1 (I verified this with a conditional breakpoint never reached), while the server does not. I tried with my local DOOM2 server, I didn't do anything else than switching between the pistol and the fist and indeed the client's processPending printed value is always 1. [edit] I modified the code to run also offline, the player's processPending is the same as the client. [edit2] You can also reproduce the discrepancy by getting both the shotgun and the supershotgun, then press continuously '3'. |
(0015045) Edward-san (developer) 2016-06-07 10:34 edited on: 2016-06-07 10:35 |
Improved the message with this changeset:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/756ec0afbd20c4a3f8711bef521a21c3ed5899cf [^]' . A new build must be done and also a new demo must be created with the new build. |
(0015047) WaTaKiD (updater) 2016-06-07 16:39 edited on: 2016-06-07 18:23 |
heres a build with the improved message:'https://www.dropbox.com/s/rfo8cnm8if7g12d/zandronum-3.0-r160607-1031-756ec0a-windows.zip?dl=0 [^]' demo:'http://zandronum.com/tracker/file_download.php?file_id=1822&type=bug [^]' edit: heres a demo with cl_predict_players 0:'http://zandronum.com/tracker/file_download.php?file_id=1823&type=bug [^]' |
(0015049) Torr Samaho (administrator) 2016-06-07 18:54 |
Do you have the server console log that corresponds to this demo? |
(0015050) WaTaKiD (updater) 2016-06-07 19:10 |
i do not, but here is a server log from a new demo ive recorded (also with cl_predict_players 0):'http://zandronum.com/tracker/file_download.php?file_id=1824&type=bug [^]' if needed, i can provide said demo, and even a client log, although to me it doesnt seem like theres any useful info in either of the logs, just me connecting, give all, and disconnecting |
(0015051) WaTaKiD (updater) 2016-06-07 19:43 |
edward-san made this:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/a083e70be4e93e0966b639d6b84685c915de93af [^]' and my results: <WaTaKiD>tested with both cl_predict_players 0 and 1 <WaTaKiD>after trying for a minute and a half with each, i didnt desync |
(0015052) Edward-san (developer) 2016-06-07 19:50 edited on: 2016-06-07 20:21 |
I'll try to explain that: when trying to switch weapons, after increasing the gametic, the server can call P_PlayerThink (which calls P_MovePsprites) from ClientMoveCommand::process before P_NewPspriteTick is called (from P_Ticker). I guess the proper solution is to move the P_NewPspriteTick call in SERVER_Tick.. [edit] and nope, it doesn't fix the problem. Investigating further.. |
(0015053) WaTaKiD (updater) 2016-06-07 21:16 |
edward-san made another:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/405521e792e71ee9a52f46952853b7ea3eb0a383 [^]' we did some testing on a server, and while we did not see ourselves desync, we did see eachother desync while f12ing also, the ps_flash debug messages werent working correctly if there was more than 1 client |
(0015054) StrikerMan780 (reporter) 2016-06-07 21:56 edited on: 2017-02-15 17:06 |
Here's a mod that can be used to test. Weapons of Saturn. The minigun depends on the new flash behavior of 2.7.1. 'http://www.mediafire.com/download/4x5o69vpp5bq0b1/weapons_of_saturn.pk3 [^]' You'll still see a flash on the minigun, but it won't show the proper animation like in 2.7.1. Frames are missing. |
(0015057) Edward-san (developer) 2016-06-08 11:04 |
Quote 'https://bitbucket.org/zandronum/zandronum-sandbox/commits/e0d95cad9594d44b821bd2838ecc9b36599edfd6 [^]' and'https://bitbucket.org/zandronum/zandronum-sandbox/commits/c7ab864a2f31bfb51c5fdeb46fca9f6f63e60012 [^]' makes the debug messages work for two clients (I wish I could reduce the font size even more ...). With these changesets, the eachother desync makes the client and server messages inconsistent (like the client showing the ps_flash and the server doesn't and viceversa). Anyways, we tested also latest 3.0 beta and the eachother desync with f12 happened there, too. |
(0015411) StrikerMan780 (reporter) 2016-07-26 21:47 edited on: 2017-01-31 08:15 |
Any progress, or an idea what may be causing the de-synch? The fact this ticket is stagnating is worrying... The current behavior in Zandronum is breaking a shitload of 2.7.1+ mods, including my own. |
(0016866) StrikerMan780 (reporter) 2017-02-15 16:41 edited on: 2017-02-17 19:24 |
@Edward-san I'd personally move the P_MovePsprites call instead of moving P_NewPspriteTick, because P_MovePsprites is the only function that makes use of the psp->ProcessPending variable in any meaningful way. OR, try putting player->psprites[ps_flash].processPending = false; under the "P_SetPsprite (player, ps_flash, flash);" call in A_GunFlash instead of putting it inside P_SetPsprite iteslf. Also, question: Do both the client and server execute A_GunFlash codepointers, not only for themselves, but everyone else? If not, I could see where problems could arise. It seems the way the server and client execute the states are inconsistent, because offline, with the way things are, the 1st tic is skipped for a flash, but online, the client doesn't skip the 1st tic (at least most of the time, it's kind of random), but the server does. |
(0018833) Leonard (developer) 2017-11-08 23:58 edited on: 2017-11-08 23:59 |
@Edward: I pulled your commits, rebased them and adapted the last one to the recent changes introduced by 0003315. By the way, an easy way to reproduce this issue is to emulate ping spikes (which will force the use of the ticbuffer). Using the settings described in 0002330:0012884 and an alias, I can reproduce this issue 100% of the time (given the fix for 0002748 is applied of course) unless your fix is applied. Here's the alias I'm using: use rocketlauncher;wait 28;+attack;wait;-attack;weapnext As for the desync occuring when spying on other players, I think this is a different issue that should be discussed in a separate ticket. Edit: here's the link to the commits. |
(0018838) Edward-san (developer) 2017-11-09 08:54 |
I re-rebased by updating my credentials: link, so the previous one can be stripped away. So, Leonard, you confirm that my patch works fine, correct? |
(0018841) Leonard (developer) 2017-11-09 11:26 |
Yup, you could make a PR right away if you want. |
(0018845) Edward-san (developer) 2017-11-09 18:01 |
'https://bitbucket.org/Torr_Samaho/zandronum-stable/pull-requests/64/fix-of-old-30-weapon-desync-caused-by/diff [^]' |
(0018877) Edward-san (developer) 2017-11-13 17:56 |
It could be nice if somebody else could test the patch in 0002607:0018845 before merging it. |
(0019172) StrikerMan780 (reporter) 2018-04-18 06:48 |
I haven't been able to reproduce the desync in the latest 3.1 build. Used gamer proxy with pings of 140, and 200. Since it seems related to the other A_GunFlash issue, which is now fixed, also fixed this. |
This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why. |
|
Supporters: | Combinebobnt Ivan |
Opponents: | No one explicitly opposes this issue yet. |
Issue History | |||
Date Modified | Username | Field | Change |
2016-02-01 00:21 | unknownna | New Issue | |
2016-02-01 00:21 | unknownna | File Added: 3.0_weapondesync.cld | |
2016-02-01 00:22 | unknownna | Status | new => confirmed |
2016-02-01 00:22 | unknownna | Description Updated | View Revisions |
2016-02-01 00:24 | unknownna | Steps to Reproduce Updated | View Revisions |
2016-02-01 09:08 | Edward-san | Product Version | 3.0 => 3.0-beta |
2016-02-02 07:10 | Torr Samaho | Note Added: 0014297 | |
2016-04-10 19:08 | Torr Samaho | Target Version | => 3.0 |
2016-04-13 01:38 | WaTaKiD | Note Added: 0014704 | |
2016-04-13 10:17 | Edward-san | Note Added: 0014705 | |
2016-04-13 10:28 | Edward-san | Note Edited: 0014705 | View Revisions |
2016-04-15 06:30 | Torr Samaho | Note Added: 0014717 | |
2016-04-15 06:30 | Torr Samaho | Assigned To | => Torr Samaho |
2016-04-15 06:30 | Torr Samaho | Status | confirmed => feedback |
2016-04-15 06:31 | Torr Samaho | Note Edited: 0014717 | View Revisions |
2016-04-15 06:58 | WaTaKiD | File Added: 3.0_wepdesync_predict-off.cld | |
2016-04-15 07:00 | WaTaKiD | Note Added: 0014718 | |
2016-04-15 07:00 | WaTaKiD | Note Edited: 0014718 | View Revisions |
2016-04-30 17:02 | Edward-san | Note Added: 0014775 | |
2016-05-03 19:18 | Torr Samaho | Note Added: 0014808 | |
2016-05-04 00:18 | Edward-san | Note Added: 0014809 | |
2016-05-04 00:18 | WaTaKiD | Note Added: 0014810 | |
2016-05-04 05:08 | WaTaKiD | Note Added: 0014811 | |
2016-05-04 05:59 | Torr Samaho | Note Added: 0014812 | |
2016-05-04 06:28 | WaTaKiD | Note Added: 0014813 | |
2016-05-04 06:29 | WaTaKiD | Note Edited: 0014813 | View Revisions |
2016-05-04 06:31 | WaTaKiD | Note Edited: 0014813 | View Revisions |
2016-05-04 08:45 | Edward-san | Note Added: 0014814 | |
2016-05-04 15:29 | WaTaKiD | Note Added: 0014815 | |
2016-05-04 16:16 | Edward-san | Note Added: 0014816 | |
2016-05-04 16:52 | WaTaKiD | Note Added: 0014817 | |
2016-05-04 17:00 | Edward-san | Note Added: 0014818 | |
2016-05-05 19:12 | Torr Samaho | Note Added: 0014824 | |
2016-05-08 20:51 | Edward-san | Note Added: 0014839 | |
2016-05-08 20:51 | Edward-san | Status | feedback => needs testing |
2016-06-05 06:57 | StrikerMan780 | Note Added: 0015019 | |
2016-06-05 10:31 | Dusk | Relationship added | parent of 0002748 |
2016-06-05 21:53 | StrikerMan780 | Note Edited: 0015019 | View Revisions |
2016-06-05 21:54 | StrikerMan780 | Note Edited: 0015019 | View Revisions |
2016-06-05 21:54 | StrikerMan780 | Note Edited: 0015019 | View Revisions |
2016-06-06 00:59 | Edward-san | Note Added: 0015032 | |
2016-06-06 06:04 | Torr Samaho | Note Added: 0015034 | |
2016-06-06 06:21 | StrikerMan780 | Note Added: 0015035 | |
2016-06-06 06:22 | StrikerMan780 | Note Edited: 0015035 | View Revisions |
2016-06-06 22:32 | StrikerMan780 | Note Edited: 0015035 | View Revisions |
2016-06-06 22:35 | StrikerMan780 | Note Edited: 0015035 | View Revisions |
2016-06-06 22:36 | StrikerMan780 | Note Edited: 0015035 | View Revisions |
2016-06-06 22:38 | StrikerMan780 | Note Edited: 0015035 | View Revisions |
2016-06-06 22:39 | StrikerMan780 | Note Edited: 0015035 | View Revisions |
2016-06-06 22:40 | StrikerMan780 | Note Edited: 0015035 | View Revisions |
2016-06-07 00:29 | Edward-san | Note Added: 0015041 | |
2016-06-07 01:13 | WaTaKiD | Note Added: 0015042 | |
2016-06-07 01:13 | WaTaKiD | File Added: 3.0_wepdesync-71e5da2.cld | |
2016-06-07 01:14 | WaTaKiD | File Added: 3.0_wepdesync-473098b.cld | |
2016-06-07 01:14 | WaTaKiD | Note Edited: 0015042 | View Revisions |
2016-06-07 01:14 | WaTaKiD | Note Edited: 0015042 | View Revisions |
2016-06-07 05:58 | Torr Samaho | Note Added: 0015043 | |
2016-06-07 09:10 | Edward-san | Note Added: 0015044 | |
2016-06-07 09:46 | Edward-san | Note Edited: 0015044 | View Revisions |
2016-06-07 10:21 | Edward-san | Note Edited: 0015044 | View Revisions |
2016-06-07 10:34 | Edward-san | Note Added: 0015045 | |
2016-06-07 10:35 | Edward-san | Note Edited: 0015045 | View Revisions |
2016-06-07 16:39 | WaTaKiD | File Added: 3.0_wepdesync-756ec0a.cld | |
2016-06-07 16:39 | WaTaKiD | Note Added: 0015047 | |
2016-06-07 18:22 | WaTaKiD | File Added: 3.0_wepdesync-756ec0a-predict-off.cld | |
2016-06-07 18:23 | WaTaKiD | Note Edited: 0015047 | View Revisions |
2016-06-07 18:54 | Torr Samaho | Note Added: 0015049 | |
2016-06-07 19:08 | WaTaKiD | File Added: serverlog.txt__2016_06_07-12_05_36.log | |
2016-06-07 19:10 | WaTaKiD | Note Added: 0015050 | |
2016-06-07 19:43 | WaTaKiD | Note Added: 0015051 | |
2016-06-07 19:50 | Edward-san | Note Added: 0015052 | |
2016-06-07 19:50 | Edward-san | Note Edited: 0015052 | View Revisions |
2016-06-07 20:21 | Edward-san | Note Edited: 0015052 | View Revisions |
2016-06-07 21:16 | WaTaKiD | Note Added: 0015053 | |
2016-06-07 21:56 | StrikerMan780 | Note Added: 0015054 | |
2016-06-08 11:04 | Edward-san | Note Added: 0015057 | |
2016-07-26 21:47 | StrikerMan780 | Note Added: 0015411 | |
2017-01-31 08:15 | StrikerMan780 | Note Edited: 0015411 | View Revisions |
2017-02-15 16:41 | StrikerMan780 | Note Added: 0016866 | |
2017-02-15 16:41 | StrikerMan780 | Note Edited: 0016866 | View Revisions |
2017-02-15 16:42 | StrikerMan780 | Note Edited: 0016866 | View Revisions |
2017-02-15 16:47 | StrikerMan780 | Note Edited: 0016866 | View Revisions |
2017-02-15 16:48 | StrikerMan780 | Note Edited: 0016866 | View Revisions |
2017-02-15 17:06 | StrikerMan780 | Note Edited: 0015054 | View Revisions |
2017-02-15 17:18 | StrikerMan780 | Note Edited: 0016866 | View Revisions |
2017-02-15 17:18 | StrikerMan780 | Note Edited: 0016866 | View Revisions |
2017-02-17 19:24 | StrikerMan780 | Note Edited: 0016866 | View Revisions |
2017-04-27 01:47 | Ru5tK1ng | Status | needs testing => feedback |
2017-10-29 17:55 | Edward-san | Target Version | 3.0 => 3.1 |
2017-11-08 23:58 | Leonard | Note Added: 0018833 | |
2017-11-08 23:59 | Leonard | Note Edited: 0018833 | View Revisions |
2017-11-09 00:02 | Leonard | Status | feedback => assigned |
2017-11-09 00:02 | Leonard | Assigned To | Torr Samaho => Edward-san |
2017-11-09 08:54 | Edward-san | Note Added: 0018838 | |
2017-11-09 11:26 | Leonard | Note Added: 0018841 | |
2017-11-09 18:01 | Edward-san | Note Added: 0018845 | |
2017-11-09 18:01 | Edward-san | Status | assigned => needs review |
2017-11-13 17:56 | Edward-san | Note Added: 0018877 | |
2017-11-13 17:56 | Edward-san | Status | needs review => needs testing |
2018-04-18 06:48 | StrikerMan780 | Note Added: 0019172 | |
2018-04-20 07:09 | Dusk | Status | needs testing => resolved |
2018-04-20 07:09 | Dusk | Fixed in Version | => 3.1 |
2018-04-20 07:09 | Dusk | Resolution | open => fixed |
Copyright © 2000 - 2024 MantisBT Team |