Failing to load a fanmade map into ioq3 64

ioquake3 support
1

Hello everyone!
just recently I’ve started using ioq3 back again after a very long time away from playing q3 and, on recommendation of ZJS, I’ve picked on using the test build because the regular x86 release was causing me problems with the mouse/cursor and would only let me move through the game with keyboard controls. well, the win 64 bit version of test build has fixed the problem flawlessly, but it’s giving me a new one on the other hand…

I wanted to mess back around with one very old fanmade map that I liked, but the test build straight crashes as soon as the gamestate/awaiting connection screen pops up. :confused:
now when I run the map with the regular x86 engine the map loads just fine and everything is there, but, like I’ve said, the mouse control isn’t working for me with that one…

could it be some config setting I have to switch to make the test build get along with the map? can somebody help me out on this one??

the map is part of q2toq3.pk3, file can be found on fileplanet if necessary, incase you guys wanna try and see what’s up for you.
here’s a few notes:

  • the problem doesn’t seem to solve by raising the “com_hunkMegs” value
  • doing a console log I’m able to see that I’m getting a “Client Shutdown (Received signal 11)” message, but not that great informations in it…
Console log

logfile opened on Sun May 19 23:19:01 2019

]/map q3q2dm1
------ Server Initialization ------
Server: q3q2dm1
RE_Shutdown( 0 )
------- FBO_Shutdown -------
------- R_ShutdownVaos -------
------- GLSL_ShutdownGPUShaders -------
Hunk_Clear: reset the hunk ok
We are looking in the current search path:
C:\Users\Hp\AppData\Roaming\Quake3\baseq3
C:\Program Files (x86)\ioquake3\baseq3
C:\Program Files (x86)\ioquake3\baseq3\q2toq3.pk3 (268 files)
C:\Program Files (x86)\ioquake3\baseq3\pak8.pk3 (9 files)
C:\Program Files (x86)\ioquake3\baseq3\pak7.pk3 (4 files)
C:\Program Files (x86)\ioquake3\baseq3\pak6.pk3 (64 files)
C:\Program Files (x86)\ioquake3\baseq3\pak5.pk3 (7 files)
C:\Program Files (x86)\ioquake3\baseq3\pak4.pk3 (272 files)
C:\Program Files (x86)\ioquake3\baseq3\pak3.pk3 (4 files)
C:\Program Files (x86)\ioquake3\baseq3\pak2.pk3 (148 files)
C:\Program Files (x86)\ioquake3\baseq3\pak1.pk3 (26 files)
C:\Program Files (x86)\ioquake3\baseq3\pak0.pk3 (3539 files)

handle 1: qconsole.log

4341 files in pk3 files
----- Client Shutdown (Received signal 11) -----
RE_Shutdown( 1 )

----- Server Shutdown (Received signal 11) -----

please, let me know!

2

I think I recognize this problem as one I fixed in my Elite Force client here. IIRC it’s pretty rare; this is one of very few maps that exhibits it, if not the only one.

This problem should only affect 64-bit builds. Did you try using the 32-bit ioquake3 test build, or did you have mouse issues with that?

3

I can confirm the issue (tried to load the maps you mentioned on Win 8.1 64-bit) and they failed loading.
As Chomenor said, only 64-bit should be affected.
Here is a similar issue (or even the same issue) with other maps: https://github.com/ioquake/ioq3/issues/186
Eventually @ensiform knows an engine-side fix?

4

I think that’s a different issue. This one isn’t related to floating point calculations at all. It’s an issue of the compiler optimizing for loops into vector operations that assume integers are aligned on 4-byte boundaries and crash otherwise. The patch I linked was basically a hack that prevents this optimization.

1 Like
5

Ah okay, anyways it would be cool to fix all issues that prevents loading of maps! Especially because the main goal of ioquake3 was compatibility to existing content. Thanks for clarification, Chomenor!

6

thanks both of you for reaching back!

@Chomenor sadly I’m not any good at reading the scripts in the page you’ve linked, so I’m not getting how you got around the issue there.
anyway, I’ve just tried patching up with the test build for 32 bit and the map does work and everything, no mouse issues with the test build for 32 bit, but there are some lightning issues on movable items I believe… guns and items are blackened most of the times, they come visible only when you touch certain areas of the map. looks like it’s confusing with the gamma coloring/shadowing or the palette board (?)… keep in mind I have some libraries from the 64 bit installation left in the main folder, I doubt those files are called in by the 32 bit build tho.

in the regular x86 installation of ioq3 there weren’t any of these lightning problems, and the gamma looked just alright.

I can confirm you that the map does work with 32 bit engines.
I can also confirm you that map was made wayyy back during the Q3Test days, so no surprise there may be some incompatibilities. according to the author it was done with the Q2toQ3 converter, and (even if I have no idea if the map plays on 64 bit vanilla installations of Q3A) I would exclude that it was a protection bug occourred by straight converting original maps from Q2.
there seem to be plenty of other map conversions of The Edge, and other original Q2 DM maps that load just fine with the 64 bit build…

both Q2-original/Q3-converted .bsp files read the same version number (74? or something)… it’s nothing to do with the audio or texturing side of the map (other remakes of The Edge share the same tga textures and sounds and they work properly on 64 bit). maybe anything to do with the map’s geometry defined by the Q2toQ3 converter (structure misinterpretations like you’ve witnessed)?? dunno, but the map does load and look alright on 32 bit engines.

I have never converted a Quake 3 map in my life, but I’ve tried doing my own conversion of Q2dm1 using Q2toQ3 and BSPC, without any further map editing, and I still get the same identical issue. works with 32 bit, doesn’t work with 64 bit of ioq3…

@ToKu something about what’s being said in your thread seems to echo what I’m going through. it might be a problem caused by very old map converters. like I’ve said, this one map pack I’m trying to run dates back to the Q3Test days.
I co-sign that such issue should be covered by the ioq3 engine, even if so random and rare, 'cause a lack into some random stuff could return into a lack into some whole other relevant stuff. I’ve just pointed out another issue with the gamma lightning of the map by testing with the other test build engine, althought I don’t know if it’s really a bug on the 32 bit test build’s part… still it’s good to be aware of if you ask me.

I’d still want to get this thing to work with the 64 bit test build 'cause, why not?! one wants to get his resources adjusted at their best!

7

The lighting seems to be an issue with the opengl2 renderer on this map. You can temporarily switch to the old renderer with /cl_renderer opengl1 and switch it back with /cl_renderer opengl2.

The crash issue as I understand it is a data alignment problem. The map bsp file has certain data which would normally start at a byte location divisible by 4, but due to the unusual way the map was converted it doesn’t. Then when the engine loads the bsp that data ends up at a memory address that also isn’t divisible by 4, which is incompatible with a compiler optimization used in the 64-bit builds, leading to the crash.

To get this map to work in ioquake3 64-bit builds there will need to be some kind of fix in the source code.

2 Likes
8

yup. I have no problem waiting for the source code to be fixed for it, if it ever may be fixed for it, or even waiting for an hotfix to drop.
I wished since the map could be read with the regular x86 engine it would of be just something to do with the configuration.

btw, the lightning thing is still there with the gl1 renderer, but not as drastic as it was with the gl2. not a big of a deal, but it’s there. I played the map along a whole other bounch of original DM map remakes (which have been polished up and re-textured, unlike q3q2dm1) and they all look fine, except for that one.

heading back to the mouse problem, here’s what it was like
http://www.mediafire.com/file/9ik4dglwcbs6539/

the mouse would get stuck all the way to the corner of the screen, and as soon as I’d make a movement it would start spinning non-stop until I’d use the keyboard to control the game. messing around with “in_mouse” or +mlook wouldn’t do no change to it.
other times I’ve experienced mouse issues were with a Doom 3 mod (which involved a whole new main menu, and the mouse wouldn’t show up at all) and with Quake 1 (using some source port). doing +mlook in Q1 would solve it, although I’m not sure what causes my mouse issues in Quake related games… it seems to happen primarily with source ports.