(Help) .prt files in GoldSRC Created 7 years ago2017-07-20 11:49:05 UTC by Admer456

hlvis.exe gets stuck at 70% on my monstrosity of a map, that is fun_kobbl.
That's why I decided to open the portal file to analyse why it's taking so long and how to improve the compile times.

In Crafty:

J.A.C.K. doesn't say anything, and I'm not really willing to port the map into VHE and Sledge just to try out opening .prt files.
Dr. Orange mentioned that I can't open .prt files in the case of GoldSRC.

I've also opened the .prt file in Notepad++, and this showed up:I believe that these 2 numbers are the ones for numportals and stuff when hlvis.exe starts up.
Then there's a row of these numbers:

[From line 72]
50
1
1
1
1
1
1
1
20
38
17
1
1
1
31
11
[To line 89]
As well as more such numbers, and A LOT of 3D coordinates, which I expected to appear there.

The questions are:
Question #1: Is there a correct way to open these .prt files?
Question #2: What kind of signature is Crafty talking about?

Ok this might be a stupid one, but here goes: have you considered giving hlvis more time?

Is it crashing at 70%?

Yesterday, I let it run for 2 to 3 hours and it was stuck at 70% for 30 to 40 minutes. I should let it work more, shouldn't I?

Ask someone to compile it for you. This way we can see if it's really stuck or just needs more time.

If you are willing to give me the files I could try compiling for you.

Have you tried the 64 bit version of hlvis?

He might be running a 32bit OS

Isn't it obvious?

I've shown it a lot of times, and I'm showing it again, my 2007 laptop. The one I use to make my maps with.
I've never had a 64-bit OS in my life, lol. Only 16-bit and 32-bit ones.

But wouldn't the biggest difference in using 64-bit compiling tools be the one about being able to allocate more memory? I don't think that using a 64-bit version of hlvis.exe (if it exists, it does in Sven Co-op, though) would that significantly improve my compile speeds.

Well in theory it might, due to being able to allocate more ram, might also be the reason why it gets stuck, also maybe because swapping occurs.

Latest VHLT is x64.

Umm... but hlvis.exe only takes about 20 to 40MB of RAM on my end.
Only hlrad.exe can be so memory-hungry.

Anyway, guess what. I decided to switch to Svengine.
I instantly didn't regret it.

A map like this totally deserves the shift to Svengine. :3

Lastly, is the latest VHLT x64-only, or not?

No there are both 32 and 64 bit versions of VHLT.

But once I build my dream PC... MUAHAHAHAHAHAHAAAAA

Okay, so is there apparently no way of opening .prt files for GoldSRC?

@Cd5ssmffan That doesn't do anything.

Most sites like those usually try to get you to download adware disguised as a file converter.

I doubt that's the .prt file format I'm looking for.

Edit: Posted the below, then realized its not terribly relevant. Move along

---

Couple thoughts:

I've had compiles in un-optimized or overly complex maps back in the day on potato hardware that took over 24 hours. So, you may just need to wait longer.

Alternately, you can sometimes track errors or crashes in cases like this down in a way similar to how you might track a leak (I know this isn't necessarily a leak).

Try this:

Cover the whole map in one giant solid brush. Compile the map (should go pretty quick). No crash? or compile hang? Uncover half the map and compile again - keep doing that until you reach the hang/crash again. You should then have more info about your problem.

Either your compile logs will show that you were approaching an engine limit as you started uncovering more geometry, or you will be able to narrow down which piece of the map was uncovered and is causing your problem.

You know, I opened Compilator 3 which I had installed since early 2016.
I configured it for Sven Co-op, and OH MY GOD!

I've never been so happy for a compiling time!
LeafThread gets stuck at 16% (1080 out of 6641), 43% (2885) and it's still compiling.

Also, CSG and BSP took 1 minute and 30 seconds each, now they only take 30 seconds each. XD

I've managed to open the portal file:HOLY HELL, no wonder VIS takes more than 2 hours to process the darn map!
Alright, now it will be easier to see what's wrong.

But I'm really confused about this part:I'll have to look further...
The windows, for example:In the editor, they're covered with a hint+skip brush, just like they should.

But I just don't understand why these smooth window things produce such nightmarish results, even though they're like this:Also, this thing is func_detail so it doesn't make VIS work longer:This stuff is plain unpredictable.

Oh... NOW I SEE.
THIS is also func_detail:Yay, looks like we can fix one part of the issue. :DDDDD
Kids, always remember to double-check for func_details so you can cover them too.

P.S. SC-VIS.exe managed to finish processing the map in 10101 seconds. Seriously.

And yet another reason why VIS takes so long:Yeah, gotta turn it to func_detail right now.

Anyway, big thanks to Solokiller for reminding me of Crafty.
It truly is a crafty tool, as the name suggests.