Slight issue with map compiling (hlrad) Created 5 years ago2019-01-26 20:11:58 UTC by SirCobalt

I'm currently in the process of creating a sort of custom campaign mod for Half Life. I'm using the J.A.C.K editor as I believe it's called and after exporting the map to test it the map is completely lit up with no light functionality whatsoever. I've had this problem before and I managed to fix it but the moment I get back into Half Life modding and making maps using a different and supposedly far superior editor compared Half Life SDK, it has to break again. Here's what it tells me...

hlcsg v3.4 VL33 (Feb 2 2014)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (vluzacn@163.com)
----- BEGIN hlcsg -----
Command line: "C:/Program Files/Jackhammer/halflife/hlcsg.exe" E:\SteamLibrary\steamapps\common\Half-Life\valve\maps\reception
Arguments: E:\SteamLibrary\steamapps\common\Half-Life\valve\maps\reception -low -wadautodetect
Entering E:\SteamLibrary\steamapps\common\Half-Life\valve\maps\reception.map

Current hlcsg Settings
Name | Setting | Default
---------------------|-----------|-------------------------
threads [ 8 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
reset logfile [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 33554432 ] [ 33554432 ]
max lighting memory [ 50331648 ] [ 50331648 ]
priority [ Low ] [ Normal ]

noclip [ off ] [ off ]
null texture stripping[ on ] [ on ]
clipnode economy mode [ off ] [ off ]
clip hull type [ simple ] [ simple ]
onlyents [ off ] [ off ]
wadtextures [ on ] [ on ]
skyclip [ on ] [ on ]
hullfile [ None ] [ None ]
wad configuration file[ None ] [ None ]
wad.cfg group name [ None ] [ None ]
nullfile [ None ] [ None ]
nullify trigger [ on ] [ on ]
min surface area [ 0.000 ] [ 0.000 ]
brush union threshold [ 0.000 ] [ 0.000 ]
map scaling [ None ] [ None ]
light name optimize [ on ] [ on ]
UTF8 game_text [ on ] [ on ]

Using mapfile wad configuration
Wadfiles not in use by the map will be excluded
Wadinclude list :
[zhlt.wad]

CreateBrush:
(0.09 seconds)
CSGBrush:
(0.21 seconds)

added 15 additional animating textures.
Using Wadfile: \SteamLibrary\steamapps\common\Half-Life\valve\halflife.wad

• Contains 100 used textures, 99.01 percent of map (3116 textures in wad)

Using Wadfile: \SteamLibrary\steamapps\common\Half-Life\valve\liquids.wad

• Contains 1 used texture, 0.99 percent of map (32 textures in wad)

Wad files required to run the map: "halflife.wad;liquids.wad;"
Texture usage is at 0.93 mb (of 32.00 mb MAX)
0.53 seconds elapsed

----- END hlcsg -----

hlbsp v3.4 VL33 (Feb 2 2014)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (vluzacn@163.com)
----- BEGIN hlbsp -----
Command line: "C:/Program Files/Jackhammer/halflife/hlbsp.exe" E:\SteamLibrary\steamapps\common\Half-Life\valve\maps\reception
Arguments: E:\SteamLibrary\steamapps\common\Half-Life\valve\maps\reception -low -chart

Current hlbsp Settings
Name | Setting | Default
-------------------|-----------|-------------------------
threads [ 8 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ on ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 33554432 ] [ 33554432 ]
priority [ Low ] [ Normal ]

noclip [ off ] [ off ]
nofill [ off ] [ off ]
noinsidefill [ off ] [ off ]
noopt [ off ] [ off ]
no clipnode merging [ off ] [ off ]
null tex. stripping [ on ] [ on ]
notjunc [ off ] [ off ]
nobrink [ off ] [ off ]
subdivide size [ 240 ] [ 240 ] (Min 64) (Max 512)
max node size [ 1024 ] [ 1024 ] (Min 64) (Max 65536)
remove hull 2 [ off ] [ off ]

SolidBSP [hull 0] 500...1000...1044 (0.20 seconds)
Warning: === LEAK in hull 0 ===
Entity monster_scientist @ (-1420,1188, 64)
Error:
A LEAK is a hole in the map, where the inside of it is exposed to the
(unwanted) outside region. The entity listed in the error is just a helpful
indication of where the beginning of the leak pointfile starts, so the
beginning of the line can be quickly found and traced to until reaching the
outside. Unless this entity is accidentally on the outside of the map, it
probably should not be deleted. Some complex rotating objects entities need
their origins outside the map. To deal with these, just enclose the origin
brush with a solid world brush

Leak pointfile generated

SolidBSP [hull 1] Warning: Ambiguous leafnode content ( EMPTY and SOLID ) at (464,536,156)-(465,537,244) in hull 1 of model 0 (entity: classname "worldspawn", origin "", targetname "")
500...Warning: Ambiguous leafnode content ( EMPTY and SOLID ) at (464,487,156)-(465,488,244) in hull 1 of model 0 (entity: classname "worldspawn", origin "", targetname "")
956 (0.15 seconds)
Warning: === LEAK in hull 1 ===
Entity info_player_start @ (-256,-144, 100)
SolidBSP [hull 2] 500...794 (0.11 seconds)
Warning: === LEAK in hull 2 ===
Entity light @ (-1408,1088, 144)
SolidBSP [hull 3] 500...Warning: Ambiguous leafnode content ( EMPTY and SOLID ) at (464,536,174)-(464,537,226) in hull 3 of model 0 (entity: classname "worldspawn", origin "", targetname "")
Warning: Ambiguous leafnode content ( EMPTY and SOLID ) at (464,487,174)-(464,488,226) in hull 3 of model 0 (entity: classname "worldspawn", origin "", targetname "")
1000...1032 (0.26 seconds)
Warning: === LEAK in hull 3 ===
Entity info_player_start @ (-256,-144, 100)
Reduced 3704 clipnodes to 3176
Reduced 684 texinfos to 538
Reduced 101 texdatas to 98 (4448 bytes to 4316)
Reduced 4558 planes to 1635
FixBrinks:
Increased 3176 clipnodes to 3232.

Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 20/512 1280/32768 ( 3.9%)
planes 1635/32768 32700/655360 ( 5.0%)
vertexes 8120/65535 97440/786420 (12.4%)
nodes 1268/32767 30432/786408 ( 3.9%)
texinfos 538/32767 21520/1310680 ( 1.6%)
faces 9366/65535 187320/1310700 (14.3%)

• worldfaces 9035/32768 0/0 (27.6%)

clipnodes 3232/32767 25856/262136 ( 9.9%)
leaves 886/32760 24808/917280 ( 2.7%)

• worldleaves 674/8192 0/0 ( 8.2%)

marksurfaces 10497/65535 20994/131070 (16.0%)
surfedges 42310/512000 169240/2048000 ( 8.3%)
edges 21180/256000 84720/1024000 ( 8.3%)
texdata [variable] 4316/33554432 ( 0.0%)
lightdata [variable] 0/50331648 ( 0.0%)
visdata [variable] 0/8388608 ( 0.0%)
entdata [variable] 6610/2097152 ( 0.3%)

• AllocBlock 14/64 0/0 (21.9%)

98 textures referenced

Total BSP file data space used: 707236 bytes

Wad files required to run the map: "halflife.wad;liquids.wad;"
2.58 seconds elapsed

----- END hlbsp -----

hlvis v3.4 VL33 (Feb 2 2014)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (vluzacn@163.com)
----- BEGIN hlvis -----
Command line: "C:/Program Files/Jackhammer/halflife/hlvis.exe" E:\SteamLibrary\steamapps\common\Half-Life\valve\maps\reception
Arguments: E:\SteamLibrary\steamapps\common\Half-Life\valve\maps\reception -low

There was a problem compiling the map.
Check the file E:\SteamLibrary\steamapps\common\Half-Life\valve\maps\reception.log for the cause.

----- END hlvis -----

hlrad v3.4 VL33 (Feb 2 2014)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (vluzacn@163.com)
----- BEGIN hlrad -----
Command line: "C:/Program Files/Jackhammer/halflife/hlrad.exe" E:\SteamLibrary\steamapps\common\Half-Life\valve\maps\reception
Arguments: E:\SteamLibrary\steamapps\common\Half-Life\valve\maps\reception -low

There was a problem compiling the map.
Check the file E:\SteamLibrary\steamapps\common\Half-Life\valve\maps\reception.log for the cause.

----- END hlrad -----

I would very much appreciate your help.

basically you have a leak, the map should be completely sealed from the void

So another problem has arisen. The map took ages to compile and when it did the lighting was still off. I looked at the log and it's telling me that the map is too complex and I need to switch to 64bit hlrad but I don't know how to do that. Also there's some strange yellow particles floating around a scientist I placed and I don't know why. Thanks for replying though.

What happened is basically that HL RAD ran out of available memory. How much RAM do you have? If you've got more than 4 GB, you should definitely try running the 64-bit version of RAD.Basically, you can switch to the 64-bit version by going to your settings, and changing the build tools, or compile tools, or something third, depending on how the map editor calls it. Simple as that.
If you can't use the 64-bit version, or you have even less than 4 GB of RAM, well, you can use less textures, since J.A.C.K. can use lots of memory if you're using too many WADs. If that doesn't do it either, then you can resort to the Compilator 3. It's sweet and manages the compilation process for you, and in some cases it can make it a bit faster when the map editor is closed.

As for the leak, I'm thinking you've now made a huge hollow box around the map. Don't do that. You can read about leaks here.
If you have small gaps that cause a leak, simply close them with either extra brushes, or by extending a nearby brush.

The strange yellow particles are probably there because the scientist, or a part of the scientist, is inside of the floor or any other solid. Make sure he spawns in the air, if you can't get rid of the particles otherwise.

I’m currently working on that issue. For now I’m going to be asking a lot of questions if you don’t mind.

At the beginning of the map there’s a trigger that activates a multimanager which activates both a scripted sentence and an on screen message. However the problem is that for some reason the message appears right on que but the sentence takes a few seconds to activate. I’ve checked and there’s no value in the delay before activation tab nor in the multimanager so I don’t know what’s going on.

Also I’m trying to get a scientist to loop between two scripted sequences but the problem is that he goes to one and just stays there.

ALSO at a later part in the map a vehicle is supposed to traverse across the map from one point to another. There’s no problem here it works fine but I’m wondering if there’s a way to get it to make a sound without giving it a move sound (because I made it a door entity) and just swapping that sound file in the mod folder with the desired sound. If you know what I mean.

Thanks

"Also I’m trying to get a scientist to loop between two scripted sequences but the problem is that he goes to one and just stays there."

Each scripted_sequence should target one another. seq1 targets seq2 and vice-versa, for example. I've done that in my mod once, but not sure if I used aiscripted_sequence or the regular scripted_sequence.

"However the problem is that for some reason the message appears right on que but the sentence takes a few seconds to activate."

You could delay the text message.
I'm not sure what causes this. Try turning on the "multi-threaded" flag in the multi_manager. Or delay the message by 0.01 seconds, and have the sentence without delay.
(might be that the specific sentence has a delay by itself, caused by the game files?)

"I’m wondering if there’s a way to get it to make a sound without giving it a move sound"

Yeah, you can use an ambient_generic entity, with initial volume set to 10, start silent and medium radius turned on. Then as you trigger the vehicle, you will also trigger the sound-emitting entity.
The only issue there is that the sound will always be emitted from the sound entity's position, meaning that it is going to sound strange if the vehicle is already far away, but the sound remained still.

Thanks, I was worried I might not get anything. Sorry my reply was a bit vague because I was rushing it. The two scripted sentences do both have each other’s names in the target boxes. I have learned to uncompile half life maps to view in the editor to see how valve have done it (I’m not trying to steal anyone’s maps or anything in case that’s what you might be thinking) and I noticed they used things called ai nodes. I’m wondering if these could have a role in scripted sequences?

I’ll see what I can do with the multimanager and the vehicle.

It's okay. The situation has been contained. All I needed to do to make the sequences loop was check the repeatable flag for each one. The scripted sentence and the screen message problem appears to have resolved itself.

"ai nodes"

AI nodes are just a 'GPS system' for the NPCs. When you place these nodes, you're giving NPCs confident information as to what way they can go. Without nodes, they use pathfinding and sometimes they're not too good at it.

I wouldn't call it confident. Very rarely in Half-Life you can do without pushing npcs forcibly

Confident as in, the AI will be 100% sure what way to go. Should the way they go be correct or not, eeeeh, it depends on the mapper and how the nodes are placed.

Use sledge you heathen.

Pretty sure he'd have the same questions and problems even if he had used Sledge (if not some more stability issues too). Though, what I've just said won't be valid after the next couple of years.

So now this problem has just arisen. I'm trying to get a guard to say something and afterwards proceed to walk over to a button were he'll do an animation and the door will open. I think this has done something because now I get this error.

SolidBSP [hull 0] 500...Warning: Ambiguous leafnode content ( EMPTY and SOLID ) at (-2464,-1422,-256)-(-1920,-1280,-64) in hull 0 of model 0 (entity: classname "worldspawn", origin "", targetname "")

And it goes on for ages. The hlvis supposedly froze at one point so I cancelled it. Only when the map started, no scripted sentences worked.

Also what's wrong with J.A.C.K?

That error has nothing to do with scripted_sequences or any point entity for that matter.

Vluzacn says this about the error:

This is actually the warning that is called "mixed face contents" in previous versions.
It is often caused by two planes or two vertexes that almost coincode with each other but leave small gaps (less than 0.1 unit). Open the .map file, not the .rmf file, then go to that coordinates, zoom in and see if there are tiny gaps between lines, like in the picture. If there are, remake the brushes in your .rmf file.
If you still can't fix it, try to convert the brushes to func_details, which will eliminate the "ambiguous leafnode content" warning and minimize its consequence (but it won't fix the gap). If what has the "Ambiguous leafnode content" problem is an entity (such as a func_wall), you can also manually add keyvalue "zhlt_detaillevel" "1" and "zhlt_clipnodedetaillevel" "1" to the entity, so that it takes the advantage of detail brushes.Source

Make sure that when you work with brushes, you have snap-to-grid enabled.

If HL VIS is stuck, your map needs some optimisation. Can you show us some screenshots of the map?
Usually, tiny brushes that are merely architectural details (or even prop-like things like signs, fences, railings, tables, chairs, lamps, small rocks etc.) should definitely be func_detail.

The compile warning is really just a warning. It also means that the geometry is a bit funky or unusual, so the compiler can interpret the geometry in more than one way (hence ambiguous). Generally, it's completely fine, not much to worry about.

Are you triggering the sequence that the guard is supposed to do? Some more context is needed, and some of the keyvalues that are being used by the entity setup. Try the aiscripted_sequence entity, too.

Not much is wrong with J.A.C.K. except for the few bugs it has and it's closed-source (and the author pretty much hasn't updated it in a while). Sledge is open-source and will surpass J.A.C.K. one day, I hope. But hey, if it weren't for those two, almost all of us would be using hacked Hammers, or Hammer 3.4, or even worse, QuArK. D:

Oh, also:
You can open your map's portal file to analyse what VIS has to calculate.
Where your .bsp file resides, there will also be a .prt file. Open it with a text editor, and you'll see something like this:

1681
3982
2
1
1
10
1
1
1
4
15
4 688 45 ( 400, 500, 600 ) etc.

You'll want to skip the first two lines, because those are the number of portals and visleaves, IIRC. Then delete whatever is between them and the coordinates (basically, delete the "garbage" numbers):

1681
3982
4 688 45 ( 400, 500, 600 ) etc.

The last line that I wrote won't actually look like the one in a .prt file, but you can get the idea.
This file is generated per each compile.
Then, you open the .prt file with the map editor: Map->Open Portal File.

Hold on, I'm currently in the process of completely refurbishing my map. I can provide screenshots once it's finished. Also what's the difference between a regular scripted sequence and an aiscripted sequence? Don't they both do the same thing?

Yeah, the guard is supposed to say something and once finished proceed to walk towards a button and press it. This in turn will open the doors. Everything is set up like it should be, there aren't any problems that I can find. I could try and use an aiscripted_sequence entity instead but I'm not sure exactly in which way. I once made a mistake when I placed an aiscripted sequence instead of a normal one and the sequence didn't work so I can't say I really trust them.

Also... func_detail. How do I know which details to assign this entity to? And also what exactly does it do?

Sorry about all the questions, my knowledge on the Goldsource engine is quite limited.

An aiscripted_sequence forces the AI to do it. It's like the God of AI, even prevents death while it's being executed.

func_detail basically prevents the "cutting" of portals, and lets you control the contact BSP face splitting.Now what would happen if we assign func_detail to these boxes?Firstly, there would be less portals and less stuff for VIS to calculate. In this case, it's just one room, so the portal file would actually be 'empty':

mapname.prt
-----------------
1
0
6

Secondly, these boxes would not "cut" the floor into multiple faces as they did previously.I added another block there just so the portal file wouldn't be empty. Basically, func_detail simplifies the map's portals (these blue rectangles), but it should absolutely not be used on walls, ceilings etc.
It acts as a non-entity, but it'll still be treated as an entity by the compiler, so it won't block any leaks.

Here's another example. (oh the mapping gods, please forgive me as this sin is for the purpose of enlightenment)Each of these volumes defined by these blue boundaries can be considered a room. Basically, VIS thinks there are multiple rooms in there, while it's just some space around a pipe. Doesn't make much sense. So it should be func_detail. You can use func_detail on basically anything that causes unneeded complications in VIS calculations. Chairs, tables, lamps, maybe window frames, furniture, static vehicles, pipes, signs, poles etc. should all be definite func_detail candidates.

Yeah that makes sense. Only problem now is how I bring up these blue lines so I can see what's causing the issue.

Also these so called "sins"? I'm not entirely sure if I've already committed any of these but now I have a sinking feeling that I have.

Oh great, now ANOTHER problem has arisen. I deleted a bunch of stuff in the map for the "refurbishing" and now I can't compile the map because it tells me there's a leak. I try and follow the point file but it doesn't lead to anywhere. It just stops in the middle of the void. It's also curling around other stuff as well and I feel like that's trying to tell me something.

I have literally no idea why this is happening because the entire map is completely sealed off from the void.

"Only problem now is how I bring up these blue lines so I can see what's causing the issue."

You don't read anything I write, do you? :V

Here:

You can open your map's portal file to analyse what VIS has to calculate.
Where your .bsp file resides, there will also be a .prt file. Open it with a text editor, and you'll see something like this:

1681
3982
2
1
1
10
1
1
1
4
15
4 688 45 ( 400, 500, 600 ) etc.

You'll want to skip the first two lines, because those are the number of portals and visleaves, IIRC. Then delete whatever is between them and the coordinates (basically, delete the "garbage" numbers):

1681
3982
4 688 45 ( 400, 500, 600 ) etc.

The last line that I wrote won't actually look like the one in a .prt file, but you can get the idea.
This file is generated per each compile.
Then, you open the .prt file with the map editor: Map->Open Portal File.

BTW you might wanna check if you accidentally func_detail'ed a wall or a ceiling or something. This is where screenshots would come in handy. Does the line go through walls? If yes, then check for errors with Alt+P, there might be an invalid brush.

And don't worry about the sins, it's a joke. Mapping is no religion.

Sorry. I didn’t think to look back at your previous post because I don’t remember that being mentioned. By the way I am reading everything you write and I’m finding it very helpful. So, thanks. Again

I didn't mean it. No need to be sorry.

"I have literally no idea why this is happening because the entire map is completely sealed off from the void."

Do you have any entities outside of the map? All entities should be inside of the rooms, even things like lights, or info_ entities etc.

Have you checked for problems? (Alt-P)
Also what grid size are you working on? The bigger the better for map sealing brushes.

Double check that joke of your world sealing brushes aren't entities by accident.

Open a properties window and click each brush to check easily.

Oh right, one more thing: the point file's lines actually do end up in the void in the end. The thing is, you gotta track the line to see if it's going through a brush or not. The lines will "find their way" through any hole in the map, basically. Watch out for teeny tiny gaps.

Fixed. Turns out there was a locked door exposed to the void so I put wall behind it.

So for the sequence I tried using an aiscripted sequence instead but that appears to have done nothing. I realised I made a mistake by not changing the move to position but even after rectifying it, nothing happens. It could be trigger related but I've checked everything thoroughly.

Write this into the console:
developer 2
Restart the map and you'll see a real-time log of what is actually going on, what entities are being triggered etc., and then try to see what's the issue.

I have discovered that it's the scripted sentence entity that's causing the problem. The sequence works fine but the sentence for some reason refuses to work even when triggered. It works fine for the first guard in the map so I can't see a reason as to why it won't trigger. The only difference between the two is that one is stuck doing an idle animation whilst the other is free to move but I don't see how this would have an effect.

It's still not fixed. Some assistance would be greatly appreciated right now.

"The only difference between the two is that one is stuck doing an idle animation whilst the other is free to move but I don't see how this would have an effect."

Think of it as one guard being busy. What does your entity setup look like? What entities are triggering what, and what keyvalues/entity properties are being used?

Never mind crisis averted. I just checked the "fire once" and "interrupt speech" flags and it all works now.

Yay.