Forum posts

This is a double post...

This is a double post...

Nit picky nowadays?

Cake - I Will Survive

When you all figure it out, create a new post and let us know...

Good luck!

AND DONT DOUBLE POST!

Technically, this isn't a double post. It's a continuation of thought... maybe it rides on a second, underlying thought brought up by someone else that is not exactly on the topic of the post.

You'll have to live with it....

No... the highest resource used is 71%.

I took your train of thought with the wads and re-associated them in the batch compiler. It is running the RAD right now, so it found the textures. In the batch compiler, you navigate to the wads, like you do in Hammer, so I don't know how they "broke" or why it is random.

It has compiled before, several times... without error. But I can compile it fine, look at it, then re-compile it, and BAM! - "Error!" I'm just looking for consistancy.

I think you would like the Batch Compiler, Bob, I really do. It isn't any easier than using the expert compile function in Hammer, but it is easier to be more precise with what you want to do. I set up a leakcheck compile preset, a fast vis/rad compile preset, and a final compile preset that I can easily select, depending on which stage of the game I'm at. Spend an hour and give it a try.

Nobody mentioned -wadinclude.

(What a fricken soap opera this map has become!)

Ahem... yes, penguinboy. It's hard to show the inflection I was intending in that sentence... Might be better like this:

"Not to be rude, but (yes) you ARE clueless to the batch compiler..."

As for the problem, I compiled it again and that error didn't show up. I didn't change a thing. The error, with the textures working, is "Exceeded Max Patches".

I have a few things to try to hopefully get the GOD DAMN MAP to compile.

Not to be rude, but you are clueless to the batch compiler... The wad paths have to be spelled out before you can compile in the same way that you set Hammer up to find whichever wads you use.

This version of Nem's Batch Compiler doesn't include a tab for HLFix. I am assuming his latest version fixed whatever that problem was.

I've been to the "dark side" and the batch compiler is much faster. Really, it's just a wysiwig for the switches you use in in your expert compile. You see all the choices available with decent explanations onto which switches do what.

!FLUID_YELLOW is a custom texture... yes, I have used it before; yes, it is not the problem.

Once you set up Nem's, it automatically adds the wads to the bsp... it acutally only adds the textures from the wads that you've acutally used, so if you set up Hammer with A.wad, B.wad, and C.wad, but never used any textures from C.wad, it won't add them.

Yes, I have zhlt installed, and and the batch compiler set up. It shows up twice on my compile record, but always has and hasn't been a problem in the past.

Warning: ::FindTexture() texture LAB1_COMP3A not found!
Warning: ::FindTexture() texture +2~LAB1_CMP2 not found!
Warning: ::FindTexture() texture LAB1_COMP2 not found!
Warning: ::LoadLump() texture !C2A52 not found!
Warning: ::LoadLump() texture !FLUID2B not found!
Warning: ::LoadLump() texture !FLUID_YELLOW not found!

This is just a sample of what is in the log. There's a PILE of textures "not found. Looks like ALL of them are missing! When I run the map, I get another (yet again) BAD SURFACE EXTENTS error... It compiles all the way through, though, so WTF?

I do not use a wad.cfg file and I have only 6 wad files. I am using Nem's Batch Compiler. This map has worked before and I adjusted a few things, added some health and weapons just to one small area, and recompiled. And it seemed to compile fine. But running the map... no.

Any ideas what causes that???

I noticed that early on in my struggles and replaced all the NULL texture with something else.

Sometimes all the textures are missing, like the other example. If I recompile, then Hammer finds all the textures again. I have no idea about that one...

all sections compile... one section can't load the transfer files (extention .inc), but I think I can keep it going for now. Captian P, I will probably forward it to you for lighting suggestions in the near future.

I think I found the problem. I had the compiler set to subdivide at 256. The default is 240. According to Nem, setting the subdivide too high can cause bad surface extents. My first cordon section compiled and ran through STEAM. 256 seemed a better "computer" number, but I'm guessing, now, it's not.

Thanks for the offer, Captain P, and I understand the logic behind your suggestion. In fact, I force my apprentices to do just that every day. I just make sure they've exhausted EVERY possible option they can think of before I look at it. So when I run out of options, I will send it your way.

I have problems on every map I make. Not your everyday "texture perpendicular to axis" problems. They piss me off so much I set it aside for a while...a few months. Come back, start another one... same stuff. So this map is a compilation of several of those maps tied together. Not for the faint of heart, I know.

Every one of the sections in this map have worked flawlessly at one time.

Compiling is not my strong suit.

Thanks for creating the tool, but I've hit my "fuck this" stage for now.

Oh, yeah... Map_Rev1_Hallway, Map_Rev1_Hallway2, etc.

RowleyBob:

I've been through that list of odd and peculiar errors before... I have 6 .wads. The sky thing might be a cause,though. I was putting cl_skyname and not sky_skyname. I've never had a problem with that before, though I use mostly default skies.

This map is my own creation (it attends the school for "special" maps, but I love it anyways), so no decompiling.

edit: I've found sometimes that deleting an object that's giving you trouble, then compiling, then hitting Ctrl+Z--so you never close down Hammer obviously--and recompiling sometimes gets rid of various malformed, corrupted stuff.

That I don't understand... You delete the object, compile, then in Hammer, "undo" the deletion, then recompile? I don't think I will do that one, since the error is with many little objects all over the place.

Captain P:

I'm realizing that the textures in the entities still cause a problem. I thought that they didn't.

So I'm using your tool with a cordon strategy. It gives me quite a head start on things. I'm wondering if this is what I'm reading with it:

Entity #55
:: Brush #4
:: Scale too low at line: 4759 (0.09375)
:: Scale too low at line: 4760 (0.09375)
:: Scale too low at line: 4761 (0.09375)

Is that brush #4 of Entity #55 or is that two separate items; Brush #4 and Entity #55?

And your tool will show a brush with a texture being 10.5, but I've changed it to 2 in Hammer, though it didn't need changing, and it still shows up as 10.5. I've saved it and also saved it with different name. Any ideas why this might happen? If I raise my threshold for maximum texture size to 11, my errors drop from 289 down to 27.

Also, a question not about the tool, but my problem:

In some areas, I find no texture violations, but still end up with bad surface extents. Other than textures, what might be the cause of that?

Perhaps a tool (or an addition to this tool) that also fixes the 'violating' scales to the minimum/maximum you set? Would save you some work... smile -

Just because I like things to be complete, I think it'd be a good idea to be able to raise the tiny scales to a minimum and lower the huge scales to a maximum... Now if there were a way to identify the brushes associated with entities and either set them aside or "forget" them so that only world brushes were affected by the resizing of the textures,I would be even more inclined to use it. That way the lights and other little what-not wouldn't be changed.

But, like you say, it doesn't help me with my current problem. I think I can only find this by ripping the map into sections and recompiling each section... Divide and conquere...

BJ,

With this paticular texture, I have not searched it out and changed it, but I have with several before... not only the texture, but the entire family those textures were in.

Elon,

The only way to center that view that I know of is to pick through the map using your cursor in the x/y and y/z or x/z views. It's a big pain to do, especially with a detailed map. And I believe the 17x9 example is the size of the brush face, though if you do the math on the tri-ordinates, there isn't one that size.

Captian P! OUTSTANDING!

This will help me out alot. I could think of a whole range of problems I have that could use little programs like this, if you're looking for work. I will look for Notepad++.

Using your old version, I have many faces less than .1. I haven't had time to try your new version, nor have I had time to attempt a blanket fix yet. I had hoped changing the textures to 1x1 would have solved this problem, but not yet. I will be back with an entire log file, since RAD didn't spark any response.

And I didn't notice a second page... or I'd have added this to my above post!

Thanks, All!

And I'm just noticing the little edit button... that's new since I've been away!

Ok... I selected EVERYTHING and changed the texture size to 1x1. I checked a bunch of textures and they had changed. I saved, exported to .map, and compiled it... with a bad surface extents error... so I have copied the log for the RAD section for everyone to comment on. Please tell me if I have something set weird.

[quote]= Current hlrad Settings =
Name | Setting | Default
-------------------|---------------------|------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 1 ] [ 0 ]
chart [ off ] [ off ]
estimate [ on ] [ off ]
max texture memory [ 8388608 ] [ 4194304 ]
max lighting memory [ 6291456 ] [ 6291456 ]
priority [ High ] [ Normal ]

vismatrix algorithm [ Original ] [ Original ]
oversampling (-extra)[ on ] [ off ]
bounces [ 3 ] [ 1 ]
bounce dynamic light [ on ] [ on ]
ambient light [ 0.000 0.000 0.000 ] [ 0.000 0.000 0.000 ]
maximum light [ 255.000 ] [ 256.000 ]
circus mode [ off ] [ off ]

smoothing threshold [ 50.000 ] [ 50.000 ]
direct threshold [ 25.000 ] [ 25.000 ]
direct light scale [ 1.000 ] [ 2.000 ]
coring threshold [ 1.000 ] [ 1.000 ]
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 falloff [ 2 ] [ 2 ]
global light scale [ 1.000 1.000 1.000 ] [ 1.000 1.000 1.000 ]
global gamma [ 0.500 0.500 0.500 ] [ 0.500 0.500 0.500 ]
global light scale [ 1.000 ] [ 1.000 ]
global sky diffusion [ 1.000 ] [ 1.000 ]

opaque entities [ on ] [ on ]
sky lighting fix [ on ] [ on ]
incremental [ on ] [ 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 ]
softlight hack [ 0.0 0.0 0.0 0.0 ] [ 0.0 0.0 0.0 0.0 ]
diffuse hack [ on ] [ on ]
spotlight points [ on ] [ on ]

custom shadows with bounce light

[               off ] [               off ]

rgb transfers [ off ] [ off ]

[Reading texlights from 'D:Program Fileszhlt33lights.rad']
[59 texlights parsed from 'D:Program Fileszhlt33lights.rad']

11364 faces
Create Patches : 53458 base patches
98 opaque faces
356082 square feet [51275944.00 square inches]
4985 direct lights

BuildFacelights:
Error:
for Face 39 (texture c1a4_silo3) at
(1008.000 1281.000 -1392.000) (1008.000 1434.000 -1392.000) (1008.000 1530.000 -1392.000) (1008.000 1530.000 -1264.000) (1008.000 1510.000 -1264.000) (1008.000 1281.000 -1264.000)
Error: Bad surface extents (17 x 9)
Check the file ZHLTProblems.html for a detailed explanation of this problem[/quote]

Ok... it works very well... too well, since I didn't want to see the answers.

Now the questions:

I am showing something like 1200 discrepancies. I set it for 0.2 and 10. Nothing is larger than 11. I'm guessing that the decimal following the error text is the actual size of the texture?

Is 0.2 a good number to search for? Is that a stable size for a texture or should it be larger or smaller?

What program can I open a .map file in that will show me line numbers? Otherwise, I'm doing a ton of division in MS Word, since it at least tells me what line per page...

Can I edit the .map file, open it in Hammer, then save it as a new .rmf file?
If I can edit it, I would try to replace the low decimals with 1, then fix them again in Hammer.

A suggestion for future versions would be to add the brush number to your list as well as the texture size and a method for saving to a log file. Then noobs like me could waltz around in Hammer and take care of it in an environment we're familiar with... and I'm not so noob I don't know how to mark and select it to paste in a notepad file. But others may not know how.

Wow! I will give that program a try! Thanks, Captain P!

I don't usually hit the "fit" button, except to fit one side (or two, if it's a door. And I only do it one side at a time.

It's not that I don't expect to have them, but to compile for an hour to find out the next object that needs correcting, well, it's driving me crazy! Usually I have an error or two and I fix them, but it's almost like every object has this error. I'm just looking for someone to say I'm doing right by fixing each one instead of throwing out the map because it'll never be fixed.

Well, I'm guessing it's extremely small textures... mixed with large ones... along the lines of 1.67x 0.21 kind of stuff... Every time I fix them, a new one comes up somewhere else. Is there a way to make it list all the objects? It appears to compile through VIS. I'm not sure how it does it, but I would think it could know all the offenders after a once-through.

Hiya Rowley!

Pasting the co-ordinates into the brush number fails. I'm sure it would like an actual brush number.

I know what they are and I (unfortunately) know what needs to happen, and I've been doing it. Since Hammer finds no errors in the map, I am individually hunting down the offending surfaces and re-texturing them. What I'd like to know is this: Is it better to check the world box or the face box as far as the texture is related. Most of these textures are at the surfaces that touch, so they are never seen. I am selecting them, resizing them to 1x1, centering them, and checking the "face" box... so... is that the best way to fix them when you don't know if they're truly the problem?

You can... but why would you need to? Except for the video card, which you can upgrade, Macs come top-of-the-line right out of the box. With a PC, a "builder", like Dell, puts in the minimum requirements for the MOBO... then charges you severe markup to upgrade. With a Mac, if the MOBO holds a max of 2ghz of RAM, then it probably comes with 2ghz of RAM.

My friend is considering of buying a Mac too, but I can't figure out why.

They never break.

I have owned both Mac and PC and if you were doing something intensive, like photo or movie editing, or doing extraordinary calculations, like high powered derivitives and algorithms, you would want a Mac. If you had 10 people working for you, say, digitally modeling, say "Toy Story", and each person had to wait 20 seconds to load their 2 seconds of realtime movie, just to see how it looked, then change something, and wait 20 seconds again, over and over, it would take a LONG while to make that 2 hr. movie. If a Mac could (and does) do it that same thing with a 5 second load time, your employees would have Macintosh. Period.

Now if you want your employees to surf the internet at lunch or email the latest jokes to the other plebes in the mail room, then a PC's your huckleberry every time!

Honestly, this topic is like the Ford/Chevy argument... who cares what it is as long as it does what you need? It's a tool. How many PC'ers are trying to make their machine like a Mac by installing Linux, eh?

As near as I can tell, it's Transformers! (More than meets the eye!)

If you cut a block into a wedge and then resize it, it could cause errors since the scaling of the angle could create infinite math for the engine.

Phys_ballsocket might help you since it mimics, among other things, a hip or shoulder joint.

Just thinking out loud, and I'm all for trying to do things for the sake of doing them, so keep at it, but, just for me, wouldn't it be easier to make in a modeling program... like the buggy and waterboat? I guess I'm asking how would Valve have approached your project? How would they solve it?

Heh... it really is a map in the rough. Just the big ticket items, so far. And the light has been turned way down trying to compensate for the model texture I had.

And thanks for the comments!

Fixed!!! Yes! Thanks, Seventh!

Here's a screenshot of the map. It's in the rough, but coming along....

well, it is a model texture. (Why do they even put them in as choices, eh?) I will change it and see what happens. Thank you!

I am having a problem with the way a few brushes are lit in my map. What I have is a taller building that has a few decks in it. The second deck up has a hole in the wall for bringing in supplies... picture it like a barn... big doors and above it, another door. And above that deck is a third deck. They are smaller brushes... maybe 256x96. Also the doors are open. The pavement outside and inside the building are a whitish texutre. There is water nearby, behind you, in this view, and also some water inside the building. The building is a boat maintanence building with a water bay for small boats inside it. Hopefully, you can picture that.

Now, here's the problem. As you approach the large doors, you can see inside, through the doors and also through the hole above the door. Essentially, you can see the bottoms of the decks. They are lit like they are in a fullbright map, though that's not the case. Once you get inside the doors, the lighted textures on the bottom of the decks fade to dark shades of the texture, which makes sense, since you've come inside, where it's darker. Alot of times, they don't darken up right away and sometimes, deep inside the building, they spring back to fullbright, if you move just right. These three brushes are the only three inside that do that, and only on the bottom. I have changed the lightmap scale to 8 on this with no noticeable effect. I have placed cubemaps under the textures and drew the cubemap from the texture (not sure if this was correct) and that didn't help or hurt anything.

I'm sure that there is a ton of light bouncing around at that spot, reflected off the water and off the cement texture. Should I split the floor brush along the building wall and make the interior texture different? Do that and grab the cube's map from the new floor texutre? While there are a ton of tutorials out there, there really isn't any kind of lighting (or modeling, for that matter) troubleshooting guides and, frankly, I'm stumped. Thanks in advance.

By the way, what is the invisibleladder texture for?

It is steam... when I first started out with SourceSDK, it was that way for me. One thing I do is make sure that once Hammer is started, I shut the "Play Games" window. VERC says that window eats the memory or doesn't release it or whatever. Closing it and all the other steam related windows helps.

You can ctl+alt+delete, go to "processess", select steam.exe, right-click it, and set it's priority to low.

I also set the model preview fairly close, so that Hammer isn't drawing a Gordon way away from where I'm working.

Better more info than less info.

And that is the word "Camera" in the upper corner of the window...

Try selecting all of your map, pasting it into a new Hammer page, giving it a different name, and re-compiling.

Creating default cubemaps for env_cubemap using skybox sky_wasteland02...

It sounds to me that you haven't placed an env_cubemap in your map... It would not create a default one if there was one to use already...

I switched to a phys_ballsocket and I think that will work once I get the settings correct. When I shoot it now, it falls to the ground and the rope plays out like it was off a winch, which is not the effect I'm after... but it's better than the perpetual motion machine that it was. Rabid's suggestion of an additional phys_constraint should work.

So if Mass Scale is the default mass times that number, where do you set an actual mass for an object?

I have a prop_physics_override attached to a rope and it is just ducky! The problem comes when you shoot it. It spins and twirls, like it is supposed to. And spins and twirls... and spins... and twirls... and spins.... and keeps going on and on about it! I never comes to a rest. Here are some settings:

The Mass Scale is set to 2000, physics impact force to override is set to 150, and Don't take Physics Damage flag is checked. I believe this means my prop "weighs" 2000 widgets and it takes 150 widgets to set it in motion and it will never be destroyed. I also figured it'd be considered "heavy" and come to rest easily, but it doesn't stop... ever again.

I am using a phys_constraint to hold it to its base plate. Should I try a different phys? Like phys_ballsocket? Now that I spell it out, that sounds like a damn good idea! You guys are great!

Create your newspage full length and on the index page, link the "read more" to an anchor at each newstory...

God....

I will, but I need to call all the information back again... it was a semi-detailed post.

I posted a question last night in the HL2 mapping questions forum. It's not there now. Was this removed for some reason? If not, where did it go? And why?

Do what Rabid said. Here's what probably happened:

When you were fussing with them, you grabbed their little "globe" helper-handles and moved it... ever... so... slightly. That makes the minimum fade distance smaller than the object itself, making the object fade away before it can be drawn.

Convert the old decals and textures into new ones...

Make a shortcut to STEAM on your desktop and add " -applaunch 211 -runhammer" to it.

Make sure that the account that has access to the SourceSDK is the account you last logged in with and that it remembers your password, or it will hang up at this stage of connecting.

Another decent one for tutorials.

http://www.akilling.org/akg/

Good for finished map distribution: http://www.globalassault.com/index.cfm

What isn't readily explained in that tutorial (It took me a long time to make a ladder from that tutorial) is that when you place the func_useableladder, you need to grab the little white circle/dot and drag the SECOND box (that is perfectly on top of the FIRST box in all three views) to the top of the climb. It's a two-part single entity.

Also, ladders work poorly in Deathmatch. It's like you've developed a severe hiccup as you climb.