Forum posts

Posted 9 years ago2015-10-09 19:23:26 UTC
in Sledge (Hammer Alternative) Alpha Build Post #327234
I dunno if this has been brought up before, but texture lock seems to be hit-and-miss for me, especially when it comes to faces with smaller texture scales. I'm guessing this is probably due to rounding errors like I observed before when compiling.
Posted 9 years ago2015-06-07 06:43:35 UTC
in Sledge (Hammer Alternative) Alpha Build Post #325830
Yeah, he said it was something it might take him a while to get around to.
Posted 9 years ago2015-06-06 22:16:52 UTC
in Sledge (Hammer Alternative) Alpha Build Post #325828
As I demonstrated before (see my posts on this page: http://twhl.info/forums.php?thread=18410&page=25), the problem has to do with decimal rounding during compiles.

I thought it was because of some large-ish custom textures that had to be scaled down, and the rounding of the XY scale caused the offset to be out of whack. I just noticed it was also happening with stock textures that weren't scaled down as much.

My fix suggestion was to limit the texture fit and center buttons to two decimal precision since that's what Sledge outputs to the compiler, but I dunno if that ever got added to the bug database.
Posted 9 years ago2015-06-06 17:50:55 UTC
in Sledge (Hammer Alternative) Alpha Build Post #325826
So I mentioned the texture alignment bug I have earlier. Well, recently I was playing around with Sledge and I found out that some stock textures (halflife.wad) have the same problem! Just FYI.
Posted 9 years ago2014-11-30 05:25:35 UTC
in Sledge (Hammer Alternative) Alpha Build Post #322549
Later's better than never. Thanks for the work.
Posted 9 years ago2014-11-30 05:11:34 UTC
in Sledge (Hammer Alternative) Alpha Build Post #322547
That sounds like that should work. That 0.0005 difference in texture scale is so small that it alone couldn't account for the misalignment. It was how that rounding affected the texture shift. You'll notice how the fixed version pretty drastically shifted the yz position of the texture (+42, -23).

The texture just reverts to the broken version after pressing Fit, so if you're going to limit to 2 decimals, that would be a good place to insert that code. That and Center. All the other texture align tools are probably okay since they aren't dealing with any kind of fractions.

Also happy to help, I do this stuff for work sometimes anyways.
Posted 9 years ago2014-11-30 04:00:04 UTC
in Sledge (Hammer Alternative) Alpha Build Post #322545
From Hammer:
( 1795 3044 296 ) ( 1795 3044 320 ) ( 1795 2996 320 ) SIGN_PEAK10ACC6 [ 0 -1 0 106.667 ] [ 0 0 -1 42.6667 ] 0 0.1875 0.1875
From Sledge:
( 1795.000 3044.000 296.000 ) ( 1795.000 3044.000 320.000 ) ( 1795.000 2996.000 320.000 ) sign_peak10acc6 [ 0.000 -1.000 0.000 106.667 ] [ 0.000 0.000 -1.000 42.667 ] 0.000 0.188 0.188
Huh, so it looks like there was texture scale rounding error, from 0.1875 to 0.188. That 4-digit precision is from the Fit function. Of course, both Hammer and Sledge show that further rounded to 0.19, which is why I couldn't tell there was a problem.

Upon fixing that and recompiling in Sledge, I got the following values, and the texture was (relatively) aligned.
( 1795.000 3044.000 296.000 ) ( 1795.000 3044.000 320.000 ) ( 1795.000 2996.000 320.000 ) sign_peak10acc6 [ 0.000 -1.000 0.000 149.000 ] [ 0.000 0.000 -1.000 20.000 ] 0.000 0.190 0.190
So the problem here looks like bad handling of single-precision float to decimal integer conversion. I dunno if you can get into Hammer's code, but there's obviously something different with how it's handling that conversion.
Posted 9 years ago2014-11-30 02:45:02 UTC
in Sledge (Hammer Alternative) Alpha Build Post #322542
I couldn't replicate the problem in a bare bones map. But, I looked at the MAP exports from Sledge and Hammer and sure enough, the textures were misaligned in the Sledge MAP but not in the Hammer one.

It's a pretty large map area. I could strip it down a bit (consolidate some custom stuff) and upload that somewhere if it'd help.
Posted 9 years ago2014-11-30 01:48:40 UTC
in Sledge (Hammer Alternative) Alpha Build Post #322540
It's aligned in Hammer, and compiling it with Hammer (using ZHLT and VHLT) looked normal in-game. I also tried a different map in Sledge and the misalignment happened for some stock textures too (from halflife.wad).

The nudge trick unfortunately didn't work. I even tried flipping its alignment, but it was still offset when using Sledge.

EDIT:

I solved the game launch problem, and it showed me a bug. Turns out the game launch only happens when using a temp directory to compile, rather than the map directory, which I had been trying to use. When using the map directory to compile, it also copied an older BSP file into \valve\maps.
Posted 9 years ago2014-11-30 00:09:30 UTC
in Sledge (Hammer Alternative) Alpha Build Post #322537
I'm having the same texture misalignment problem that was brought up earlier. It appears normal in Sledge and offset in-game - see below. Note I didn't run rad for that compile, but it happens no matter what. It's only happening to a certain few custom textures - that picture has two, and only one didn't work. It doesn't have to do with the left one being tied to the func_door_rotating, since the misalignment is happening for world brushes too. I checked the scales, and they're not overly precise (two decimals). I also tried both ZHLT 3.4 and VHLT v33 to compile the map. I'm not sure what to do with it. Anyone have any ideas?
User posted image
Oh, and i'm also experiencing a bug where the compiler doesn't always run the game when done (or ask to), despite having set it in the options.
Posted 16 years ago2007-11-26 23:59:50 UTC
in Elevator help Post #239254
Posted 16 years ago2007-11-26 23:45:49 UTC
in Elevator help Post #239250
I'm working on a SOHL map that involves an elevator that has inner doors and outer doors, i.e. doors attached to the elevator and doors next to the path_corners. The problem is that I can't figure out how to make them work :(

Here are the entities:

The two path_corners are 'up' and 'down', with "next stop target" set as 'down' and 'up', respectively

The main func_train is called 'elev', and has "first stop target" set at 'up'

There are two func_doors, called 'eledoors', that have "move with" set to 'elev'

There is also a func_button, called 'eleb', that havs "move with" set to 'elev'

At the upper landing, there is a button 'upbtn' and two doors 'updoors'
At the lower landing, there is a button 'downbtn' and two doors 'downdoors'

I assume that people know how elevators work (press the button, the elevator comes, doors open, you get in, press button, elevator descends, etc), but I'm having trouble making it work in Hammer. Can anyone help? And I will post the .rmf if people want/need it...

Thanks!
Posted 17 years ago2007-09-08 20:55:37 UTC
in The Free Texture Thread! Post #233716
This is a really good resource for safety signs.
Posted 17 years ago2007-09-08 20:48:42 UTC
in A little error Post #233715
Click here to download the map...
Posted 17 years ago2007-09-08 20:40:29 UTC
in A little error Post #233714
Ok. My map (pointless, btw) has a glitch. It compiles normally and runs fine, until you try to break the glass at the OVERRIDE switch near the SECURE ACCESS door (see the file for position etc). At this point, HL crashes. Is there a way to fix this?

Oh and for the record there are a couple of custom textures i'm using along with a custom sound. Also, because i'm lazy, i've borrowed some rooms from the sp game.