Strict Standards: Non-static method phpbb_captcha_factory::get_instance() should not be called statically in /nfs/c05/h01/mnt/83021/domains/edawn-mod.org/html/forum/posting.php on line 185

Strict Standards: call_user_func() expects parameter 1 to be a valid callback, non-static method phpbb_captcha_qa::get_instance() should not be called statically in /nfs/c05/h01/mnt/83021/domains/edawn-mod.org/html/forum/includes/captcha/captcha_factory.php on line 38[phpBB Debug] PHP Warning: in file /includes/functions.php on line 4586: Cannot modify header information - headers already sent by (output started at /posting.php:185)[phpBB Debug] PHP Warning: in file /includes/functions.php on line 4588: Cannot modify header information - headers already sent by (output started at /posting.php:185)[phpBB Debug] PHP Warning: in file /includes/functions.php on line 4589: Cannot modify header information - headers already sent by (output started at /posting.php:185)[phpBB Debug] PHP Warning: in file /includes/functions.php on line 4590: Cannot modify header information - headers already sent by (output started at /posting.php:185)excessive dawn • Post a reply

cmdrr wrote:It seems to be connected somehow to the additional file "pak8a.pk3", since removing it fixes the problem.Any ideas?

Yes, it looks like a bug in pak8a, I will try to reproduce and fix it, thanks for report!

[quote="cmdrr"]It seems to be connected somehow to the additional file "pak8a.pk3", since removing it fixes the problem.Any ideas?[/quote]Yes, it looks like a bug in pak8a, I will try to reproduce and fix it, thanks for report!

Hi, I stumbeled across your project when I came back to Q3A after a 10 years abstinence, grabbing it recently on a GOG sale. And I must say, it really makes a huge difference if one uses your or the last official version from id. Thanks a lot for your great work!

However when playing the campaign, I encountered a problem, which occurs in single player mode when an arena is restarted manually. The problem can be reproduced as follows:

Choose Single Player, select the first arena, and start playing on any difficulty but the first. Leave the room through the portal and wait to see if your opponent is attacking you. Normally it should. Now, press Esc and choose "Restart Arena". Proceed as before. This time, Crash is just running around and not attempting to shoot at you anymore. The problem does not vanish with subsequent restarts of the arena. Only leaving it and starting the campaign anew helps. It seems, that after the first restart, the difficulty level is reset to the first one "I can win", where bots do not attack.

After installing "quake3-1.32e", the problem occurs with any arena using any server, be it the default one (quake3.exe, v1.32) or the new ones (quake3e.exe, quake3e.x64.exe, v1.32e). It seems to be connected somehow to the additional file "pak8a.pk3", since removing it fixes the problem.

Any ideas?

Hi, I stumbeled across your project when I came back to Q3A after a 10 years abstinence, grabbing it recently on a GOG sale. And I must say, it really makes a huge difference if one uses your or the last official version from id. Thanks a lot for your great work!

However when playing the campaign, I encountered a problem, which occurs in single player mode when an arena is restarted manually. The problem can be reproduced as follows:

Choose Single Player, select the first arena, and start playing on any difficulty but the first. Leave the room through the portal and wait to see if your opponent is attacking you. Normally it should. Now, press Esc and choose "Restart Arena". Proceed as before. This time, Crash is just running around and not attempting to shoot at you anymore. The problem does not vanish with subsequent restarts of the arena. Only leaving it and starting the campaign anew helps. It seems, that after the first restart, the difficulty level is reset to the first one "I can win", where bots do not attack.

After installing "quake3-1.32e", the problem occurs with any arena using any server, be it the default one (quake3.exe, v1.32) or the new ones (quake3e.exe, quake3e.x64.exe, v1.32e). It seems to be connected somehow to the additional file "pak8a.pk3", since removing it fixes the problem.

crs9683 wrote:So this reduce cpu and memory usage for dedicated servers means that server operation should be smoother to play on compared to id's unmodifed 1.32c and ioquake3? i'm curious about the benefit of that.

Yes, a bit. But this is related only to snapshots, other changes like faster virrual machine (QVM) may provide more significant difference.

[quote="crs9683"]So this reduce cpu and memory usage for dedicated servers means that server operation should be smoother to play on compared to id's unmodifed 1.32c and ioquake3? i'm curious about the benefit of that.[/quote]Yes, a bit. But this is related only to snapshots, other changes like faster virrual machine (QVM) may provide more significant difference.

Btw if you want some live conversation - feel free to join https://discordapp.com/invite/X3Exs4C

So this reduce cpu and memory usage for dedicated servers means that server operation should be smoother to play on compared to id's unmodifed 1.32c and ioquake3? i'm curious about the benefit of that.

So this reduce cpu and memory usage for dedicated servers means that server operation should be smoother to play on compared to id's unmodifed 1.32c and ioquake3? i'm curious about the benefit of that.

#2 - in_minimize on is nice, but it only works wtih "0" key, if so, it has the side effect where I can not set things like r_dynamiclights 0, as the key doesn't register whilst it is in use, which makes it horrible to have on.

two problems:

#1 - dynamiclights on looks like this: http://imgur.com/87D5l6h

#2 - in_minimize on is nice, but it only works wtih "0" key, if so, it has the side effect where I can not set things like r_dynamiclights 0, as the key doesn't register whilst it is in use, which makes it horrible to have on.

This is an attempt to fix 32 dead keys on RU/UA keyboard layouts, for example. It is possible to fix your problems by changing just one directMap() function but I will need your feeback to test experimental binaries

This is an attempt to fix [b][u]32[/u][/b] dead keys on RU/UA keyboard layouts, for example. It is possible to fix your problems by changing just one directMap() function but I will need your feeback to test experimental binaries

/ in GER is & in ENG_ in GER is ? in ENG/ in ENG is - in GER_ in ENG is ? in ENG

The german layout is QWERTZ. The Problem is: If I want to enter this here: "/in_forceLayout 0" then I have to press these buttons "-in?forceLazout 0". And that is very confusing. With the latest version of Quake3 1.32e has all worked perfectly. Had also no problem with English systems too. I do not understand why this is now standard. This will confuse many people without EN layout.

The most important examples :

[b]/[/b] in GER is [b]&[/b] in ENG[b]_[/b] in GER is [b]?[/b] in ENG[b]/[/b] in ENG is [b]-[/b] in GER[b]_[/b] in ENG is [b]?[/b] in ENG

The german layout is QWERTZ. The Problem is: If I want to enter this here: "[b]/in_forceLayout 0[/b]" then I have to press these buttons "[b]-in?forceLazout 0[/b]". And that is very confusing. With the latest version of Quake3 1.32e has all worked perfectly. Had also no problem with English systems too. I do not understand why this is now standard. This will confuse many people without EN layout.

ZerTerO wrote:09-May-2017:Please, please disable this by default. I come from germany and took a long time to switch this option off in the console. Why does it have to be activated by default? Why is this cvar needed? Not many people in the world have a keyboard with EN/US keyboard layout...

What layout you have and what keys is not working properly for you? I can fix that AZERTY stuff (temporary disabled that) but I need some feedback.

I will explain why I enabled it by default: it fixes bind inconsistency on windows i.e. when you type 'bind a +moveleft' on azerty layout - when later you press 'a' - it will execute 'q' key bind because bind keys actually (if on-sceen keybard simulation is correct) connected to physical scancdodes and 'a' azerty key is 'q' by its scancode. With new behavior you always have constant physical bind layout so it will work with any keyboard settings, it also fixes 'dead keys' which comes with non-US/EN layouts

[quote="ZerTerO"][b]09-May-2017:[/b]Please, please disable this by default. I come from germany and took a long time to switch this option off in the console. Why does it have to be activated by default? Why is this cvar needed? Not many people in the world have a keyboard with EN/US keyboard layout... :([/quote]What layout you have and what keys is not working properly for you? I can fix that AZERTY stuff (temporary disabled that) but I need some feedback.

I will explain why I enabled it by default: it fixes bind inconsistency on windows i.e. when you type 'bind a +moveleft' on azerty layout - when later you press 'a' - it will execute 'q' key bind because bind keys actually (if on-sceen keybard simulation is correct) connected to physical scancdodes and 'a' azerty key is 'q' by its scancode. With new behavior you always have constant [u]physical[/u] bind layout so it will work with any keyboard settings, it also fixes 'dead keys' which comes with non-US/EN layouts