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

Created 12 years ago2011-12-26 08:32:24 UTC by Skals Skals

Posted 12 years ago2012-01-01 14:24:42 UTC Post #302333
Wait, so all these tests I've been doing for light in that box... wait what? ARE YOU KIDDING ME?
Skals SkalsLevel Designer
Posted 12 years ago2012-01-01 16:10:50 UTC Post #302334
Sorry, dude. :(
The Mad Carrot The Mad CarrotMad Carrot
Posted 12 years ago2012-01-01 16:59:48 UTC Post #302335
hahahaha
Stojke StojkeUnreal
Posted 12 years ago2012-01-01 17:29:11 UTC Post #302336
Lol'd :D
Excitement is a bitch.
Daubster DaubsterVault Dweller
Posted 12 years ago2012-01-01 22:25:07 UTC Post #302342
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. ='(
Captain Terror Captain Terrorwhen a man loves a woman
Posted 12 years ago2012-01-02 10:51:35 UTC Post #302346
I will ask Vluzacn.

Nvm my bad, the engine limit is still there.
Skals SkalsLevel Designer
Posted 12 years ago2012-01-02 17:53:41 UTC Post #302357
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?
The Mad Carrot The Mad CarrotMad Carrot
Posted 12 years ago2012-01-02 21:04:16 UTC Post #302361
stands back to make it appear like CT walked forwards.

Right then, chop chop :D
...and cool I want to see if that really is true. the better than HLfix part.
Skals SkalsLevel Designer
Posted 12 years ago2012-01-02 23:15:37 UTC Post #302368
Looking forward to your findings, Skals. :)
The Mad Carrot The Mad CarrotMad Carrot
Posted 12 years ago2012-01-03 03:57:13 UTC Post #302373
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.
Captain Terror Captain Terrorwhen a man loves a woman
Posted 12 years ago2012-01-03 16:50:58 UTC Post #302385
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.
The Mad Carrot The Mad CarrotMad Carrot
Posted 12 years ago2012-01-17 09:53:05 UTC Post #302792
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 SkalsLevel Designer
Posted 12 years ago2012-01-17 10:05:09 UTC Post #302793
skals, could you ask vlcuzan if he can make a floating point enabler for source? :P
Captain Terror Captain Terrorwhen a man loves a woman
Posted 12 years ago2012-01-17 12:19:14 UTC Post #302794
@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. :P

I'll get to it as soon as i can. :)
The Mad Carrot The Mad CarrotMad Carrot
Posted 12 years ago2012-01-17 12:36:21 UTC Post #302795
HOW DARE YOU! THIS IS A 1985 HONDA
Captain Terror Captain Terrorwhen a man loves a woman
Posted 12 years ago2012-01-17 16:12:12 UTC Post #302803
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.
Skals SkalsLevel Designer
Posted 12 years ago2012-01-17 16:24:08 UTC Post #302804
ha wicked! ty skals, i will try it and see what she does :P
Captain Terror Captain Terrorwhen a man loves a woman
Posted 12 years ago2012-02-13 16:54:36 UTC Post #303358
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.
The Mad Carrot The Mad CarrotMad Carrot
Posted 12 years ago2012-02-13 20:44:00 UTC Post #303359
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.
Posted 12 years ago2012-02-14 17:30:39 UTC Post #303378
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!
Skals SkalsLevel Designer
Posted 12 years ago2012-02-14 18:12:39 UTC Post #303381
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:
User posted image
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.
The Mad Carrot The Mad CarrotMad Carrot
Posted 12 years ago2012-02-14 18:44:43 UTC Post #303382
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.
Posted 12 years ago2012-02-14 18:55:36 UTC Post #303383
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.
The Mad Carrot The Mad CarrotMad Carrot
Posted 12 years ago2012-02-14 20:03:52 UTC Post #303385
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.
Posted 12 years ago2012-02-14 20:12:37 UTC Post #303386
You are correct, it says so in the fgd.
The Mad Carrot The Mad CarrotMad Carrot
Posted 12 years ago2012-02-27 21:12:57 UTC Post #303808
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.
Skals SkalsLevel Designer
Posted 11 years ago2012-04-09 16:28:15 UTC Post #305122
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]
Posted 11 years ago2012-04-09 16:48:35 UTC Post #305125
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.
Archie ArchieGoodbye Moonmen
Posted 11 years ago2012-04-09 17:38:40 UTC Post #305128
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
The Mad Carrot The Mad CarrotMad Carrot
Posted 11 years ago2012-04-09 20:31:58 UTC Post #305145
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.
Skals SkalsLevel Designer
Posted 11 years ago2012-04-09 20:37:01 UTC Post #305146
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:
User posted image
VHLT:
User posted image
Posted 11 years ago2012-04-09 21:11:36 UTC Post #305150
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.
Skals SkalsLevel Designer
Posted 11 years ago2012-04-30 05:21:26 UTC Post #305839
I'll just drop this here... :>
VHLT 2.6: http://forums.svencoop.com/showthread.php?t=38059&page=23
Skals SkalsLevel Designer
Posted 11 years ago2012-04-30 10:35:19 UTC Post #305844
Yeah, vluzacn and me finally made the spread angle for sun. Good luck using it!
Posted 11 years ago2012-04-30 14:00:28 UTC Post #305847
You worked with him on the code?
Stojke StojkeUnreal
Posted 11 years ago2012-04-30 14:13:01 UTC Post #305848
Coolz, didn't know you were on svencoop forum. Not sure how the spread angle works though.
Skals SkalsLevel Designer
Posted 11 years ago2012-04-30 14:31:14 UTC Post #305849
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...
Posted 11 years ago2012-07-04 20:55:49 UTC Post #307636
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:
User posted image
Striker StrikerI forgot to check the oil pressure
Posted 11 years ago2012-07-05 10:35:23 UTC Post #307641
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!
Captain Terror Captain Terrorwhen a man loves a woman
Posted 10 years ago2014-02-05 20:32:25 UTC Post #317767
Posted 10 years ago2014-02-05 23:53:48 UTC Post #317768
YOiNK!

Just in time for a new compo to be going around eh?
Rimrook RimrookSince 2003
Posted 10 years ago2014-02-06 06:54:17 UTC Post #317772
Updated again ? :o
Posted 10 years ago2014-02-06 11:31:56 UTC Post #317775
it looks like the source engine in early stages :) that lighting is getting better...
Posted 10 years ago2014-02-08 12:11:05 UTC Post #317825
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.
Archie ArchieGoodbye Moonmen
Posted 10 years ago2014-02-08 16:46:31 UTC Post #317826
So we can expect The Core to be released in a few hours, right...right guys?

...Guys?

:'(

And back to Source.
Moaby MoabyMk. III
Posted 10 years ago2014-02-08 16:48:54 UTC Post #317827
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% :-) ?
Posted 10 years ago2014-02-08 23:38:52 UTC Post #317834
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?
Rimrook RimrookSince 2003
Posted 10 years ago2014-02-09 03:34:31 UTC Post #317836
Accept Debit. :P
On topic: 64-bit compilation tools are good news.
Notewell NotewellGIASFELFEBREHBER
Posted 10 years ago2014-02-09 05:21:55 UTC Post #317837
Rimrook RimrookSince 2003
Posted 9 years ago2014-04-05 01:27:28 UTC Post #318594
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?
You must be logged in to post a response.