Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002773Zandronum[All Projects] Bugpublic2016-07-07 21:492018-09-30 21:45
Reportergrrfield 
Assigned ToTorr Samaho 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformRaspberry Pi 2BOSRaspbianOS VersionLinux grrfield 4
Product Version2.1 
Target Version3.0Fixed in Version3.0 
Summary0002773: incorrect firing modes of ennemies
DescriptionUsed with complex doom v26a2:

Monsters that have a "spread" attacking mode (eg. multiple fireballs in a horizontal spread like the hell duke or other baron types) do not have a correct firing mode under zandronum-server compiled for ARM processors.

This has been discussed with Torr and he acknowledged the compiler flags (as being correctly applied)
Steps To ReproduceFire up the included wad (but add complex-doom.v26a2.pk3 (not included in my post). Baron types will appear randomly but they all have the same behaviour. It is most clear with the hellduke, but this is a rare monster.


Courtesy to Breach for creating the wad I included. I can't make maps myself.
Additional InformationI added two pictures as well. One I took when running a server on my windows computer (showing how things SHOULD look) and another one when hosting the same wad on my Raspberry Pi (faulty firing mode).

Maybe not so clear from the pictures, but in the "Raspberry" version you slightly notice that the missing firing balls are just concentrated in the middle one. They are not missing. Being hit by the middle one(s) causes higher damage on impact (presumably).
Attached Files? file icon complexspreadattacktest.wad [^] (1,570 bytes) 2016-07-07 21:49
jpg file icon raspberry - wrong firing mode.jpg [^] (671,291 bytes) 2016-07-07 21:50
jpg file icon windows - correct firing mode.jpg [^] (540,598 bytes) 2016-07-07 21:50
? file icon complexspreadattacktest_1.wad [^] (1,992 bytes) 2016-07-08 14:46
jpg file icon complexspreadattack_1.jpg [^] (727,094 bytes) 2016-07-08 14:57
txt file icon resume.txt [^] (325 bytes) 2016-07-08 17:20 [Show Content]
txt file icon resume updated.txt [^] (415 bytes) 2016-07-09 08:48 [Show Content]
txt file icon resume updated corrected.txt [^] (421 bytes) 2016-07-09 09:01 [Show Content]

- Relationships

-  Notes
User avatar (0015218)
Torr Samaho (administrator)
2016-07-08 06:32

 Can you test if this also happens in 3.0?

If so, please extract the necessary parts of complex-doom.v26a2.pk3 and add them to the example wad. complex-doom.v26a2.pk3 is so big that debugging problems of the engine is infeasible with it.
User avatar (0015219)
Edward-san (developer)
2016-07-08 14:47

 Does it happen with the attached wad (includes a very simple baron replacement which emulates the spread attack)?
User avatar (0015220)
grrfield (reporter)
2016-07-08 15:04

 Hi,

No change with complexspreadattack_1 (see included screenshot).

I will test it tonight with the v3.0. I need someone with more expertise to get it compiled "by the book" (sorry for being linux illiterate).

As for the question to strip complex-doom.v26a2.pk3, well, i'm looking around to find someone to get the job done for me, since i'm not familiar with mapping. I'm even bad at playing doom itself.

Let me take the opportunity to say thanks for the impressive job you all are doing...
User avatar (0015221)
grrfield (reporter)
2016-07-08 15:24

 update.

In the meanwhile i received a patched binary (http://wiki.zandronum.com/Compiling_the_Zandronum_server_on_a_Raspberry_Pi is the source). Apparently there is a fix for something included in this version).

I still get the same result -> spread attack is still messed up.
User avatar (0015222)
Edward-san (developer)
2016-07-08 16:11

 Can you reproduce it without complex doom? That was the point of the updated test wad.
User avatar (0015223)
grrfield (reporter)
2016-07-08 17:16
edited on: 2016-07-08 17:20

 Ok, I must have misunderstood. Here is a resumé of all tests I have performed. I am still waiting for that v3.0 to test. I keep you updated.

                                complexspreadattack complexspreadattack_v1
With Complexdoom
windows 2.1.2 OK Ok
RPI 2.1.2-r150718-1029 buggy buggy
RPI 2.1.2-r150718-1029M buggy buggy

Without complexdoom
Windows 2.1.2 not applicable ok
RPI 2.1.2-r150718-1029 not applicable buggy
RPI 2.1.2-r150718-1029M not applicable buggy

(not applicable: because monsters have no spread attacks in this scenario)

I add a textfile to the documentation, since I have formatting issues in presenting this table-wise.
User avatar (0015227)
grrfield (reporter)
2016-07-09 08:47

 I tested it with v3.0. I added the results in an updated textfile for better reading. Conclusion: same results as before: works under windows, does not work correctly on my Pi
User avatar (0015228)
grrfield (reporter)
2016-07-09 08:51
edited on: 2016-07-09 08:53

 Friend of me reported same issues with Zandronum3.0-160519 downloaded for mac osX (tested with version complexspreadattack_1.wad (without complexdoom).


He reports the following (in dutch):

"Ik heb net Zandronum3.0-160519 op osX gedownload.
Hiermee heb ik een locale server gestart met enkel complexspreadattacktest_1.wad als wad. (dus geen complex of andere)
Vervolgens heb ik met de osX client geconnect en volgende vaststelling gedaan."

....and then a screenshot demonstrating erroneous firing behaviour.
User avatar (0015229)
grrfield (reporter)
2016-07-09 09:01

 Error, I uploaded wrong resume. I fixed it now.
User avatar (0015230)
Edward-san (developer)
2016-07-09 11:17
Quote
Friend of me reported same issues with Zandronum3.0-160519 downloaded for mac osX (tested with version complexspreadattack_1.wad (without complexdoom).


Does it imply that it happens also offline?
User avatar (0015231)
Torr Samaho (administrator)
2016-07-09 11:52
edited on: 2016-07-09 12:18

 I can confirm the broken behavior using complexspreadattacktest_1.wad on my RasPI2. Looks like a sign problem, i.e.
A_CustomMissile("BaronBall", 32, 0, -6)

is treated as
A_CustomMissile("BaronBall", 32, 0, 6)

EDIT: Looks like ACTION_PARAM_ANGLE doesn't work properly. Negative values seem to be mapped to zero.
User avatar (0015233)
Torr Samaho (administrator)
2016-07-09 14:54

 The type conversion in ACTION_PARAM_ANGLE seems to be broken on the pi, which means that all angle arguments of all DECORATE code pointers are affected. Changing ACTION_PARAM_ANGLE to the following seems to fix the issue:

#define ACTION_PARAM_ANGLE(var,i) \
    angle_t var = angle_t(SDWORD(EvalExpressionF(ParameterIndex+i, self)*ANGLE_90/90.f));

Since ZDoom switched to double precision angles, it's most likely not affected by this issue anymore.
User avatar (0015237)
Edward-san (developer)
2016-07-09 15:29
edited on: 2016-07-09 15:30

 There's an issue with MSVC compiler for x86 when you add an explicit SDWORD cast in the middle, like I reported here (which applies here, too), so the solution would be to move the whole fix in a specific ifdef.
User avatar (0015238)
Torr Samaho (administrator)
2016-07-09 15:59

 I skimmed through the ZDoom thread you linked there. Isn't the conclusion to use xs_RoundToInt instead of any signed or unsigned casts?
User avatar (0015239)
Edward-san (developer)
2016-07-09 16:16

 Right, I forgot to check again the zdoom thread. I misremembered the solution.
User avatar (0015240)
Torr Samaho (administrator)
2016-07-09 16:47

 So, the proper fix then should be to backport'https://bitbucket.org/Torr_Samaho/zandronum-zdoom-sync/commits/d5bfa2cd6f724cc77a44fced911c39fcf81845c3 [^]'

Unfortunately, that relies on ZDoom changes 3.0 doesn't have. I'll think about this further, but likely will just adapt the changes manually to fit 3.0.
User avatar (0015248)
grrfield (reporter)
2016-07-10 09:08

 Does it imply that it happens also offline? -> It does.
User avatar (0017058)
Torr Samaho (administrator)
2017-03-25 16:16

 Should be fixed in 3.0 now.
User avatar (0017618)
grrfield (reporter)
2017-05-10 18:27

 Thanks, i noticed that complex doom just got a bit harder on my 3.0 servers. Thanks
User avatar (0017619)
Ru5tK1ng (updater)
2017-05-10 19:52

 Feel free to reopen should this issue pop up in the future.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2016-07-07 21:49 grrfield New Issue
2016-07-07 21:49 grrfield File Added: complexspreadattacktest.wad
2016-07-07 21:50 grrfield File Added: raspberry - wrong firing mode.jpg
2016-07-07 21:50 grrfield File Added: windows - correct firing mode.jpg
2016-07-08 06:32 Torr Samaho Note Added: 0015218
2016-07-08 06:32 Torr Samaho Assigned To => Torr Samaho
2016-07-08 06:32 Torr Samaho Status new => feedback
2016-07-08 14:46 Edward-san File Added: complexspreadattacktest_1.wad
2016-07-08 14:47 Edward-san Note Added: 0015219
2016-07-08 14:57 grrfield File Added: complexspreadattack_1.jpg
2016-07-08 15:04 grrfield Note Added: 0015220
2016-07-08 15:04 grrfield Status feedback => assigned
2016-07-08 15:24 grrfield Note Added: 0015221
2016-07-08 16:11 Edward-san Note Added: 0015222
2016-07-08 16:11 Edward-san Status assigned => feedback
2016-07-08 17:16 grrfield Note Added: 0015223
2016-07-08 17:16 grrfield Status feedback => assigned
2016-07-08 17:19 grrfield Note Edited: 0015223 View Revisions
2016-07-08 17:20 grrfield Note Edited: 0015223 View Revisions
2016-07-08 17:20 grrfield File Added: resume.txt
2016-07-09 08:47 grrfield Note Added: 0015227
2016-07-09 08:48 grrfield File Added: resume updated.txt
2016-07-09 08:51 grrfield Note Added: 0015228
2016-07-09 08:52 grrfield Note Edited: 0015228 View Revisions
2016-07-09 08:53 grrfield Note Edited: 0015228 View Revisions
2016-07-09 09:01 grrfield Note Added: 0015229
2016-07-09 09:01 grrfield File Added: resume updated corrected.txt
2016-07-09 11:17 Edward-san Note Added: 0015230
2016-07-09 11:17 Edward-san Status assigned => feedback
2016-07-09 11:52 Torr Samaho Note Added: 0015231
2016-07-09 12:18 Torr Samaho Note Edited: 0015231 View Revisions
2016-07-09 14:54 Torr Samaho Note Added: 0015233
2016-07-09 15:29 Edward-san Note Added: 0015237
2016-07-09 15:30 Edward-san Note Edited: 0015237 View Revisions
2016-07-09 15:59 Torr Samaho Note Added: 0015238
2016-07-09 16:16 Edward-san Note Added: 0015239
2016-07-09 16:47 Torr Samaho Note Added: 0015240
2016-07-10 09:08 grrfield Note Added: 0015248
2016-07-10 09:08 grrfield Status feedback => assigned
2017-03-25 07:29 Torr Samaho Target Version => 3.0
2017-03-25 16:16 Torr Samaho Note Added: 0017058
2017-03-25 16:17 Torr Samaho Status assigned => needs testing
2017-05-10 18:27 grrfield Note Added: 0017618
2017-05-10 19:52 Ru5tK1ng Note Added: 0017619
2017-05-10 19:52 Ru5tK1ng Status needs testing => resolved
2017-05-10 19:52 Ru5tK1ng Resolution open => fixed
2017-05-10 19:52 Ru5tK1ng Fixed in Version => 3.0
2018-09-30 21:45 Blzut3 Status resolved => closed




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker