I have had a few e-mails of confusion on this, so I will once more give a very clear picture of what will be allowed.

Players won't be launching nQuake. They will be launching ezquake, as it is the client. We, the administrators, will use nquake to install quake to the systems, but the player won't need to do this.

As stated before, the files must be officially part of the nQuake package and accessible through Ezquake. pk3 files will not be allowed. All hud files and such much be unpacked so that we can view them easily. Cfg, crosshairs, and hud files only. No models, no textures, no skins, fonts and etc will be allowed.

Thanks for clarifying this once and for all

It has come to my attention that ezquake 2.2 will be used at QuakeCon unless there is an official build of 3.0 released (very soon)

How can we make this happen? Perhaps it can just be an approved "QuakeCon" build of 3.0? Ideas?

Yes, latest nQuake package will be preinstalled. Featuring latest ezQuake. Problem is dimman went for drinks and barbeque indefinately - so will he, or anyone else - be able to release something before QCON?



Great timing to disappear dimman I hope you get back soon!

dimman's busy with other projects for the forseeable future, he was working on qcon changes before he went. There seems to have been a suggestion of getting loads of new features in for 3.0 at end of month, that really won't be possible as it's just me working on it now. I'll try and catch up with the nquake devs and find out what the plan is.

Well what is the issue with ezQuake really? Having an arbitrary number to the client? There is a build/revision number and there seems to be a still working nightly build system here: http://uttergrottan.localghost.net/ezquake/dev/nightlybuilds/win32/

Just pick any from them once they it is "done" - whatever that means.

But if you require it to get it into the nQuake package, this is I would worry about the most. I have not seen Empezar around here for quite some time. So I have no idea if he has Qcon on his radar or if he is considering updating nQuake to to ezQuake 3 at all. While it aims to be somewhat compatible to the old 2.0 I think a lot has changed. Looking at how well Empezar has bundled ezQuake into nQuake I feel that there is more to configs etc than just replacing the client binary..

Is there ever a good time? I have a wedding to plan for this summer (and a lot to do before that). I suggested solutions that would require minimun effort (and problems for everyone involved including QCon), they chose to do it their way which requires a lot more work from our side to absolute no benefit at all. I don't have that amount of time to just waste, sorry but I've made that clear to QCon staff from the beginning. They could've taken the easy way, they didn't and I accept that but this is the unfortunate consequence of it. It's out of my hands really.

Considering Qcon's refusal to use any of the customization solutions (pk3 and launcher), our best shot to have at least ezq3 is to choose one of the 3.0 versions already available and name it the official latest.

Question: would Qcon install nQuake as it is today and also download and make available the latest 3.0 ezQuake for people to choose what to run? If they don't, how are we going to deal with people still using ezQuake 2.2 that didn't update their cfg yet or vice versa?

Hey Dimman, maybe all that is required is the latest code to be built and version'd by you as official and they'd accept it. I think everyone is pretty happy with the latest nightly builds of 3.0. It is quite stable as far as i am concerned. It would be greatly appreciated

That doesn't solve the problem really. There is a qcon branch (dimman/qcon) in the official repo with stricter checks for sounds, new qcon ruleset and also a new command to set LG color ingame without using external textures. I think this branch should be used really (rebase it on top of master to get those fixes in too).

In short the qcon branch should check everything important but I didn't spend more time verifying it (only did sounds) so that a f_modified would really check everything against hardcoded original checksums, that way allowing .pk3's wouldn't be a problem since the client binary itself would be readonly. There would be no code to load things that weren't checked thus not really possible to cheat unnoticed. They didn't go for this solution but went ahead with a solution to restrict files etc (dunno how the client handles not being able to write to folders etc it's supposed to be able to write to). I hope it goes well but I don't know.

The client is not able to switch most textures dynamically today which is what they want and need for their solution. I don't have time to add support for this (with new and untested code), and I'm not sure the most proper solution would fit qcon anyway due to their limitations. That's the reason we're in this situation: I don't have time to do their solution (and as I said it might be a waste of time from a project perspective), and the solution I had time for they didn't accept (which is fine just unfortunate).

Given that, would an ezquake 3 nightly be any less safe than ezquake 2.2?

(Un)fortunately, the problem we need to solve now is just about letting players use the newest ezQuake instead of the old 2.2. Customization is not an issue anymore because it won't be allowed anyway.

Btw, thanks for the LG color! Very nice to hear that.

Considering that 2.2 hasn't got any maintenance for years and is EOL, 3.0 is the way to go.

3.0 is stable and as good as ready for release, just some minor bugs to fix (most of which are also present in 2.2, although 2.2 has _a lot_ of more bugs than 3.0 in general).

Okay so that's a problem now too? That they would be using 3.0 is all I heard from the start...

It would be allowed if it was in the nQuake package I was told, is that changed too? Problem with that is still that the client can't change things dynamicall so even if texturesets etc are packed into nQuake there's no real way of choosing what to use from within the client.

You're correct. So no need to bother 'cause nobody has time/knowledge to do what it takes to make the custom textures allowed. That's what I meant.

I think it would be enough if you just make a forum thread with the QCon branch release.

Any hopes for new player.mdl ?

What is the deadline set by QuakeCon for this? Isn't it the end of this month?

From what Lilie told me they need things to be done some time before QCon starts, it's just dev that pushed for a deadline.

Oh sweet. Thanks dimman

Any progress on the qcon fork? I am happy to start testing any alpha/beta.

This has been integrated into the standard build, so you should be able to grab the latest nightly, and do "/ruleset qcon" to get testing.

I know it was being discussed and sorry if I missed the answer, but is there any work being done on nQuake too? I understand the "official QuakeCon setup" will be a fresh nQuake install where the included ezQuake binary will be replaced with some newer ezQuake binary that is deemed official, and using ruleset qcon. And all we can do is bring a config + crosshair + hud. But I'd like to know if there any changes being made to nQuake so I can make sure everything I have works nicely together.

Thanks,
BD

There is an idea of mixing a Launcher / Customizer to the nQuake package, where players can change the files they want and save this changes in a template file, but it won't be used in QuakeCon.

We should keep testing the latest nightlies to report bugs and make the official QCon ezQuake release as good as possible.

Thanks meag. I've been testing it and it is working well. Any chance we could get some kind of official release? QCon is saying we all have to go back to 2.2 unless this happens extremely soon

Yeah let's release, it would be a real shame to have to use a many-years-old client when 3.0 seems to work better for nearly everyone!?

Agreed. It is over 2 years now since I made the switch to 3.0...

3.0 will be released soon as announced on discord.

This is great news! Thanks meag