MAX_PATCH_PLANES jedicouncilgcx map

[ensiform]

This map produces MAX_PATCH_PLANES error in OpenJK.  I know it happens at least as old as April 20th compiles (JAWA) servers use builds from then.

 

RMG removal stuff maybe?

 

from jawa server:

 

That spammed CM_ message shows up when developer is 1.

[Xycaleth]

Try checking out a copy of the code from before the RMG removal and see if it still produces the error.

 

Failing that, you'll probably need to try bisecting until you find the revision which does produce the error.

[ensiform]

Tested the April 1st build from buildbot and the map loads fine.

 

Even the April 22nd one does and the May 6th one does... but my win64 bit local build does not.

 

Happens on a fresh x86 build and x86_64 on windows too.  But not on http://builds.openjk.org/openjk-2014-05-06-15939504-windows.zip  I can't see anything in the changelog that would even remotely be related though.

 

It was already happening before I added 6302b86155f65383ea9fd7ba870409df1c28ae87 and 97b410bf53cacae4d63ca02352a2be9f46e0424c

[ensiform]

Happens in current SP as well.

[ensiform]

Bump.  @@Xycaleth is investigating.

 

Oldest revision that the map works is eda37de supposedly.

 

Seems some newer ones still work.

[Xycaleth]

I posted this on the github issue, but I'll post it here too. The problem doesn't happen if OJK is compiled with VS2010 which makes things a bit more fun when debugging...

[ensiform]

Fixed in https://github.com/JACoders/OpenJK/commit/60072ca08353db3e82cd068880775c4fda734ace

[Oobah]

This the original gcx or the version I remapped?

 

If it's mine then I can answer why you may "potentially" hit the issue, looking at it from a mapping perspective.

 

Used patches for example like on the little bars to make it so the glass holding beer/wine has an interior molding so when you look inside the bar glass you don't see just nothing.  For looks purely.  Since I still use base JK, at least till openjk hits a stable release, I didn't hit the issue cause obviously base jk didn't see any patches I put around as being to intense on the rendering portion of the engine.  In general the main reason patch issue comes up, like in JO, you have to many models or patches in a single cell area(more of an issue for mappers than players, less you use altered game code, different issues but bare with me since they're similar).  Single cell area is basically a single room or box.  You have to much content clustered or cloistered together in a single spot the game engine doesn't like it and it hits the game limit on such and such an issue.  JA, unlike JO, doesn't really face or suffer from that problem persay less you're a really sloppy mapper, or again you're using the source with altered game code.

 

 

If it's the original, that's simply due to a map made on an older version of radiant and did in a different time and place with a different setup of mapping.  Lot of people who made some of the first big maps in JA were people who came from JO style of mapping.  Hence why on ex_jedi_temple, for example, the creator did brush work for the chairs instead of models(JO is 128 I think?).  People probably weren't to sure of the game limitations on map models.  Which honestly is just tied into the ent limits for JA, outside of clustered in a single area, you can add up to the 4096 ent limit for map models in JA.

 

I voted for gcx, original, on jawa 1 time and I think it crashed the server, good to have a better idea of what caused it. 

[ensiform]

The ent limit is 1024-2 fwiw.  4096 is the absolute limit by radiant that you can have of ALL entities even ones that get stripped out during compile.

 

AFAIK there shouldn't be a limit on misc_models that get compiled into bsp.  But misc_model_statics may be significantly lower in JO than JA.  We upped the limit there to 4k from whatever it was in JAMP defaults if using our cgame client mod or JA++'s

[eezstreet]

misc_model_static doesn't even exist in JK2 (?)