Didz

The entire architecture of the game code was built for a single thread of execution. It would be a massive undertaking and a monumental waste of time (imo) trying to retrofit multi-threading/parallelism into the Q3 engine to try to squeeze out more performance for the increase in entities. You'd need to do detailed profiling comparisons on the code (with original entity limit, and with increased entity limit) before thinking of taking this on. If you can't pin-point the critical sections of bad performance, there's no hope of trying to parallelise it. Off-the-topic of more entities, but on-topic on performance: One very noticable source of bad performance in the game is synchronous file loading where the game pauses for several frames in order to load files in (like when players change their models). This could be fixed by loading in files asynchronously, and you don't even need to implement multi-threading to do this (the system will let you know when the file has been read). Many of these can be set off in parallel and you can carry on running the game while files are being loaded in the background if the file is not critical to the gameplay.

No one can predict how much the impact of doubling the entity limit can be. It's something that would just require experimentation.

^ This

The main issue is just likely to be reduced performance and increased network traffic consumption. Here's a comment left in the source code by rww (Richard Whiteouse) explaining why he didn't increase the limit to 2048: //rww - we do have enough room to send over 2048 ents now. However, I cannot live with the guilt of //actually increasing the entity limit to 2048 (as it would slow down countless things, and //there are tons of ent list traversals all over the place). rww had also planned to increase the limit to 1053 entities in this same section of code (to ensure MP could load SP maps that were close to the limit), but he commented all that change out for some reason.

I am not a lawyer, but here's how I believe copyright works. Content creators retain copyright on their work even if they release their content as open-source. Creators can use open-source licences to grant others specific privileges on things that they are allowed to do with the work, such as derivation, distribution, reverse-engineering, etc. The work still belongs to the creator (because copyright), but the creator is giving you a licence that grants you extra freedoms to do certain things with the work. There's basically three options for managing the copyright on work intended for a community project: Every contributor keeps copyright ownership on the work they create, but they release it under an open-source licence so the community project can use itThe community project owner must require all contributors to disclaim their copyright on the work and hand it over to the community project owner before the work can be accepted into the projectThe community project owner must require all contributors to release their work into the public domain, so the work is no longer copyrighted by anyoneFor a fun community map project like the one that's being suggested, the 1st option is probably the best one as the work is open-source, but the contributors still own the copyright for the work they've done. Creative Commons have a great page explaining what copyright licences do and also describe the licences they offer themselves: https://creativecommons.org/licenses/ Sorry for derailing the thread a bit there, I just wanted to explain that open-source doesn't mean copyright is surrendered.

I don't even know how Steam/Valve got into this conversation..

Raven could redirect all requests for masterjk3.ravensoft.com to master.jkhub.org if they wished. I don't know if they'd have any motivation to do that though.

On your end, you're making use of mapextras.pk3 which is bundled with GtkRadiant. This pk3 has a bunch of textures for map development, including some textures under textures/colors. The base asset pk3s contain some of these colours, however the yellow and white textures are only in mapextras.pk3. Some colours also differ between these pk3s even though they have the same filename. Test your map without the mapextras.pk3 file and you'll see what's not vanilla.

Yeah, the q3map_surfacelight setting affects an entire surface (as the name suggests). You need to separate your shaders (and brushes) into a wall shader and a light shader.

I guess you can count screen tearing as being something that decreases graphics quality too. So if your "highest graphics" target is intended for actual game playing (not recording or screenshotting), use r_swapInterval 1 (vsync) in fullscreen mode to prevent screen tearing. There's reasons not to have vsync on because of some quirks regarding movement in the Q3 engine, but it's a tradeoff you need to consider.

r_lodCurveError doesn't have a cap, it goes up to the practical maximum limit for a floating point number. I think 99999999999999 is a bit excessive though. Stand far away from a curved surface with r_showtris 1 and fiddle about with r_lodCurveError, and you'll see there's no changes after 3000. It's safe to say 100000 is a good value if you absolutely always want curves to be high quality and never be optimized for speed. r_simpleMipMaps 0 is a good bet. You'll pay a small time cost while loading a map, but it'll mean that mip maps are generated using linear filtering instead of a more rough approximation.

I don't think the lightgrid is the problem here, because your own player model is being lit properly and that uses the lightgrid. Screenshots with r_showNormals 2 will help us know if it's the lightgrid causing the problem though. (EDIT: Seems this only shows light values in Wolfenstein: ET, not JKA) Apart from that, I can't see an obvious problem. Maybe try lifting the model so that its origin isn't submerged into the floor? Are there any custom parameters in worldspawn that are affecting light calculations? Is the model scaled differently to other ones? Is there a clip brush or something surrounding it? EDIT: Check for any console warnings when loading the map too

You should only have one fx_rain entity, and it can be anywhere in your map. You need to encompass the entire bounds of your 'outside' brushes with one big 'weather zone' brush (textures/system/weatherzone). Make sure all the 'outside' brushes are within the weather zone (leave at least a 16-wide padding), and be sure to make it a misc_weather_zone brush entity. The weather zone is optional, but it's used to reduce load times.

Ensure these settings are set: r_gamma 1r_textureMode GL_LINEAR_MIPMAP_LINEARr_picmip 0r_texturebits 32You could also try fiddling with r_ext_compress_textures on and off. Can you attach a pk3 we can use to test the model, or just the actual texture file?

I'm guessing you mean issue #271, but this issue should no longer happen as @@ensiform reverted the commits that added the changed shader parser I think? Yeah players will always be able to do /connect themselves. You can also add the servers to your Favourites list if you don't want to save the IP addresses down yourself. Game servers already support up to 5 different master servers they can configure, so if one goes down, players can still check other ones.

Well I can't tell if the problem is: Player model not being litPlayer model seeming to have less level of polygonal detailTexture quality poorerEdge aliasingSomething elseWe need to know exactly what looks worse in-game. I can't tell if the player model being black is the problem he's describing, or just a problem with the lighting on that map. It might help if the screenshots were from a map with better textures for comparison (maybe BlueIce Nightfall), and taken from the same view point.

Yeah the difference here appears to be solely anti-aliasing. The first one looks like it has around 16x AA, but the second one looks like it has 2x or 4x AA. Try upping it all the way up in the Nvidia Control Panel.

Screenshots would help with diagnosing the problem! Make sure you use the /screenshot_tga command or take a print screen and save to a PNG file, so we know the problem isn't lossy artifacts in the image format itself (like JPEG does).

You can also use the Nvidia Control Panel to force on anti-aliasing for the game, and this smooths out the edges of all objects, instead of the jagged edges you get by default. Usually a setting of 4x is sufficient and you'll see very noticable improvement, but you can go higher if you want

Ravensoft's DNS servers aren't affected, so you can still resolve the correct IP address for the Ravensoft master server. However, the master server itself isn't accessible on the IP address.

No idea what the goal is. All I can think about when it happens is this video: https://www.youtube.com/watch?v=qRNlUjQ3Dvk (I don't mean any offence to Russian people with this video. It's funny to me because it's in a foreign language I don't know, so the subtitles are comically believable.)

Yes, lightmaps have much better quality than vertex lighting. Lightmaps are like custom textures detailing the lighting values for a surface. Meanwhile vertex lights only give lighting values to the vertices of a surface (corners), and these are blended over the surface to give a very rough approximation. Try playing on different maps with r_vertexLight 1 (then doing vid_restart) and you'll see just how low quality it can be.

The JKHub Master Server is currently down because of a technical problem. You can keep up-to-date with the thread here.

Server hosting companies shouldn't have any issue at all, servers have been using multiple master servers since the 90s Notably the GameSpy and QTracker master servers.

Server owners don't need any mod to make it work, they support multiple master servers out-of-the-box. You can also use a mod like the All Seeing Eye on your client to use the JKHub Master Server as well EDIT: Clarified this in the OP