Vluzacn's Half-Life Tools v34 Created 12 years ago2011-12-26 08:32:24 UTC by Skals

Wait, so all these tests I've been doing for light in that box... wait what? ARE YOU KIDDING ME?

Sorry, dude.

hahahaha

Lol'd
Excitement is a bitch.

Skals: ya, that sucks, but how could you possibly think you were calling command paramaters to the tools through there?!

oh also btw, i tired rescaling those textures to 1024x512, and they still crahsed hl. ='(

I will ask Vluzacn.

Nvm my bad, the engine limit is still there.

Had anyone tried this tool:
http://forums.svencoop.com/showthread.php?t=39037

According to vluzacn, it's like HLFix, except better.
Captain Terror, you seem to be the perfect candidate to try it. If this tool does a better job than HLFix, i'll add it support for it to the Compilator, next to HLfix.

Oh wait, it's not an actual compile tool like csg, bsp vis or rad, it's a standalone executable that patches your Hammer exe.

Do you still want to give it a try, CT, or anyone else?

stands back to make it appear like CT walked forwards.

Right then, chop chop
...and cool I want to see if that really is true. the better than HLfix part.

Looking forward to your findings, Skals.

Idk, hlfix works virtually perfect for me along with compilator, so i really feel i shouldn't try to f with perfection, e.g. i can currently build any sturcture i can think of in hammer, and hlfix will make sure it looks that way in the game, every time.

What i really wish tho is they could make hlfix for source. that would really be something since as it is now, i have more freedom of brushwork in goldsource, which doesn't seem correct.

I will download the utility and play with it sometime tho, and i have to say, it's a exciting to see peeps still developing awesome stuff like this for Goldsource mapping.

Yes, Source Hammer is much worse when it comes to keeping floating points of vertices on the exact same spot.

If you map a complex object using VM and scaling, then work on a different object in the same map, then come back to your initial complex object you'll notice cracks and seams in its structure. If you zoom all the way in, you'll notice that the vertices are slightly spread out.

And the reason why i hope that vluzacn's HammerFloatingPointEnabler tool is better than HLfix is because we can be sure it'll work fine alongside VHLT. I know that HLfix has a couple of issues with the latest SHLT (3.9) and that HLfix is no longer being developed, so im hoping that vluzacn's HammerFloatingPointEnabler will be the perect replacement for HLfix.

I tested le HammerFloatingPointEnabler, It seems to work just as good as Hlfix if not better, because I received less errors now than I did with hlfix (I was receiving some errors for a few objects that were rotated, I had about 6, and then when I recompiled with HFPE, I had only 2).

Also, everything appears to be just find in-game. Also this tool is easier to use as its a simple patch for hammer, you don't need to do anything besides export the .rmf as a .map file and you can compile it right there.

TMA, how are you progressing with compilator? Could I have a version that lets me use custom flags please?

skals, could you ask vlcuzan if he can make a floating point enabler for source?

@CT: I doubt that's going to work as the Source SDK has the habit of replacing files at startup if it detects a difference (filesize, filecontent, etc). You'll end up with an unmodified Hammer.exe again.

@Skals: Haven't started yet, CT keeps "bothering" me with bug reports and additional features to add to my HLLP.

I'll get to it as soon as i can.

HOW DARE YOU! THIS IS A 1985 HONDA

Uh yeah I don't really want to put this conversation here, but you wanted this information, I asked him if he is planning to make something like this tool but for source, and this is what he replied:

le me: "Hello Vluzacn, I was wondering if in the future you are planning to make a tool like the Export .map with floating point coordinates but for Source? It would be very useful. Thank you."

le Vluzacn: "Did you mean when saving vmf? This could be easy. Open the hammer.dll with a hex editor, and replace any '(%g %g %g) (%g %g %g) (%g %g %g)' with '(%f %f %f) (%f %f %f) (%f %f %f)'."

I'm no coder so I'm not sure what he meant, but apparently that's supposed to do something.

ha wicked! ty skals, i will try it and see what she does

I'm having trouble figuring out the difference between info_texlights and light_surface. They both turn a texture on a face into a light emitting texture, right?

It's a shame that proper documentation of these new entities and parameters of VHLT are lacking.

info_texlights sets values globally for all surfaces with specified texture, while light_surface allows you to have different values for individual surfaces even with the same texture.

Exactly, although I did have some problems with the entity, it did not seem to function properly in cs1.6; the light was produced but the targeted object disappeared!

Well it didn't work for me at first, i had a bunch of small light fixtures in a room, and added one light_surface. The light_surface made all the light fixtures in the room to emit light. To make only one of them emit light, i had to use one of the filters. The 'Filter entity name' did it.

Here's what it looks like:The light on the left is a normal texturelight. It gets its color and brightness from the light.rad file:
+0~GENERIC86R 128 0 0 60000

The light on the right emits light from the light_surface entity. Brightness is the same as the brightness value of the lights file (60000)

Now what i like the most about the light_surface entity is that you can toggle the light on and off or select a predefined appearance or custom appearance without making the actual light it emits look like its light coming from an ordinary pointlight, it MAINTAINS the texturelight look. Awesome.

One the difference:

Maybe light_surface calculates the average color of the texture it's being emitted from to define light color? The texture isn't very red, it's quite pink on average. I also heard that light_surface uses smaller density of the light sources than old texture lights. Or maybe it's just a bug?

"...it MAINTAINS the texturelight look. Awesome."

You could always get the same result with ordinary texture lights, you just needed to use -coring 0, but few knew that. But I believe vluzacn already fixed the "pointlight" bug thing in dynamic lights.

You should inform vluzacn about this.

Yes the light_surface gets the color of the light by looking at the average color of the texture.

Are you saying it shouldn't emit pink-ish light? Unless that's a bug and it really should emit red light like the normal texturelight on the left.

No, I'm not saying this. If it really uses average color then it should emit pinkish light. I just wanted to figure out why it differs, now it's clear.

You are correct, it says so in the fgd.

right, so, more info!

info_sunlight is an entity used to set the default colour of the player models. This means rather than turning completely black (Which is a problem in some maps) they would turn to that colour, so if you set it to the colour of the light_environment, you can ensure that your map never gets the black players error.

more on func_detail:
by default, it blocks light and casts shadow, and that cannot be changed. You can't set transparency values for it however, so func_wall will still be the entity used for transparent objects.
func_detail can be set to not cut other func_details. To do so, set "detail level" to 2.

hi
my map is totally full bright after compiling with VHLT, in order to make the stuff simple i use The Compilator i just changed ZHLT Directory to VHLT directory "E:Half-Life mappingtoolszhlt vluzacn25tools"

+ compile log:

[quote]
hlcsg v3.4 VL25 (Oct 23 2011)
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: hlcsg.exe -wadinclude ninjashock.wad -chart -estimate -texdata 8192 "C:Documents and SettingsDamianMy Documentshlmappingsyndicate.map"
Arguments: -wadinclude ninjashock.wad -chart -estimate -texdata 8192 "C:Documents and SettingsDamianMy Documentshlmappingsyndicate.map" -low -wadautodetect
Entering C:Documents and SettingsDamianMy Documentshlmappingsyndicate.map

Current hlcsg Settings
Name | Setting | Default
--------------------|-----------|------------------------
threads [ 2 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
reset logfile [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ on ] [ off ]
estimate [ on ] [ off ]
max texture memory [ 8388608 ] [ 33554432 ]
max lighting memory [ 33554432 ] [ 33554432 ]
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 ]
wadcfgfile [ 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]
[ninjashock.wad]

CreateBrush:
(0.06 seconds)
CSGBrush:
(0.23 seconds)

Using Wadfile: programyvalve hammer editor!txhalflife1halflife.wad

• Contains 23 used textures, 85.19 percent of map (3116 textures in wad)

Including Wadfile: programyvalve hammer editor!txninjashock.wad

• Contains 4 used textures, 14.81 percent of map (4 textures in wad)

"wad" is "halflife.wad;"

added 7 additional animating textures.
Texture usage is at 0.51 mb (of 8.00 mb MAX)

Object names Objects/Maxobjs Memory / Maxmem Fullness
---------- ------------- ------------- ------
models 0/512 0/32768 ( 0.0%)
planes 2070/32768 41400/655360 ( 6.3%)
vertexes 0/65535 0/786420 ( 0.0%)
nodes 0/32767 0/786408 ( 0.0%)
texinfos 459/32767 18360/1310680 ( 1.4%)
faces 0/65535 0/1310700 ( 0.0%)
clipnodes 0/32767 0/262136 ( 0.0%)
leaves 0/32760 0/917280 ( 0.0%)

• visleafs 0/8192 0/0 ( 0.0%)

marksurfaces 0/65535 0/131070 ( 0.0%)
surfedges 0/512000 0/2048000 ( 0.0%)
edges 0/256000 0/1024000 ( 0.0%)
texdata [variable] 118828/8388608 ( 1.4%)
lightdata [variable] 0/33554432 ( 0.0%)
visdata [variable] 0/8388608 ( 0.0%)
entdata [variable] 9319/524288 ( 1.8%)

• AllocBlock 0/64 0/0 ( 0.0%)

34 textures referenced

Total BSP file data space used: 187907 bytes

0.36 seconds elapsed

--- END hlcsg ---

hlbsp v3.4 VL25 (Oct 23 2011)
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: hlbsp.exe -chart -estimate -texdata 8192 "C:Documents and SettingsDamianMy Documentshlmappingsyndicate.map"
Arguments: -chart -estimate -texdata 8192 "C:Documents and SettingsDamianMy Documentshlmappingsyndicate.map" -low -chart

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

noclip [ off ] [ off ]
nofill [ off ] [ off ]
noinsidefill [ off ] [ off ]
noopt [ off ] [ off ]
null tex. stripping [ on ] [ on ]
notjunc [ 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...569 (0.22 seconds)
BSP generation successful, writing portal file 'C:Documents and SettingsDamianMy Documentshlmappingsyndicate.prt'
SolidBSP [hull 1] 494 (0.30 seconds)
SolidBSP [hull 2] 398 (0.20 seconds)
SolidBSP [hull 3] 488 (0.33 seconds)
Reduced 459 texinfos to 345
Reduced 34 texdatas to 32 (118828 bytes to 118740)
Reduced 2070 planes to 869

Object names Objects/Maxobjs Memory / Maxmem Fullness
---------- ------------- ------------- ------
models 18/512 1152/32768 ( 3.5%)
planes 869/32768 17380/655360 ( 2.7%)
vertexes 1801/65535 21612/786420 ( 2.7%)
nodes 661/32767 15864/786408 ( 2.0%)
texinfos 345/32767 13800/1310680 ( 1.1%)
faces 1276/65535 25520/1310700 ( 1.9%)
clipnodes 1826/32767 14608/262136 ( 5.6%)
leaves 445/32760 12460/917280 ( 1.4%)

• visleafs 297/8192 0/0 ( 3.6%)

marksurfaces 1757/65535 3514/131070 ( 2.7%)
surfedges 6124/512000 24496/2048000 ( 1.2%)
edges 3063/256000 12252/1024000 ( 1.2%)
texdata [variable] 118740/8388608 ( 1.4%)
lightdata [variable] 0/33554432 ( 0.0%)
visdata [variable] 0/8388608 ( 0.0%)
entdata [variable] 9319/524288 ( 1.8%)

• AllocBlock 3/64 0/0 ( 4.7%)

32 textures referenced

Total BSP file data space used: 290717 bytes

1.25 seconds elapsed

--- END hlbsp ---

hlvis v3.4 VL25 (Oct 23 2011)
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: hlvis.exe -full -chart -estimate -texdata 8192 "C:Documents and SettingsDamianMy Documentshlmappingsyndicate.map"
Arguments: -full -chart -estimate -texdata 8192 "C:Documents and SettingsDamianMy Documentshlmappingsyndicate.map" -low
297 portalleafs
1025 numportals

= Current hlvis Settings =
Name | Setting | Default
------------------|-----------|------------------------
threads [ 2 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ on ] [ off ]
estimate [ on ] [ off ]
max texture memory [ 8388608 ] [ 33554432 ]
max vis distance [ 0 ] [ 0 ]
priority [ Low ] [ Normal ]

fast vis [ off ] [ off ]
full vis [ on ] [ off ]

BasePortalVis:
(0.13 seconds)
LeafThread:
(26.80 seconds)
average leafs visible: 262
g_visdatasize:11280 compressed from 11286

Object names Objects/Maxobjs Memory / Maxmem Fullness
---------- ------------- ------------- ------
models 18/512 1152/32768 ( 3.5%)
planes 869/32768 17380/655360 ( 2.7%)
vertexes 1801/65535 21612/786420 ( 2.7%)
nodes 661/32767 15864/786408 ( 2.0%)
texinfos 345/32767 13800/1310680 ( 1.1%)
faces 1276/65535 25520/1310700 ( 1.9%)
clipnodes 1826/32767 14608/262136 ( 5.6%)
leaves 445/32760 12460/917280 ( 1.4%)

• visleafs 297/8192 0/0 ( 3.6%)

marksurfaces 1757/65535 3514/131070 ( 2.7%)
surfedges 6124/512000 24496/2048000 ( 1.2%)
edges 3063/256000 12252/1024000 ( 1.2%)
texdata [variable] 118740/8388608 ( 1.4%)
lightdata [variable] 0/33554432 ( 0.0%)
visdata [variable] 11280/8388608 ( 0.1%)
entdata [variable] 9319/524288 ( 1.8%)

• AllocBlock 3/64 0/0 ( 4.7%)

32 textures referenced

Total BSP file data space used: 301997 bytes

26.95 seconds elapsed

--- END hlvis ---

hlrad v3.4 VL25 (Oct 23 2011)
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: hlrad.exe -extra -chart -estimate -texdata 8192 "C:Documents and SettingsDamianMy Documentshlmappingsyndicate.map"
Arguments: -extra -chart -estimate -texdata 8192 "C:Documents and SettingsDamianMy Documentshlmappingsyndicate.map" -waddir C:Half-Lifevalve -waddir C:Half-Lifevalve_schinese -waddir C:Half-Lifecstrike -waddir C:Half-Lifecstrike_schinese -low

= Current hlrad Settings =
Name | Setting | Default
-------------------|---------------------|------------------------
threads [ 2 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ on ] [ off ]
estimate [ on ] [ off ]
max texture memory [ 8388608 ] [ 33554432 ]
max lighting memory [ 33554432 ] [ 33554432 ]
priority [ Low ] [ Normal ]

vismatrix algorithm [ Sparse ] [ Sparse ]
oversampling (-extra)[ on ] [ off ]
bounces [ 8 ] [ 8 ]
ambient light [ 0.000 0.000 0.000 ] [ 0.000 0.000 0.000 ]
circus mode [ off ] [ off ]

smoothing threshold [ 50.000 ] [ 50.000 ]
smoothing threshold 2[ no change ] [ no change ]
direct threshold [ 10.000 ] [ 10.000 ]
direct light scale [ 1.000 ] [ 1.000 ]
coring threshold [ 0.010 ] [ 0.010 ]
patch interpolation [ on ] [ on ]

texscale [ on ] [ on ]
patch subdividing [ on ] [ on ]
chop value [ 64.000 ] [ 64.000 ]
texchop value [ 32.000 ] [ 32.000 ]

global fade [ 1.000 ] [ 1.000 ]
global light scale [ 2.000 2.000 2.000 ] [ 2.000 2.000 2.000 ]
global gamma [ 0.550 0.550 0.550 ] [ 0.550 0.550 0.550 ]
global light scale [ 2.000 ] [ 2.000 ]
global sky diffusion [ 1.000 ] [ 1.000 ]

opaque entities [ on ] [ on ]
sky lighting fix [ on ] [ on ]
incremental [ off ] [ off ]
dump [ off ] [ off ]

colour jitter [ 0.0 0.0 0.0 ] [ 0.0 0.0 0.0 ]
monochromatic jitter [ 0.0 0.0 0.0 ] [ 0.0 0.0 0.0 ]

custom shadows with bounce light

[               off ] [               off ]

rgb transfers [ off ] [ off ]
minimum final light [ 0 ] [ 0 ]
size of transfer [ 1 (16bit) ] [ 1 (16bit) ]
size of rgbtransfer [ 2 (32bit) ] [ 2 (32bit) ]
soft sky [ on ] [ on ]
translucent depth [ 2.000 ] [ 2.000 ]
block opaque [ on ] [ on ]
ignore textures [ off ] [ off ]
reflectivity gamma [ 2.200 ] [ 2.200 ]
reflectivity scale [ 1.000 ] [ 1.000 ]

Load Textures:
Opening wad files from directories:
C:Half-Lifevalve
C:Half-Lifevalve_schinese
C:Half-Lifecstrike
C:Half-Lifecstrike_schinese
Error: Could not locate wad file halflife.wad
Error: Could not locate WAD file
Description: The compile tools could not locate a wad file that the map was referencing.
Howto Fix: Configure game directory pathes for hlrad in file '<tool path>settings.txt', and make sure this wad file either has been included into bsp by hlcsg or exists in one of the game directories.

--- END hlrad ---

[/quote]

RAD isn't actually running.

Opening wad files from directories:
C:Half-Lifevalve
C:Half-Lifevalve_schinese
C:Half-Lifecstrike
C:Half-Lifecstrike_schinese
Error: Could not locate wad file halflife.wad
Error: Could not locate WAD file
Description: The compile tools could not locate a wad file that the map was referencing.

This is stopping it. I had similar troubles with the compilator that Muzz was never able to fix. Try compiling out of Hammer and see if it works.

I may have figured it out. Try this:

Add -waddir to RAD and specify the path to your wad directory where halflife.wad is located in.

For example:

-waddir ...Steamsteamappsusernamehalf-lifevalve

God, can you guys not see? It says it right there at the bottom

Howto Fix: Configure game directory pathes for hlrad in file '<tool path>settings.txt', and make sure this wad file either has been included into bsp by hlcsg or exists in one of the game directories.

He obviously didn't configure his setting.txt to have the locations of all wad files used... and you guys are having such a hard time lol. It says it in the readme when you dl vhlt, that you have to specify all paths to ur .wad files in the settings.txt, very simple.
So all you have to do is - put the lime in the coconut.
But seriously, open your flippin vhlt folder, open the settings.txt, and put the directories in there replacing his default ones.

yea i was clicking around and changed a little settings.txt ^^ its fine right now ^^ i have just noticed a huge difference in how my map looks like and i think that VHLT is cool ^^

btw. on the pictures u can see my new map project ^^

ZHLT:VHLT:

That is quite a big difference, new one looks a lot more atmospheric, although I'm not sure if it's a dark look you were going for, if not just increase the brightness of those lights.

I'll just drop this here... :>
VHLT 2.6: http://forums.svencoop.com/showthread.php?t=38059&page=23

Yeah, vluzacn and me finally made the spread angle for sun. Good luck using it!

You worked with him on the code?

Coolz, didn't know you were on svencoop forum. Not sure how the spread angle works though.

The bigger the light source, the blurrier the shadows. On a clear day shadows can be razor sharp because sun only covers about a degree on the sky. But on a cloudy day there can be no shadows at all because the whole sky becomes one huge light source illuminated by the sun...

Just switched from SHLT to VHLT at archie's advice. The compile time doubled, from 1 minute to 2 minutes.

But holy schnitzel! The lighting is just sexy:

Whoa that looks lovely Striker =)

Ninja: Same for you(i missed those when you originally posted), the vhlt screen looks much better. Cool map btw!

YOiNK!

Just in time for a new compo to be going around eh?

Updated again ?

it looks like the source engine in early stages that lighting is getting better...

Oh man, that 64bit & RAM usage increase to hlrad is the best news ever. My biggest maps in The Core have gone from ~30 minute RAD compiles to ~4 minutes.

So we can expect The Core to be released in a few hours, right...right guys?

...Guys?

:'(

And back to Source.

if u make The Core more fun than the Residual Life mod i will donate some cash

so basically the compilation time has been shortened about 80% ?

I haven't tried the new tools yet, though they sound impressive.

I'm curious what I'd have to do with Super Matt Jordan to get you to throw cash at me?

Accept Debit.
On topic: 64-bit compilation tools are good news.

Maybe I'm just missing something:

** Executing...
** Command: D:GamesSteamSteamAppscommonHalf-Life SDKMap_Toolshlcsg.exe
** Parameters: "D:GamesSteamSteamAppscommonHalf-LifevalvemapsTest_Map"

Unknown option "D:GamesSteamSteamAppscommonHalf-LifevalvemapsTest_Map"

x4 for each compiler.

Any ideas why its not reading? Is it dropping the file extention? Is it not reading it because its on drive D? Because its in the steam folder?