User panel stuff on forum
  106 posts on 4 pages  First page1234Last page
Client Talk
2016-05-24, 17:07
Administrator
813 posts

Registered:
Jan 2006
Can we just release 3.0 already, pretty please?
IRC went Discord -> join the chats @ discord.quake.world
2016-05-24, 21:07
Administrator
122 posts

Registered:
Sep 2015
bps wrote:
Can we just release 3.0 already, pretty please?


Major remaining sticking point is that some people feel the mouse is lagged in 3.0, enough to reject it and go back to 2.2.

I'm checking differences between 2.2 and SDL2 (which 3.0 uses), and it looks like 2.2 would receive fewer messages from Windows, so would get a performance benefit. Not sure if I can disable those messages in SDL2 without breaking other aspects of the library - and even if it doesn't break anything, this might be a red herring. I'm looking into this at the moment. This would affect people using in_mouse 3 (raw mode) in 2.2. 3.0 also uses raw mode when /in_raw is set, but it seems not at the same performance level - if anyone suffering from this problem has any extra information please come forward, as I can't tell the difference on my machine.
2016-05-24, 23:25
Member
254 posts

Registered:
Jan 2015
I know 20 people that use ezQuake 3.0 and absolutely none of them reported any mouse lag issues.

I wonder if this is some kind of psychological effect.
dev
2016-05-25, 05:31
Member
155 posts

Registered:
Feb 2011
Couple of issues related to Quakecon, using the nightly from May 19.

Some of you may have seen my instructions for turning a fresh nQuake install into exactly how I like to play. But since Quakecon is more strict and will only allow hud+crosshair+cfg, I attempted to trim down my config to the bare minimum so that it becomes acceptable for Quakecon. In the process, I discovered a couple of issues:

1- f_modified fails because of basekey.wav, which is included in id1\gpl_maps.pk3 which comes with nQuake.
2- f_modified fails because of the following .mdl files which are included in qw\models.pk3 which comes with nQuake:
armor.mdl
backpack.mdl
gib1.mdl
gib2.mdl
gib3.mdl
invisibl.mdl
invulner.mdl
quaddama.mdl

I'm using an nQuake install that's a couple of months old, not sure if these are "fixed" in a newer install.

3- I've said this before but nobody has been able to answer me. the qw\nquake.pk3 that comes with nQuake completely screws up any of my attempts at using my own hud and config. It does some weird stuff that overwrites everything to make the setup noob-friendly. For the love of god, can someone else please try a fresh nQuake install, copy your config and hud, and see if everything works or if that stupid file breaks everything? I can very easily work around it by either deleting the file or by adding a qw\pak.lst file that tells ezQuake to not load nquake.pk3, but if Quakecon is so strict about what we can touch I'm not sure if I'm allowed to do this even though it's so simple. I have tried both overwriting the included ezquake\config.cfg and exec'ing a blood.cfg from the console, but neither of these work perfectly well when nquake.pk3 is loaded.

-BD
2016-05-25, 07:38
Member
310 posts

Registered:
Nov 2006
BLooD_DoG wrote:

3- I've said this before but nobody has been able to answer me. the qw\nquake.pk3 that comes with nQuake completely screws up any of my attempts at using my own hud and config. It does some weird stuff that overwrites everything to make the setup noob-friendly. For the love of god, can someone else please try a fresh nQuake install, copy your config and hud, and see if everything works or if that stupid file breaks everything? I can very easily work around it by either deleting the file or by adding a qw\pak.lst file that tells ezQuake to not load nquake.pk3, but if Quakecon is so strict about what we can touch I'm not sure if I'm allowed to do this even though it's so simple. I have tried both overwriting the included ezquake\config.cfg and exec'ing a blood.cfg from the console, but neither of these work perfectly well when nquake.pk3 is loaded.


So does it mean that is a load order problem? Like, if you would load your own config manually after startup - does it work? Or does it remain broken?
2016-05-25, 10:17
Administrator
122 posts

Registered:
Sep 2015
BLooD_DoG wrote:
Couple of issues related to Quakecon, using the nightly from May 19.
1- f_modified fails because of basekey.wav, which is included in id1\gpl_maps.pk3 which comes with nQuake.
2- f_modified fails because of the following .mdl files which are included in qw\models.pk3 which comes with nQuake:
I'm using an nQuake install that's a couple of months old, not sure if these are "fixed" in a newer install.


I'll get these added to f_modified - support for the debug models was removed recently from ezquake, will put back in. basekey.wav is just placeholder to let non-shareware maps load, I'll add it as valid too.

BLooD_DoG wrote:

3- I've said this before but nobody has been able to answer me. the qw\nquake.pk3 that comes with nQuake completely screws up any of my attempts at using my own hud and config. It does some weird stuff that overwrites everything to make the setup noob-friendly. For the love of god, can someone else please try a fresh nQuake install, copy your config and hud, and see if everything works or if that stupid file breaks everything? I can very easily work around it by either deleting the file or by adding a qw\pak.lst file that tells ezQuake to not load nquake.pk3, but if Quakecon is so strict about what we can touch I'm not sure if I'm allowed to do this even though it's so simple. I have tried both overwriting the included ezquake\config.cfg and exec'ing a blood.cfg from the console, but neither of these work perfectly well when nquake.pk3 is loaded.

-BD


What worked for me was setting /cfg_save_unchanged 1, then re-exporting my config (now 106KB instead of 25) and then adding cfg_reset to the start. I could then copy to ezquake/configs/config.cfg, launch nquake and it gave me my usual hud positions etc.
2016-05-25, 11:04
Administrator
1212 posts

Registered:
Jan 2006
If you have suggestions to improve nquake, email me with the exact stuff that needs to be changed and I take care of the rest.
never argue with an idiot. they'll bring you back to their level and then beat you with experience.
2016-05-25, 11:56
Member
254 posts

Registered:
Jan 2015
meag wrote:
BLooD_DoG wrote:
Couple of issues related to Quakecon, using the nightly from May 19.
1- f_modified fails because of basekey.wav, which is included in id1\gpl_maps.pk3 which comes with nQuake.
2- f_modified fails because of the following .mdl files which are included in qw\models.pk3 which comes with nQuake:
I'm using an nQuake install that's a couple of months old, not sure if these are "fixed" in a newer install.


I'll get these added to f_modified - support for the debug models was removed recently from ezquake, will put back in. basekey.wav is just placeholder to let non-shareware maps load, I'll add it as valid too.

BLooD_DoG wrote:

3- I've said this before but nobody has been able to answer me. the qw\nquake.pk3 that comes with nQuake completely screws up any of my attempts at using my own hud and config. It does some weird stuff that overwrites everything to make the setup noob-friendly. For the love of god, can someone else please try a fresh nQuake install, copy your config and hud, and see if everything works or if that stupid file breaks everything? I can very easily work around it by either deleting the file or by adding a qw\pak.lst file that tells ezQuake to not load nquake.pk3, but if Quakecon is so strict about what we can touch I'm not sure if I'm allowed to do this even though it's so simple. I have tried both overwriting the included ezquake\config.cfg and exec'ing a blood.cfg from the console, but neither of these work perfectly well when nquake.pk3 is loaded.

-BD


What worked for me was setting /cfg_save_unchanged 1, then re-exporting my config (now 106KB instead of 25) and then adding cfg_reset to the start. I could then copy to ezquake/configs/config.cfg, launch nquake and it gave me my usual hud positions etc.


I also deleted all other cfg files from nQuake / ezQuake folders.
dev
2016-05-25, 14:59
Member
155 posts

Registered:
Feb 2011
Tuna wrote:
So does it mean that is a load order problem? Like, if you would load your own config manually after startup - does it work? Or does it remain broken?

I've tried a bunch of things and it remains broken (i.e. my hud becomes a frankenstein combination of my real hud and an nquake hud). I've tried a pk3 file where alphabetically it comes before and after nquake.pk3 (in case the order is affected), tried extracting the files, loading my own config manually after startup, etc. I think the issue is that nquake.pk3 autoexecs some stuff to overwrite back to the default config.

andrestone wrote:
I also deleted all other cfg files from nQuake / ezQuake folders.

Cheater!!! I don't think Quakecon would allow this Like I said it's easy for me to workaround the problem by deleting or renaming nquake.pk3, or adding a text file called pak.lst that tells ezquake which pk3 files to load, but it sounds like all these options will be prohibited at Quakecon.

meag wrote:
What worked for me was setting /cfg_save_unchanged 1, then re-exporting my config (now 106KB instead of 25) and then adding cfg_reset to the start. I could then copy to ezquake/configs/config.cfg, launch nquake and it gave me my usual hud positions etc.

Thanks Meag, I'll try this when I get home later tonight. It seems a little excessive that this is required (and strange that nobody else who will be competing has complained or run into this?).

Cheers,
BD
2016-05-25, 15:09
Member
35 posts

Registered:
May 2012
meag wrote:
bps wrote:
Can we just release 3.0 already, pretty please?


Major remaining sticking point is that some people feel the mouse is lagged in 3.0, enough to reject it and go back to 2.2.

I'm checking differences between 2.2 and SDL2 (which 3.0 uses), and it looks like 2.2 would receive fewer messages from Windows, so would get a performance benefit. Not sure if I can disable those messages in SDL2 without breaking other aspects of the library - and even if it doesn't break anything, this might be a red herring. I'm looking into this at the moment. This would affect people using in_mouse 3 (raw mode) in 2.2. 3.0 also uses raw mode when /in_raw is set, but it seems not at the same performance level - if anyone suffering from this problem has any extra information please come forward, as I can't tell the difference on my machine.


Actually im one of those. Id so much prefer to use EZq3 than 2.2. But after several ppl told me in_mouse 3 would feel a bit better (i wouldnt believe it), i reinstalled 2.2 and tested. Its definatly much more pleasant and easier for me to handle mouse with that. (360 flicks / slow moves aswell). Nobody conviced me of that, i tested and found 2.2.to be more fluid. On another note, i anyway had to flip back because i cant get the new soundmodule stable on my system at all. Seems like SDL2 can support not too many soundcards properly

I wish i could go back to ezq3 but wont happen with that soundissue and mousefeeling. EZQ3 is the more modern client, awww too bad it doesnt run so well on my box
2016-05-25, 18:06
Member
155 posts

Registered:
Feb 2011
meag wrote:
What worked for me was setting /cfg_save_unchanged 1, then re-exporting my config (now 106KB instead of 25) and then adding cfg_reset to the start. I could then copy to ezquake/configs/config.cfg, launch nquake and it gave me my usual hud positions etc.

Ok I tried a few variations of this and it's better but not perfect.

This is what my hud should look like:
http://imgur.com/1tnbAXg

This is what was happening before trying your suggestion. You'll see it's a frankenstein combination of my hud and the nquake hud. This happens if I replace the config.cfg that comes with nquake by my config.cfg (which was saved with cfg_save_unchanged 0).
http://imgur.com/0QtlTxx

Below is what happens when I save my config with cfg_save_unchanged 1, add a cfg_reset to the top of it, rename it to blood.cfg, load ezquake, and exec blood.cfg (note that if I overwrite the nquake config.cfg with blood.cfg it doesn't load my hud correctly, even with cfg_reset added to the top).
http://imgur.com/UFWNzK4

The last pic is pretty close to what it should be, because there are no overlapping elements and everything is in the right place, but the icons for weapons and health/armor/ammo are loaded from nquake.pk3 instead of loading the ones that I copied to the \textures\wad folders.

-BD

[Edit] The images aren't loading inline because imgur is overloaded, but if you copy the link and open in a separate window it works fine.
2016-05-26, 01:13
Member
254 posts

Registered:
Jan 2015
BLooD_DoG wrote:
meag wrote:
What worked for me was setting /cfg_save_unchanged 1, then re-exporting my config (now 106KB instead of 25) and then adding cfg_reset to the start. I could then copy to ezquake/configs/config.cfg, launch nquake and it gave me my usual hud positions etc.

Ok I tried a few variations of this and it's better but not perfect.

This is what my hud should look like:
http://imgur.com/1tnbAXg

This is what was happening before trying your suggestion. You'll see it's a frankenstein combination of my hud and the nquake hud. This happens if I replace the config.cfg that comes with nquake by my config.cfg (which was saved with cfg_save_unchanged 0).
http://imgur.com/0QtlTxx

Below is what happens when I save my config with cfg_save_unchanged 1, add a cfg_reset to the top of it, rename it to blood.cfg, load ezquake, and exec blood.cfg (note that if I overwrite the nquake config.cfg with blood.cfg it doesn't load my hud correctly, even with cfg_reset added to the top).
http://imgur.com/UFWNzK4

The last pic is pretty close to what it should be, because there are no overlapping elements and everything is in the right place, but the icons for weapons and health/armor/ammo are loaded from nquake.pk3 instead of loading the ones that I copied to the \textures\wad folders.

-BD

[Edit] The images aren't loading inline because imgur is overloaded, but if you copy the link and open in a separate window it works fine.


Any file contained in a pk3 will have priority over the ones in the folders. The hud files must be contained in a pk3 file with filename greater than nquake.pk3. I named mine z.pk3 just to make sure
dev
2016-05-26, 01:19
Administrator
122 posts

Registered:
Sep 2015
BLooD_DoG wrote:

The last pic is pretty close to what it should be, because there are no overlapping elements and everything is in the right place, but the icons for weapons and health/armor/ammo are loaded from nquake.pk3 instead of loading the ones that I copied to the \textures\wad folders.


Ok, more head-scratching... some of the nquake hud elements are .tga, some are .png. When they are .tga, they took precedence over any .png files that you had in your textures/wad/ directory. I've updated ezquake to change this slightly, and now any loose files take precedence over pak/zip files - this isn't a great solution but is better than what was there before. So it will find the .tga in a pk3, but then find your .png in /textures/hud folder, and should use that instead.

Second problem (or it was the way I had set up my nquake test, anyway) is that /qw/ directory take precedence over /ezquake/ directory (/path command shows this). So instead of putting the textures/hud files in there, I put them in the MyDocuments/ezquake/ directory, which takes precedence over the others. I then also put my config (with unchanged vars, as previously discussed) in MyDocuments/ezquake/configs/config.cfg, which nquake's autoexec.cfg executes. This gives me my config and the hud images replaced.

Hopefully this helps. New build (might be tomorrow night now for nightly build to update, might have missed the deadline) should have clean f_modified on nquake install too.
2016-05-26, 02:33
Member
254 posts

Registered:
Jan 2015
I would like to go back to the officialization of ezQuake 3.0. As at least 9 out of 10 players didn't experience major problems on 3.0 and actually find it a much better client, can't we just release?

If some still can't play on 3.0, they should update their hardware or play with 2.2 until the developers increase hardware compatibility. That aside, releasing now doesn't force us to stop development, we'd just have a official 3.0 to start using. If any major fix / feature comes up, we can always launch 3.01 and it will be the latest official, that is what QuakeCon said they'll use.

We are almost two months away from QuakeCon and the seeding tourneys are about to start. Please release!
dev
2016-05-26, 05:01
Member
155 posts

Registered:
Feb 2011
andrestone wrote:
Any file contained in a pk3 will have priority over the ones in the folders. The hud files must be contained in a pk3 file with filename greater than nquake.pk3. I named mine z.pk3 just to make sure

I tried that before but it didn't matter how I named it. Also, Lillie said you can't bring a pk3, the files have to be extracted. So again you're cheating

meag wrote:
So it will find the .tga in a pk3, but then find your .png in /textures/hud folder, and should use that instead.

Great!

meag wrote:
I then also put my config (with unchanged vars, as previously discussed) in MyDocuments/ezquake/configs/config.cfg, which nquake's autoexec.cfg executes

I'll try this soon, I hope it would be acceptable in Quakecon to place files in the user account's Documents folder.

meag wrote:
Hopefully this helps.

Yeah, thanks for all your work on this, it's much appreciated!

andrestone wrote:
We are almost two months away from QuakeCon and the seeding tourneys are about to start. Please release!

Really agree here, there shouldn't be a reason to use years-old version when ezquake 3 has tons of bug fixes and improvements (and security checks?). I tried ezquake 2 briefly today and it felt bad.

-BD
2016-05-30, 22:54
News Writer
795 posts

Registered:
Jan 2006
andrestone wrote:
I would like to go back to the officialization of ezQuake 3.0. As at least 9 out of 10 players didn't experience major problems on 3.0 and actually find it a much better client, can't we just release?

If some still can't play on 3.0, they should update their hardware or play with 2.2 until the developers increase hardware compatibility. That aside, releasing now doesn't force us to stop development, we'd just have a official 3.0 to start using. If any major fix / feature comes up, we can always launch 3.01 and it will be the latest official, that is what QuakeCon said they'll use.

We are almost two months away from QuakeCon and the seeding tourneys are about to start. Please release!


I agree. I actually find 3.0 much more stable than 2.2... I have been testing the /ruleset qcon releases and no problems at all so far. We just need an official release ASAP.
  106 posts on 4 pages  First page1234Last page