Project

General

Profile

Bug #1977

Doomsday crashes with Intel Chipset

Added by Incantator over 4 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
3rd party compatibility
Target version:
Start date:
2015-02-12
% Done:

100%


Description

Hello. This time I'm having a trouble with Doomsday itself. I don't know if I have to report this in dengine.net or here but just decided to post it here.

As I said before, I'm keep using the latest stable Doomsday. When I try to open the Doomsday.exe, it just crashes (~ has stopped working error message). I gathered every information possible before asking this, and I've seen somewhere that (1) Doomsday is somewhat not compatible with Intel graphics chipset and (2) it requires OpenGL 2.0 or higher. Now my laptop supports OpenGL 2.1 so it shouldn't be a problem, I guess. My computer is using Mobile Intel(R) 4 Series Express Chipset Family (it's a laptop!).

So can't I use Doomsday engine at all? I've seen someone just using the older version but... I just hope there's a way to solve this.

Doomsday.out reports this:

0: ..\Bin\Doomsday.exe
1: -basedir
2: D:\rest\Games\Doom\Doomsday/
3: -sfxchan
4: 16
5: -nohighpat
6: -nohightex
7: -notexcomp
8: -game
9: doom1-ultimate
10: -iwad
11: D:\DOOM.WAD
12: -userdir
13: C:\Users\Incantator\Documents\Doomsday Frontend\runtime/
RenderSystem: Loading shader definitions from read-only archive entry "data/renderer.pack/
shaders.dei" [path "/data/doomsday.pk3/data/renderer.pack/shaders.dei"]
from archive in read-only "(basedir)\data\doomsday.pk3"

Thanks again.

-vvv -nofsaa.txt (446 KB) -vvv -nofsaa.txt Incantator, 2015-02-13 10:41
files.zip (314 KB) files.zip Drako, 2015-09-05 04:01
doomsday.out (549 KB) doomsday.out -vvv -nofsaa (drako) Drako, 2015-09-05 04:30
doomsday.out (261 KB) doomsday.out 1710 Drako, 2015-09-07 19:24
doomsday.out (262 KB) doomsday.out 1711 Drako, 2015-09-08 05:38
1.jpg (138 KB) 1.jpg Drako, 2015-09-08 19:24
2.jpg (137 KB) 2.jpg Drako, 2015-09-08 19:24
PixelFormats.xls (30.5 KB) PixelFormats.xls Drako, 2015-09-09 04:16
doomsday.out (337 KB) doomsday.out 1712 Drako, 2015-09-09 05:28
1712_GLscreen.jpg (67.8 KB) 1712_GLscreen.jpg 1712 Drako, 2015-09-09 05:50
doomsday.out (2.16 MB) doomsday.out v 1.15.4 (1732) Drako, 2015-09-29 19:22
doomsday.out (322 KB) doomsday.out v 2 (1730) Drako, 2015-09-29 19:28

Related issues

Related to Bug #1879: [Windows] Doomsday randomly fails to start when/after loading shader definitionsClosed2014-10-16

Related to Bug #2063: GLFramebuffer > GLTarget: Segmentation Violation [Intel]Rejected2015-05-20

Related to Bug #2183: Incomplete attachments uncaught exception (jdrp hud weapons)Closed2016-11-08

Precedes Feature #2116: Compatibility with limited FBO functionality (old OpenGL drivers)Progressed2015-02-13

Associated revisions

Revision ea1d417b (diff)
Added by skyjake almost 4 years ago

libgui|Windows|Linux: Report missing OpenGL entry points

Exception thrown, aborts startup.

IssueID #1977

Revision d49157c8 (diff)
Added by skyjake almost 4 years ago

OpenGL|libgui: Check EXT variants of functions not present in OpenGL 2.1

IssueID #1977

Revision d4dde8fb (diff)
Added by skyjake almost 4 years ago

OpenGL|libgui: Even more robust setup for GLFramebuffer

There are now five alternative configurations for the framebuffer.
The objective is to find the one that supports the most renderer
features.

According to the OpenGL Wiki, old GPUs may not allow having both depth
and stencil attachments unless they use the same target. Therefore,
if the depth24+stencil8 texture/renderbuffer fails, the fallbacks now
test for simpler color+depth only configurations, although that will
prevent sky masking from working.

IssueID #1977

Revision b7690605 (diff)
Added by skyjake over 3 years ago

Fixed|GL|libgui: Better compatibility with older OpenGL drivers

More robust FBO configuration that is more likely to work with
OpenGL 2.1 drivers.

However, some renderer features may be currently unsupported if the
FBO is not full-featured.

IssueID #1977

History

#2 Updated by skyjake over 4 years ago

The most likely reason for this crash is that the way we do antialiasing in 1.14 is not compatible with the Intel GPU you have. I recommend trying to launch with the "-nofsaa" option. When using the frontend, you can add this option in Settings > Developer > Custom options.

#3 Updated by Incantator over 4 years ago

Hm, probably I just have to wait until I buy a decent desktop; the doomsday.out is almost the same except the additional command.

Application path: D:\rest\Games\Doom\Doomsday\Bin\Doomsday.exe
Created a new 32.0 MB memory volume.
Executable: Doomsday Engine 1.14.5 (Stable 32-bit #1265) Jun 19 2014 13:11:35
Command line options:
0: ..\Bin\Doomsday.exe
1: -basedir
2: D:\rest\Games\Doom\Doomsday/
3: -sfxchan
4: 16
5: -notexcomp
6: -game
7: doom1-ultimate
8: -iwad
9: D:\DOOM.WAD
10: -nofsaa
11: -userdir
12: C:\Users\Incantator\Documents\Doomsday Frontend\runtime/
RenderSystem: Loading shader definitions from read-only archive entry "data/renderer.pack/
shaders.dei" [path "/data/doomsday.pk3/data/renderer.pack/shaders.dei"]
from archive in read-only "(basedir)\data\doomsday.pk3"

And it still crashes.

#4 Updated by skyjake over 4 years ago

  • Related to Bug #1879: [Windows] Doomsday randomly fails to start when/after loading shader definitions added

#5 Updated by skyjake over 4 years ago

Did you try the unstable 1.15.0? We've fixed some potential causes for a startup crash.

#6 Updated by Incantator over 4 years ago

I've just tried it, yet with the same result:

Application path: D:\rest\Games\Doom\Doomsday1\Bin\Doomsday.exe
Created a new 32.0 MB memory volume.
Executable: Doomsday Engine 1.15.0 [#1503] (Unstable 32-bit) Feb 12 2015 14:46:56
Command line options:
0: ..\Bin\Doomsday.exe
1: -basedir
2: D:\rest\Games\Doom\Doomsday1/
3: -sfxchan
4: 16
5: -notexcomp
6: -game
7: doom1-ultimate
8: -iwad
9: D:\rest\Games\Doom\Doomsday1\bin\DOOM.WAD
10: -userdir
11: C:\Users\Incantator\Documents\Doomsday Frontend\runtime/
RenderSystem: Loading shader definitions from read-only archive entry "renderer.pack/
shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"
^ : Loading shader definitions from read-only archive entry "renderer.pack/
lensflares.pack/shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
lensflares.pack/shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"

This is slightly different from previous, though. Same with the -nofsaa option.

#7 Updated by skyjake over 4 years ago

Ok, what if you also add the "-vvv" option in 1.15.0? This will produce a lot more log output that may contain some hints for us. Please use http://pastebin.com/ (or similar) or attach the log here as a file.

#8 Updated by Incantator over 4 years ago

Incantator wrote:

I've just tried it, yet with the same result:

Application path: D:\rest\Games\Doom\Doomsday1\Bin\Doomsday.exe
Created a new 32.0 MB memory volume.
Executable: Doomsday Engine 1.15.0 [#1503] (Unstable 32-bit) Feb 12 2015 14:46:56
Command line options:
0: ..\Bin\Doomsday.exe
1: -basedir
2: D:\rest\Games\Doom\Doomsday1/
3: -sfxchan
4: 16
5: -notexcomp
6: -game
7: doom1-ultimate
8: -iwad
9: D:\rest\Games\Doom\Doomsday1\bin\DOOM.WAD
10: -userdir
11: C:\Users\Incantator\Documents\Doomsday Frontend\runtime/
RenderSystem: Loading shader definitions from read-only archive entry "renderer.pack/
shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"
^ : Loading shader definitions from read-only archive entry "renderer.pack/
lensflares.pack/shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
lensflares.pack/shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"

This is slightly different from previous, though. Same with the -nofsaa option.

#9 Updated by Incantator over 4 years ago

Sorry, it says 'modify' in Korean but it should be 'reply'... what the...
Sure, here is the log file.

By the way, I've noticed that as I install it, Avira detects a file as an adware. It seems to be related with C++ 2013 redistributable, but I don't know what it is exactly and why it is detected as a virus.

#10 Updated by skyjake over 4 years ago

Incantator wrote:

Sure, here is the log file.

Thanks! From the looks of it, the next thing that should be happening is that the main window appears and OpenGL drawing begins. I wonder if an older stable release like 1.12.2 works on your computer, since there the OpenGL rendering was still done in a simpler manner.

By the way, I've noticed that as I install it, Avira detects a file as an adware. It seems to be related with C++ 2013 redistributable, but I don't know what it is exactly and why it is detected as a virus.

The Visual C++ redistributable contains a couple of supporting libraries by Microsoft. Could be a false positive from Avira?

#11 Updated by Incantator over 4 years ago

skyjake wrote:

Incantator wrote:

Sure, here is the log file.

Thanks! From the looks of it, the next thing that should be happening is that the main window appears and OpenGL drawing begins. I wonder if an older stable release like 1.12.2 works on your computer, since there the OpenGL rendering was still done in a simpler manner.

Thanks. I think I just have to get a desktop next time. Hoped it to be helpful to developers but I think we just ended up the same conclusion as before haha. Thanks for taking time with this problem.

By the way, I've noticed that as I install it, Avira detects a file as an adware. It seems to be related with C++ 2013 redistributable, but I don't know what it is exactly and why it is detected as a virus.

The Visual C++ redistributable contains a couple of supporting libraries by Microsoft. Could be a false positive from Avira?

I think so. I was just wondering if it has something to do with this problem.

#12 Updated by skyjake about 4 years ago

  • Related to Bug #2063: GLFramebuffer > GLTarget: Segmentation Violation [Intel] added

#13 Updated by skyjake about 4 years ago

  • Tags set to VideoCardDriver, IntelGraphics

#14 Updated by Drako almost 4 years ago

I have the same graphics card (Mobile Intel 4 Series Express Chipset Family) and exactly the same issue. I have figured out that the newest version of Doomsday which works is 1.10.4. It seems that the problem is that the OpenGL driver returns that the version 2.1 is supported while in fact only the version 1.1 is supported. Hopefully my info will help you to fix that issue.

#15 Updated by danij almost 4 years ago

Thanks for the info. It might also help to see dxdiag info for your driver and chipset if you can, see here: https://na.wargaming.net/support/Knowledgebase/Article/View/26/18/what-is-a-dxdiag-file--how-do-i-send-one

#16 Updated by Drako almost 4 years ago

Hi. I attach (files.zip) dxdiag files (both x32 and x64). I also attach a few files from OpenGL Extensions Viewer 4.3.8. Now it seems that what I wrote about OpenGL version previously is false because renderer tests passed up to version 2.1 of OpenGL (previously I used version 4.2.8 of OpenGL Extensions Viewer where the renderer test fails if the OpenGL version is higher than 1.1 - that is why I wrote what I wrote in my previous comment).

#17 Updated by Drako almost 4 years ago

I also attach doomsday.out file (-vvv -nofsaa from the newest version 1.15.3). The way this version does not work is, after pressing "Play" in Frontend it goes full screen, display all white and does nothing. I have to use the task manager to kill the process.

#18 Updated by Drako almost 4 years ago

That is the message which I get when I try to run Doomsday 2 build 1709 (Sep 6, 2015):

Application path: C:\Program Files (x86)\Doomsday 2.0.0\bin\Doomsday.exe
Created a new 32.0 MB memory volume.
Config::read: /packs/net.dengine.stdlib/modules/Config.de is newer than modules/Config,
rerunning the script
^ : Detected new build: 1459 => 1709
Executable: Doomsday Engine 2.0.0 [#1709] (Unstable 32-bit) Sep 6 2015 03:49:36
Command line options:
0: C:\Program Files (x86)\Doomsday 2.0.0\bin\Doomsday.exe
RenderSystem: Loading shader definitions from read-only archive entry "renderer.pack/
shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"
^ : Loading shader definitions from read-only archive entry "renderer.pack/
lensflares.pack/shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
lensflares.pack/shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"
(getAllOpenGLEntryPoints) Required OpenGL function missing: glBindFramebuffer
Application terminated due to exception:
(getAllOpenGLEntryPoints) Required OpenGL function missing: glBindFramebuffer

Restoring original display mode due to shutdown

According to this website: https://www.opengl.org/sdk/docs/man/html/glBindFramebuffer.xhtml the function glBindFramebuffer is supported from version 3.0 of OpenGL. It would be great if you manage to replace that function by something supported by OpenGL 2.0 (or 2.1).

#19 Updated by skyjake almost 4 years ago

Yeah, those functions should be accessed via the extensions (e.g., EXT_framebuffer_object).

Support for FBOs is required, though, either via normal or extension functions.

#20 Updated by skyjake almost 4 years ago

  • Tags changed from VideoCardDriver, IntelGraphics to VideoCardDriver, IntelGraphics, OpenGL

Let me know if tomorrow's build 1710 works any better/differently.

#21 Updated by Drako almost 4 years ago

Ok. The build 1710 gives the following error:

Application path: C:\Program Files (x86)\Doomsday 2.0.0\bin\Doomsday.exe
Created a new 32.0 MB memory volume.
Config::read: /packs/net.dengine.stdlib/modules/Config.de is newer than modules/Config,
rerunning the script
^ : Detected new build: 1459 => 1710
Executable: Doomsday Engine 2.0.0 [#1710] (Unstable 32-bit) Sep 7 2015 03:48:05
Command line options:
0: C:\Program Files (x86)\Doomsday 2.0.0\bin\Doomsday.exe
RenderSystem: Loading shader definitions from read-only archive entry "renderer.pack/
shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"
^ : Loading shader definitions from read-only archive entry "renderer.pack/
lensflares.pack/shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
lensflares.pack/shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"
GLFramebuffer: Required GL_ARB_framebuffer_object is missing!
^ : Texture-based framebuffer failed: [ConfigError] (GLTarget::validate) Incomplete
attachments
Trying fallback without depth/stencil texture
(GLTarget::validate) Incomplete attachments
Application terminated due to exception:
(GLTarget::validate) Incomplete attachments

Restoring original display mode due to shutdown

It seems that GL_ARB_framebuffer_object is supported from version 3.0 of OpenGL. If you look at the report generated by OpenGL Extensions Viewer 4.3.8 (which I attached some time ago in the file files.zip) then you will see that what is supported by my card is GL_EXT_framebuffer_object. I found on the internet ( https://www.opengl.org/discussion_boards/showthread.php/177252-Regarding-GL_EXT_framebuffer_object ) that GL_ARB_framebuffer_object and GL_EXT_framebuffer_object are quite similar. Will it be possible to use GL_EXT_framebuffer_object instead of GL_ARB_framebuffer_object in the doomsday project? It would be really great.

BTW. Do you know that project: https://www.opengl.org/sdk/tools/GLIntercept/ ? It seems it allows to "emulate" old versions of OpenGL for debugging purposes.

#22 Updated by Drako almost 4 years ago

I do not know if it helps but let me share it with you. I edited deng_gui.dll and changed ARB to EXT at offset 0x25dd27 (ie I changed GL_ARB_framebuffer_object to GL_EXT_framebuffer_object). It did not fix the problem (of course) but now the error message is slightly different:

Application path: C:\Program Files (x86)\Doomsday 2.0.0\bin\Doomsday.exe
Created a new 32.0 MB memory volume.
Config::read: /packs/net.dengine.stdlib/modules/Config.de is newer than modules/Config,
rerunning the script
^ : Detected new build: 1459 => 1710
Executable: Doomsday Engine 2.0.0 [#1710] (Unstable 32-bit) Sep 7 2015 03:48:05
Command line options:
0: C:\Program Files (x86)\Doomsday 2.0.0\bin\Doomsday.exe
RenderSystem: Loading shader definitions from read-only archive entry "renderer.pack/
shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"
^ : Loading shader definitions from read-only archive entry "renderer.pack/
lensflares.pack/shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
lensflares.pack/shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"
GLFramebuffer: Texture-based framebuffer failed: [ConfigError] (GLTarget::validate)
Incomplete attachments
Trying fallback without depth/stencil texture
(GLTarget::validate) Incomplete attachments
Application terminated due to exception:
(GLTarget::validate) Incomplete attachments

Restoring original display mode due to shutdown

#23 Updated by skyjake almost 4 years ago

Thanks for the details. Indeed it should be checking for the EXT_framebuffer_object extension rather than ARB. I'll change that and see if there are other alternatives for configuring the framebuffer to get around that attachments error.

#24 Updated by skyjake almost 4 years ago

  • Category set to 3rd party compatibility
  • Status changed from New to In Progress
  • Priority changed from Normal to Low

#25 Updated by skyjake almost 4 years ago

@Drako: Could you post an updated log with -vvv, please? It would help to see more detail about what is happening after "GLFramebuffer: Texture-based framebuffer failed".

#26 Updated by Drako almost 4 years ago

Please see the attached file. Hopefully it will help.

#27 Updated by Drako almost 4 years ago

Now 1711 build. The error changed:

Application path: C:\Program Files (x86)\Doomsday 2.0.0\bin\Doomsday.exe
Created a new 32.0 MB memory volume.
Config::read: /packs/net.dengine.stdlib/modules/Config.de is newer than modules/Config,
rerunning the script
^ : Detected new build: 1459 => 1711
Executable: Doomsday Engine 2.0.0 [#1711] (Unstable 32-bit) Sep 8 2015 04:03:20
Command line options:
0: C:\Program Files (x86)\Doomsday 2.0.0\bin\Doomsday.exe
RenderSystem: Loading shader definitions from read-only archive entry "renderer.pack/
shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"
^ : Loading shader definitions from read-only archive entry "renderer.pack/
lensflares.pack/shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
lensflares.pack/shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"
GLFramebuffer: Texture-based framebuffer failed: [ConfigError] (GLTarget::validate)
Incomplete attachments
Trying fallback without depth/stencil texture
^ : Unified depth/stencil buffer failed: [ConfigError] (GLTarget::validate) Incomplete
attachments
Trying to allocate separately
^ : Separate depth and stencil buffers failed: [ConfigError] (GLTarget::validate)
Unsupported (0x8cdd)
Final fallback: disabling render-to-texture
(GLTarget::validate) Incomplete attachments
Application terminated due to exception:
(GLTarget::validate) Incomplete attachments

Restoring original display mode due to shutdown

I also attach -vvv log (build 1711)

Hopefully you can get something from that log.

#28 Updated by skyjake almost 4 years ago

Seeing as all of the fallback configurations failed, it leads me to suspect that your GPU and/or OpenGL drivers actually are not capable of supporting the way Doomsday does its rendering in version 1.11 onwards.

Furthermore, we are soon planning to require OpenGL 3.3 in the unstable builds. I was hoping to find a workaround that could be applied in the 1.15 branch for this issue, where the requirement is OpenGL 2.1, however this doesn't look very good.

#29 Updated by skyjake almost 4 years ago

If the OpenGL Extensions Viewer app shows these for you, could you check what is supported in the Pixel Formats tab under Color Buffer Modes, Depth Buffer Modes, and Stencil Buffer Modes?

#30 Updated by Drako almost 4 years ago

For now I only can send you files 1.jpg and 2.jpg. Later I will have more time to look at this.

There is a renderer test in OpenGL extensions viewer which allows to choose pixel format from 0 to 51, I tested 0, 1, 2, 30, 31, 32, 50, and 51 and they worked. (there is also some raport from OpenGL extensions viewer is in the file files.zip)

#31 Updated by skyjake almost 4 years ago

Hmm, I can't see the information I was looking for in those. However, I've added a couple of further fallbacks to the FBO setup. Let's see if they allow the engine to launch. If so, we can then look into working around the visual artifacts caused by the potentially missing FBO capabilities.

#32 Updated by Drako almost 4 years ago

I was able to extract some data from OpenGL extensions viewer 4.3.8. Please see the xls file. Pixel formats are numbered from 1 to 51. There are other fields to look at (see files 1.jpg and 2.jpg), I copied only those which I thing are meaningful. If you would like to see values of other fields please let me know.

#33 Updated by Drako almost 4 years ago

This build (1712) is better. The engine starts, I was able to see this short tutorial in the beginning. But then after choosing an IWAD folder the whole screen goes white and nothing happens (actually does not matter what folder I choose, in fact the same happens if I click Cancel instead of choosing a folder.. I have to use the Task Manager
to kill the process. I attach -vvv doomsday.out file.

Actually, before I choose the IWAD folder I can click an triangle in the right upper corner where it says: "Renderer features unavailable: sky mask, lensflare depth"

#34 Updated by Drako almost 4 years ago

(build 1712) In fact after the engine starts, I am able to write in the console and choose options "Video, network, updater, packages" I can also see "about... GL" (I attach the screen - 1712_GLscreen).

Update: When I moved the doom.WAD file to the data folder it has been found automatically and I was able to play doom 1 or ultimate doom. However I do not know where to put the 3D models files so that they get loaded automatically.

#35 Updated by skyjake almost 4 years ago

This is the 2.0 branch, which means resource packs aren't fully supported at the moment (short answer: you currently need to load them manually using command line options). For more information, see the blog post: http://dengine.net/forums/viewtopic.php?f=24&t=2019

I think it's better that we apply these OpenGL changes to the 1.15 branch where you can use the Doomsday Frontend (Snowberry) to load resource packs like before. Also as I mentioned, the 2.0 branch will require OpenGL 3.3 soon.

#36 Updated by skyjake almost 4 years ago

  • Target version set to 1.15.4
  • % Done changed from 0 to 50

#37 Updated by skyjake almost 4 years ago

  • Assignee set to skyjake

#38 Updated by Drako almost 4 years ago

Ok. Thanks. I am looking forward new build of 1.15.4.

#39 Updated by Drako over 3 years ago

I put it here because it is most likely related to the Intel Chipset. The problem is I cannot change the resolution in Video settings. Doomsday stops responding after I click new resolution. I have to use task manager to kill the process. Exactly the same happens in 1.15.4 (1732) (running either snowberry.exe or doomsday.exe) and in v2 (1730). I attach doomsday. out files.

#40 Updated by skyjake over 3 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 50 to 100

#41 Updated by skyjake over 3 years ago

  • Precedes Feature #2116: Compatibility with limited FBO functionality (old OpenGL drivers) added

#42 Updated by skyjake over 2 years ago

  • Related to Bug #2183: Incomplete attachments uncaught exception (jdrp hud weapons) added

Also available in: Atom PDF