I have been working on a city map for this game on and off for a few months. Like capture city but with internals. Today I compiled my map with Q3map2 in gtkradiant and I slammed into the MAX_EDGE_LINES wall. In the past I've also slammed into the maxvisportal wall. My question is: is this a wall in the DarkPlaces engine or is it just a hardcoded wall in the compiler. Second question: are there command line arguments that I can pass to that compiler to make MAX_EDGE_LINES higher if DP supports more.

Now, I've optimized my brushwork and got it to compile. The map is not near done so I may smash into it again. If this is a wall in DP could DP be improved so it does not have these limits?

Thankyou for your time, I like your game. It is good to have something to make worlds for in linux now that is all opensource.

As its the map compiler that freaks out i guess its q3map2 limit. Have you tried to lookup google what others say about this problem? I'm not a mapper so i can't help much in that regard.
Maybe you can work around it be making your map more simple and using models to create more details..

ok, I'm not sure what could be causing that, but did you check for stray entities?

Reading google (yeah, try to copy paste only your problem, it can do magic in google ) you have some extremly large brushes. Try to split the large ones (clipper tool and shift+enter) into smaller ones too. For more extre debugging, try to copy-paste parts of your map into a new one, and try to compile only that (this way you'd know where's the actual problem in your map.).

Doing the opposite is what "fixed" it (cosolidating brushes into 1 large brush). But the problem is not my map. The problem is that there is a limit in the compiler which is there because the quake 3 engine doesn't support more then 64000 something tjoints. Does darkplaces engine support more then 64000 tjoints and if so how can I remove or change the upperlimit in the opensource q3map2 compiler (can I pass it an argument). Same with vis (how many portals does dp support, should I edit the compiler's source to match that). In the q3map2 sourcecode the limit is a "static variable". We need less limits.

I am only 1/2 done with the map so I will probably hit into this wall even with the optimized brushes I have now. Is this limit in the darkplaces engine or just in the map compiler (which is opensource and I'm on linux so it can be edited if need be)? How might I rm the limit in the compiler?

I hit the damned limit again. This is absolutly pathetic. I have optimized much of my brushwork and I'm trying to get the outline of the map done (deleting some of the map is not an option). I need a technical solution. Can you please help me with this. Is it a limit in darkplaces or the map compiler? If it is in the compiler how do I raise the limit? Please help me your community from what I read on this site is helpful.

--- FillOutside ---
6300 solid leafs
1580 leafs filled
4066 inside leafs
--- CullSides ---
23954 hidden faces culled
183 coincident faces culled
--- ClipSidesIntoTree ---
--- FaceBSP ---
5416 faces
7360 leafs
--- MakeTreePortals ---
106 tiny portals
0 bad portals
--- FilterStructuralBrushesIntoTree ---
1808 structural brushes
7010 cluster references
--- NumberClusters ---
3644 visclusters
9581 visportals
11790 solidfaces
--- WritePortalFile ---
--- FloodAreas ---
2 areas
--- AddTriangleModels ---
--- AddEntitySurfaceModels ---
--- FilterDetailBrushesIntoTree ---
9822 detail brushes
16353 cluster references
----- FogDrawSurfs -----
0 fog polygon fragments
0 fog patch fragments
0 fogged drawsurfs
--- SubdivideFaceSurfaces ---
--- FixTJunctions ---
************ ERROR ************
MAX_EDGE_LINES
Disconnecting

It is a static variable.
Look at https://zerowing.idsoftware.com/svn/rad ... junction.c

see #define MAX_EDGE_LINES 0x10000
If that was changed to #define MAX_EDGE_LINES 0xFFFFF
there would be no problem (might as well change #define MAX_ORIGINAL_EDGES 0x10000 too). Unless DP can't handle it (anyone know?). There seems to be no make file for q3map2, so anyone know how to compile it, or maybe how to patch the binary, or does anyone have a development q3map2 they can patch and compile?

fuck off mikeeusa

Fixed it by coding and recompiling. If anyone want's the binary ask. Now I can make my map mega detailed and ultra huge (God willing). ha Ha Ha

You were happy I was having troubles weren't you.

leileilol wrote:fuck off mikeeusa

???
mikeeusa? where?

this is mikeeusa. But leileilol... do not use the f word on this forum. NEVER.

_________________
Perhaps one of the most interesting words in the English language today, is the word "fuck". Out of all the English words that begin with the letter 'f', "fuck" is the only word referred to as the "f word". It's the one magical word. Just by its sound it can describe pain, pleasure, hate and love. Fuck, as most words in the English language, is derived from German: the word "fricken", which means "to strike". [...]

divVerent wrote:Perhaps one of the most interesting words in the English language today, is the word "fuck". Out of all the English words that begin with the letter 'f', "fuck" is the only word referred to as the "f word". It's the one magical word. Just by its sound it can describe pain, pleasure, hate and love. Fuck, as most words in the English language, is derived from German: the word "fricken", which means "to strike". [...]

I want a "works cited" for that divVerent you plagiarist!!!

Everyone knows this was Monty Python.
_________________
We're a club of tuneful rovers!
We can sing in every clef!
We can even hit the high notes!
It's just too bad we're tone deaf!

linuxkangaroo wrote:Fixed it by coding and recompiling. If anyone want's the binary ask. Now I can make my map mega detailed and ultra huge (God willing). ha Ha Ha

I would like to have that modified version or does someone else has a mirror ??

You do you need that stupid hack you just need to make maps the proper way

esteel wrote:You do you need that stupid hack you just need to make maps the proper way

I did, only it became a bit larger then the engine could handle

Anyway, I would like to play around with that thing so if anyone could offer me a downloadable link, I would be very gratefull . . .

Well that other guy was banned for several reasons and all the other mappers here seem to be able to map correctly and do not need to hack the map compiler.. so.. i'd still say you do something wrong

esteel wrote:Well that other guy was banned for several reasons and all the other mappers here seem to be able to map correctly and do not need to hack the map compiler.. so.. i'd still say you do something wrong

I probably did but I don't know where and getting through 20.000+ brushes to find that one (or two) brushes that are wrong is simply not do-able, hense I asked for the hacked compiler . . .

Well i guess in that case you will have to compile q3map2 yourself.. the neccessary changes are explained a few posts up there. Its just one line that needs to be changed in the code. I never tried to compile radiant though so i can't help you there.

Apprentice wrote:

esteel wrote:Well that other guy was banned for several reasons and all the other mappers here seem to be able to map correctly and do not need to hack the map compiler.. so.. i'd still say you do something wrong

I probably did but I don't know where and getting through 20.000+ brushes to find that one (or two) brushes that are wrong is simply not do-able, hense I asked for the hacked compiler . . .

Nono its not one or two brushes thats to blame its the overall edges beeing to plentyfull (been using the CSG lately? Optimize your shapes and perhaps turm some comprex repetetive gemoetry into models and opyimize thise by hand.

tZork wrote:Nono its not one or two brushes thats to blame its the overall edges beeing to plentyfull (been using the CSG lately? Optimize your shapes and perhaps turm some comprex repetetive gemoetry into models and opyimize thise by hand.

At this stage, I think that I can better abandon the whole thing . . .

If your map is that big you want to abandon it? Must have been a lot of work, why do that?

esteel wrote:If your map is that big you want to abandon it? Must have been a lot of work, why do that?

It was and I got it compiled using -notjunc, but that's nothing more then a quick turn-around and without that hacked compiler, I'm basicly where I've started . . .

Isn't it better to just fix the map then rely on strange hacks that should not be needed if its done right from the start? Especially if it was that much work..

esteel wrote:Isn't it better to just fix the map then rely on strange hacks that should not be needed if its done right from the start? Especially if it was that much work..

Again, the map is over 20.000 brushes so "fixing" it isn't really an option. Besides, I can compile it with -notjunc though it would've been preferable if I can compile it without the parameter . . .

Just as a co-incidence i got the same error on a map I compiled yesterday.
My findings were
1. This fails on the lighting portion of the compile process
2. The cause was a 16 face prism brush (beveled at one edge). This single brush almost DOUBLED the BSP build time. I don't remember if it was a detail or not.

If Apprentice has a few brushes with many faces he should try removing them just as a test. The difference in build time may be STAGGERING.

Most likely not a detail then. yeh complex brushed are generaly a bad thing, avoid if at all possible.

That usualy means split the geometry into a few simple brushes or make a model out that that section/detail.