Yes, very useful. I was getting ready to implement a new tool, but that's awesome, gonna try it right away.

Thanks, man. 

My func_greybox instances were removed, but there is a problem. This is how the prefab is supposed to look, but when I place func_instance like this it appears like this

Looks like intersection between the func_instance and another func_ is f..king the whole thing. 

- of course there is one. I positioned func_instance 32 units under the func_greybox and lifted the prefab 32 units in its .map

Intersection avoided, everything works. Bug reported. :) 

Damn it, that's disappointing. Would you be willing to send me the files so I could take a look? 

Just sent you. 

Turns out I was screwing up. It works fine. Thanks, Tens. 

You're welcome, any time! As I mentioned in my email to Adib, the test map he sent along revealed by way of no harm another bug, unrelated to the issue at hand, so I'm throwing together version 0.3.1 for release sometime today. When it's done I'll go update my own thread, if anyone's interested. 

Out of pure curiosity, what was the screw-up? 

I used the -r switch on a test map but wasn't using on the real map. Greybox asset and production asset were clipping each other. 

Something weird. If I travel in one direction inside my map, at some point everything disappear and I'm on the other end of the map's working area in JACK. I mean, outside the level, looking at the level from a distance, as if I'm teleported to zero or something.

Like I'm blowing a limit and being teleported around to the other side.

I already tried to use Arcane Dimensions settings (if it works for Swampy, gonna work for my level):

-heapsize 256000 -zone 4096

and even tried to increase zone to 8192. No luck.

Does anybody know what's happening? 

Is it close to map boundaries regardless of the settings you are using? 

You're moving more than 4096 units away from the centre of the world would be my guess, i.e. your map exceeds Quake's normal limits. The same thing would happen in any map if you were to move long enough in one direction using noclip.

If it just happens on one side of the map, it might mean that you simply need to centre your brushwork, i.e. select everything in-editor and move it to a more central position.

Unless I completely misunderstood what you meant. 

Yes, it's close to map boundaries and it's close to 4096, but about these heapsize and zone settings, don't they take care of it? 

No, the only ways you can fix it are:

1) make sure you move your brushes away from the limit on all sides

or

2) if your map is too large and exceeds the limit in two opposite directions, you can use an engine that supports protocol 999 (like current versions of Quakespasm). 

*as far as I know, I should add. I could be talking utter nonsense.

I should perhaps have waited for a more experienced and knowledgeable person to answer, but I sometimes get all giddy when I actually (think I) know the answer to something (as opposed to just asking lots of basic questions, which is what I usually do around here). "Ooh, ooh! I know this one!"

But yeah, to the best of my knowledge, that was the point of adding protocol 999 to QS, because there's no other way a map that exceeds the +-4096 limit (like ORL's Zeangala) is going to be playable. 

Adib: just realised a very similar discussion took place just a few days ago:

http://www.celephais.net/board/view_thread.php?id=4&start=17062&end=17071

Sorry for posting thrice in a row. 

 

I am opening fteqccgui.exe in mac with wine, but I don't know if my problem is this compiler or are the qc files I downloaded, I can't compile fine; because all qc files have string errors and using /**/ I cannot solve my problem.
H3LP 

What is the error saying? 

I just noticed today that an area of my map that I "finished" a while ago had a leak in it. Which is strange, because it's sealed, and I can run vis on it. Here's what I mean:
Exhibit A
And here's what it looks like in the editor:
Exhibit B

Now, like I said, the map is still considered sealed. It won't generate a pointfile, and although I haven't let vis finish because it takes a while now, that will start and complete the base vis without any issues.

So, I ended up fixing it by adding a new brush to cover the area over, but the whole thing made me curious as to what it was that caused this in the first place. Any ideas? Has anyone seen this before, any way to reliably reproduce?


As a side note, how concerned should I be about warnings about things such as efrags and marksurfaces? My map breaks both of those limits and gives warnings on developer 1. Same for missing textures; the console reports 20 missing textures, but I've never encountered them playing the map so it seems superfluous. 

That happens reasonably often - bsp just sharts out a harmless random HOM for no real reason. Best solution is just to slightly change the brushwork in that location and see if it goes away. 

If I create a custom wad for a map and later add more textures to that wad in order to enrich my map, will the map still use the wad's old textures correctly without glitches or errors? 

the only thing that matters are texture names, so you can add later as many textures as you want. 

I have a map in Tesseract. Not having to worry about breaking my map by adding textures anywhere other than the end of the list (so basically deciding everything you want to use at the start) is such a nice difference in Quake mapping. Only issue here is name conflicts but I'm pretty sure they're resolved based on the order they're in then which is fine...