what is required to make a .prt file?
im using gtkraidiant 1.5 for Jedi Academy
for example i never got a .prt until i put a skybox or smthing but now that i put in a new terrain i stopped getting a .prt so my vis process stopped working so i get the “missing .prt” thing
Make sure you run BSP -meta, this should generate a .prt file which can then be used by the VIS compile stage.
If you are using a batch file to run Q3Map2, please post it. If not, how do you run the map compiler, through GTKRadiant?
[QUOTE=ACROBAT;185669]-meta makes a prt table?
I thought the first part of -vis made that.[/QUOTE]
Yes -meta makes the .prt file and vis stage calculates the visibility of each portal based on that file. After vis is done, the file is deleted, unless you use -saveprt, (in the vis stage…) it should be default tho. So if you did not get prt file from the single bsp -meta, the compiler has failed I think.
lol I just have the same problem. My -meta does not create any .prt file :<
I tried it with the compiler settings of GTK Radiant 1.4 and q3map2GUI
What can I try?
[QUOTE=eiM;185685]lol I just have the same problem. My -meta does not create any .prt file :<
I tried it with the compiler settings of GTK Radiant 1.4 and q3map2GUI
What can I try?[/QUOTE]
Everything ok with the map file? You could send it to me or a fellow mapper who can try to compile it.
well the only issue it has is a LEAK which I actually do not understand as I have a box around my map. Prolly some entity. But that should not be the reason I guess?
Might be. Or then it might just be a model etc. that has origin inside a structural brush. Hand your map over and I’ll have a look if you will.
So you’re saying -meta creates the .prt with nothing in it.
Then -vis fills in the prt table.
I mean if you had a already existing prt from meta…i dont even know why u would need a -vis compile other than to insert the already calculated values into the bsp but the heavy lifting would already be finished.
That doesn’t sound like it makes much sense to me…
Um, no.
This is a short (simplified) summary of how I think the compiling process works. The -meta stage chops up the map into areas and assigns the map’s brushes to one of these areas. Each surface of an area which borders with another area without a brush in between is called a portal. These portals are printed out to a .prt file, while the whole map and zones are written to a .bsp file.
The -vis stage will later use this .prt file to calculate which portals allow a clear line of sight to other portals, thus calculating how many areas will be visible.
ye so what happens if the prt file is missing? does it get deleted?
The portals are working when I use -meta -debugportals so there is no problem with these… but there simply is no prt file.
edit:
it must be the map itself. When I compile some random map it works fine. Can it be too big or too many bad setup portals which kill the prt saving?
To know that, you’ll have to check the compile output logs.
By any chance, did you specify a custom block size?
hm found nothing about vis or prt in the -meta process 
No I havent defined any custom blocksize… should I?
edit:
I just copied a small part of my map to test the vis part once. Even with a single room it does not work, it saves no prt file. So what setting could I have ****ed up that q3map2 fails at creating the prt file?
[QUOTE=eiM;185781]hm found nothing about vis or prt in the -meta process
No I havent defined any custom blocksize… should I?
edit:
I just copied a small part of my map to test the vis part once. Even with a single room it does not work, it saves no prt file. So what setting could I have ****ed up that q3map2 fails at creating the prt file?[/QUOTE]
I spent a good 10 mins with your map. Most time trying to compile. Pretty nice looking. Even tho it isn’t structucally sealed (found some holes from the doorways etc.), it doesn’t matter that much because you have that box around it.
Anyways I found your problem. The leakage I found was your command post. You have most likely copied the cp from a decompiled map? Every command post clip and the toi had origin keys that were not matching. Delete those keys and add manually an origin brush for each of those entities.
Also you are using 1.4.0 and that’s something I noticed aswell. The big terrain of yours gave me a good list of degenerated planes and such errors. As you probably don’t get any error messages of it, just ignore this. This sometimes happens when you open a terrain made in 1.4.0. in 1.5.0. Anyways the for-me-problematic entity number of the terrain is 918 and it is located at the bottom of the map.
After fixing the command post (and the radiant “fixing/****ing up” the terrain) I could compile just fine and get the prt file. The vis started compiling fine, but I didn’t bother to finish it, because of a major vis data size of 1 834 568 bytes.
I hope you dont mind sending me the files again =)
So in general, should I go on for 1.50 version or is it not a big problem to keep 1.40
[QUOTE=eiM;185786]I hope you dont mind sending me the files again =)
So in general, should I go on for 1.50 version or is it not a big problem to keep 1.40[/QUOTE]
You better use 1.4.0 for your map. The problem is that when you open the map in 1.5.0 some brushes get missing or get misplaced or deformed. In general if you use 1.4.0 or 1.5.0, keep the radiant version same for the map. Moving a map from 1.4.0 to 1.5.0 is many times problematic. That’s why you should stick to 1.4.0 atleast for the time you finish your project, or as long as you want.
Did you get your map compiled or what? You fixed the origin issue? I didn’t quite understand the first phrase. If you want me to send the map back to you, there is no reason because my 1.5.0 f***ed up the terrain and probably some else stuff. If you meant you want to send me a file again, feel free.
Try running the brush cleanup plugin, it should clean up any bad brushes with degenerate planes.
major vis data size of 1 834 568 bytes.
Sounds like you need to do some serious optimizing. Convert stuff to detail and put a caulk-hull around it. That giant cube you have around the map I hope is just temporary, because that attributes to a large portion of why your vis data is so big.
ye the cube around was just for testing purposes 
I did alot into detail, though there is still much to be done and I know that.
Sage I’d appreciate if you send me your fixxed file just to see what you actually changed. Not that I do some mistakes at the CP e.g. 
I guess I’ll need to go deeper into the whole caulk-hull and stuff. Never done such, what is it for? I know about detail/structural brushes and the whole hint brush shizzle… though never used any caulk hulls
But those brushes are made in 1.4.0 and it doesn’t whine about it or anything. But when you open the map in 1.5.0… Chaos.
[QUOTE=obsidian;185790]
Sounds like you need to do some serious optimizing. Convert stuff to detail and put a caulk-hull around it. [/QUOTE]
With a quick look the detail vs. structural seemed clean enough. The structural geometry seemed quite complex aswell.
[QUOTE=obsidian;185790]
That giant cube you have around the map I hope is just temporary, because that attributes to a large portion of why your vis data is so big.[/QUOTE]
Very true. The box is a big problem. You (eiM) should do a run around your map with detailed filtered off, seal it (doors are esp. to check) and remove the box around it. That’s for overall to do, but doesn’t contribute to the actual problem atm which was/is (?) leaking and prt not getting compiled.