Forum posts

Yes, noob question, I know. Plz?

K, so this archive has a folder named "spirit" and 4 dlls. I should extract the contents to my Half-Life directory right? Two of the dlls are already in that directory; should I override them? and should I make backups of the old ones first? Thc for halp

Yes, I know. I've been doing extensive clipnode optimization on a map myself, and I've reduced the figure from above-max to about 50% so far. But the kind of project I'd have in mind for a 32000x32000 grid would easily surpass max clipnodes even with tons of optimization. Actually though, that sounds like a fun challenge (like my current challenge isn't enough of a headache -_-)

I'd be interested in this if it included a convient lil max clipnode hack as well. I don't see myself making (good) use of 32000x32000 units if I'm under the same clipnode resriction. Just means sacrificing detail for size.

Lets say you have a 14 side thing in your map, you cover it with a clip brush and instead of many clip nodes you get only 6.

Only if the 14-sided thing is a func_illusionary. Right?

you're not an attorney btw, are you?

No, but I agree that I'd make a good one. Kind of like I'd make a good everything.

Oh now you tell me.

p.s. thx

and i'm still proud of that.

and rightfully. With the neccessary programming, one could create an entire map--regardless of how complex--with a single brush. The "exploit" you found and made use of must have taken some effort to discover. I can't speak for anyone else, but this falls neatly into my definition of getting the most out of a brush limit. The rules didn't cover potential use of exploits, nor use of HLFix (not to claim that I could've had better foresight.) The question here is, what is being considered the brush count? As we were required to upload a hammer shot "proving" that we stayed within the brush limit, it seems logically sound that the brush count displayed in Map Properties is considered the brush count.

This thread is to clear up an apparent misunderstanding about clip nodes and brush entities. If someone sees that I'm missing something, please explain.

From this thread:

Without knowing for sure, my guess would be a func_wall WOULD create clipnodes, because it creates a solid surface the player can touch, jump on top of, etc., where an illusionary obviously forms no barrier, so it creates no clipnodes..

Exactly. And thus it's pointless to turn very small brushes or groups of small brushes or brushes that are one unit thick into func_walls. Turn them into illusionaries instead. They're to small to stand on, what's the point of making them func_walls?

I went through a good portion of the map in question in the thread linked above, converting most of the func_walls to func_illusionaries and placing simplified clip brushed over them with the idea that it would decrease clip nodes. Then I compared the compile logs before and after, and as it turns out, my clip nodes had increased. What I initially assumed is (to the best of my knowledge) true: brush entities DO NOT CREATE CLIP NODES. I know that they block player movement, but apparently they do so in a different way than world brushes (one that doesn't add to the clip node count.) Therefore, adding clip brushes over brush entities is pointless and only creates more clip nodes. Proof:Am I overlooking something?

I would like to think most people here have the respect to vote for which entry they truly think is best. Seriously, does anyone care anough about a stupid little icon that it overrides their sense of due respect to the effort of others?

I hope so. After optimizing, that number has decreased but the other three have increased.

Okay. There are four hulls calculated by vis, HULL 0, 1, 2, and 3. Which reflects the number of clip nodes? Or is it some combination of them? Anyone know?

Combining entities fixed it. Thanks.

FresheD: minimalistic indeed. And creepy.

(c)Striker:



I love it! Very space-age floating metropolis. The black reflective tile texture on the ground below the sphere-tube thingy creates a very ominous, vaccuous impression that off-sets the the radiance of the bright sprites and light beams perfectly. Great texturing and atmosphere all around, and totally the kind of aesthetic I'm into. Above all, very inventive use of the 30-brush limit.

Sorry, Captain Terror, gotta change my vote <3

@ Capt. T: With atmosphere I just mean the whole 'feel' or look of the map. So far i'm impressed with the actual structures you made, but the picture as a whole misses a 'soul'. Try to incorporate the structure in the rest of the environment, so it seems part of the environment. The sky is certainly key in this one. Perhaps i'm being a bit too abstract now, but I hope my point comes across. The entry looks good, don't get me wrong, but it can be better with just a few touches of love!

Imo, the gray dev texture gives the impression that the structure is rising from the blueprint, right off the paper and into reality. I can understand it being seen as unpolished, but I have to contest.

quailcreek: i'm still studying your entry do see how you built those structures. It would be nice if you showed more hammer views to see how you did that.

Sure thing:As for the seemless texturing, I flattened the brushes protruding from the floor and ceiling before applying textures, then used the "World" (a.k.a orthographic projection) option, and extended the brushes back out.

I do love that, Captain Terror. Unless someone surprises me, I know who I'm voting for.

FINAL

If you're going to be a pedantic piece of shit then at least get the word right, it's minimalist.

"minimal" is often used as shorthand for "minimalistic" (which is what I think you meant to tell me I meant.) And though I may've come across as a pedantic piece of shit, I was just trying to point out that while simplicity may not appeal particularly to zeeba-G, it isn't a quality that should be looked down upon by default--which just makes me a piece of shit.

I hate to rain on your parade, but no. They are two entirely separate poeple.

Wrong again. We're the same person.

zeeba-G: The word you are looking for is minimal, not simple. And coincidentally, using less than what's available is very minimal in spirit.

What makes you think I know anything about hint brushes?

A few of my func_illusionary's disappear in-game from certain viewing angles and distances. They just vanish. I move to another spot or turn the camera to a different angle, and they reappear. Huh? The entities are covered by clip brushes, but that shouldn't be causing it. I fear this might be a sign of a video card going faulty, but I REALLY hope it's something else. Can anyone help?

edit: I have the latest gpu drivers and the latest directx

It won't. I'm not big on names that make a statement, say something about someone, or have any obvious meaning at all. It's all superficial to me.

é wins.

Oh, darn. Well then how bout just

é

Yes, I'm serious.

Yes? Oh good. I'd like my name changed to

le mouton mouillé

please. Thank you. I hope the "é" character isn't an impossibility.

It does made sense to me that func_walls would create clipnodes, but that condtradicts the test I did. The assumption I've been working on is that they create clipping in a different way, one that doesn't factor into the clipnode limit. For an eample, clipnodes being created substractively by the hull brushes, then func_walls being added back in additively. Maybe that would be slightly more resource-friendly? Idk, I'm just rambling. Only Gabe Newell and a few other Valvers could probably answer that question.

Anyway, based on what advice I've gotten here, I'm led to beleive that the sole purpose of func_walling small details is to reduce r_speeds. A better way of optimizing, if that is the case, would have to be taking Captain Terror and Mighty Atom's advice and making deatils func_illusionaries and covering them with simplified clip brushes; that would BOTH reduce r_speeds AND clipnodes. Thanks guys, and I'll jump on that.

I'll also try compiling with cliptype -simple when I get around to it.

Not exactly sure what you mean, can you elaborate a little?

No, but a picture can:

Take all the complex things and turn them into func_walls
everything that's not an external wall, that is.

So pretty much anything with more than 4 sides, or smaller than 32units^2 make a func_wall..

I've already func_walled everything that isn't part of the hull of the map. I've optimized this map pretty extensively, granted I could be missing a few things.

EDIT: I have more to say about this, but I have to go to work.

Instead of using func_wall, i prefer to use func_illusionary covered with a clip brush(s), to approximate the shape in size of the object. This way, any piece of the illusionary sticking out of the clip brush won't create clipnodes.

If it's a func_illusionary (or a func_wall or that matter) it shouldn't create clipnodes, from what I've been able to gather. I did a few tests, compiling a square room and seeing how many clipnodes it creates, then putting a complex object in it and making it a func_wall: the number of clipnodes were the same. However I'll do more experimenting with your idea.

Idk what is exactly IN your map, but if you send us a screenie of the Hammer view i can give even more tips.

Sure thing. You can't see the entire map, but you get a good idea of the most complex parts:

Hope we're aren't confusing you.

Nope lol.

Okay, so it was a leak. But in my defense, it wasn't caused by actual brushwork resulting in a hole in the map. The line file entered at a point where I had used a very thin brush to patch the map up. My guess is the engine was excluding or altering this brush in some way. I replaced it with a larger brush and it compiles successfully now, but now I'm running into this error when Half-Life tries to load it:

Hunk_Alloc: failed on 50400072 bytes

I realize that this is supposed to mean I have insufficient memory, but I have 2GB, and it was loading fine on my old 1GB computer.

Also you have some complex stuff in the map, try breaking it down a bit.

By break down you mean simplify? I'm rather proud of the more complex areas of my map. I'll work on adding more clip brushes wherever possible, but I'd really hate to simplify the brush work already present, especially considering that I've seen it in-game before so I know it's not a total impossibility.

DO NOT make any really crazy shapes textured with CLIP, cuz hammer won't like it and will smite you.

I'm glad you told me this. I had no idea it could cause problems. I use clip brushes such that they simplify the clipnodes in the map (I have a fair idea of how they work), but sometimes I make the brushes more complex so that they conform to the space they're filling, rather than just having parts of the clip brush go outside the map. Would you advise the other method?

Log is shown below. This is a map that previously compiled fine, on a different computer, and the only changes I've made (I think) are adding a few clip brushes. But I may have been compiling with different settings on the other computer, can't remember. I remember that running with cliptype precise avoided the MAX_MAP_CLIPNODES error on the other computer (not to mention fixing a few other important things.) This is a massive map that I've been working on for 3 years now, so I'd rather not upload it as a problem map if I can avoid it. Maybe I should try some different zhlt settings? Help appreciated.

edit: Also, the line file never enters the map's hull. I'm 99.99% sure this map doesn't have a leak.

hlcsg v3.4 Final (Feb 25 2006)
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 (amckern@yahoo.com)
--- BEGIN hlcsg ---
Command line: C:\ZHLT34~1\hlcsg.exe "c:\valve hammer editor 3.5\maps\map_cp_0"-cliptype precise -texdata 8192
Entering c:\valve hammer editor 3.5\maps\map_cp_0.map

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

noclip [ off ] [ off ]
null texture stripping[ on ] [ on ]
clipnode economy mode [ on ] [ on ]
clip hull type [ precise ] [ legacy ]
onlyents [ off ] [ off ]
wadtextures [ on ] [ on ]
skyclip [ on ] [ on ]
hullfile [ None ] [ None ]
nullfile [ None ] [ None ]
min surface area [ 0.500 ] [ 0.500 ]
brush union threshold [ 0.000 ] [ 0.000 ]

Using mapfile wad configuration
Wadinclude list :
[zhlt.wad]

49 brushes (totalling 376 sides) discarded from clipping hulls
CreateBrush:
(11.69 seconds)
SetModelCenters:
(0.00 seconds)
CSGBrush:
(5.34 seconds)

Including Wadfile: \zhlt34x86final\zhlt.wad

• Contains 3 used textures, 1.09 percent of map (8 textures in wad)

Using Wadfile: \half-life\valve\halflife.wad

• Contains 253 used textures, 91.67 percent of map (3116 textures in wad)

Using Wadfile: \half-life\valve\halflife_special.wad

• Contains 17 used textures, 6.16 percent of map (21 textures in wad)

Using Wadfile: \half-life\valve\liquids.wad

• Contains 3 used textures, 1.09 percent of map (32 textures in wad)

Using Wadfile: \half-life\valve\xeno.wad

• Contains 0 used textures, 0.00 percent of map (264 textures in wad)

added 80 additional animating textures.
Texture usage is at 3.35 mb (of 8.00 mb MAX)
19.64 seconds elapsed

--- END hlcsg ---

hlbsp v3.4 Final (Feb 25 2006)
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 (amckern@yahoo.com)
--- BEGIN hlbsp ---
Command line: C:\ZHLT34~1\hlbsp.exe "c:\valve hammer editor 3.5\maps\map_cp_0"

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

noclip [ off ] [ off ]
nofill [ 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 8192)

SolidBSP [hull 0] 500...1000...1500...2000...2500...3000...3500...4000...4500...5000...5500...6000...6500...7000...7500...7726 (1.13 seconds)
Warning: === LEAK in hull 0 ===
Entity info_target @ ( 894,-2664,-712)
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] 500...1000...1500...2000...2500...3000...3500...4000...4500...5000...5500...6000...6500...7000...7500...8000...8484 (1.81 seconds)
Warning: === LEAK in hull 1 ===
Entity info_target @ ( -48,-2896,-696)
SolidBSP [hull 2] 500...1000...1500...2000...2500...3000...3500...4000...4500...5000...5500...6000...6500...7000...7500...7542 (1.44 seconds)
Warning: === LEAK in hull 2 ===
Entity env_beam @ ( -48,-2896,-676)
SolidBSP [hull 3] 500...1000...1500...2000...2500...3000...3500...4000...4500...5000...5500...6000...6500...7000...7500...8000...8500...9000...9366 (2.45 seconds)
Warning: === LEAK in hull 3 ===
Entity env_beam @ ( -48,-2896,-676)
Error: Exceeded MAX_MAP_CLIPNODES
Description: The map has a problem which must be fixed
Howto Fix: Check the file http://www.zhlt.info/common-mapping-problems.html for a detailed explanation of this problem

--- END hlbsp ---

hlvis v3.4 Final (Feb 25 2006)
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 (amckern@yahoo.com)
--- BEGIN hlvis ---
Command line: C:\ZHLT34~1\hlvis.exe "c:\valve hammer editor 3.5\maps\map_cp_0"

There was a problem compiling the map.
Check the file c:\valve hammer editor 3.5\maps\map_cp_0.log for the cause.

--- END hlvis ---

hlrad v3.4 Final (Feb 25 2006)
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 (amckern@yahoo.com)
--- BEGIN hlrad ---
Command line: C:\ZHLT34~1\hlrad.exe "c:\valve hammer editor 3.5\maps\map_cp_0"

There was a problem compiling the map.
Check the file c:\valve hammer editor 3.5\maps\map_cp_0.log for the cause.

--- END hlrad ---

Haha, oh i see.

'historical' is a pretty broad term so we'll limit it to stuff before 1990

boy that really narrows it down, doesn't it? All the significant stuff in the world has happenned in the last 20 years.

Question: by "historical video game context", you mean a video game reproduction of a historical location, meaning that the entry would be a video game reproduction of a video game reproduction of a historical location, right? Or am I getting it wrong?

I think the more vague the theme the more creative it allows you to be.

Eh. The less restrictive perhaps. But it doesn't encourage finding clever and intuitive ways to express things, imo.

A map from base thing sounds fine as long as the base actually leaves something to work with. Being too simplictic can lead to this problem just as being too detailed can.

Don Punch: Are you talking about the client side/server side entity limits? If so, that would double the entity limit wouldn't it? Also, you'll have to give me more specific instructions on how to do this.

Also, I have no idea how I would go about setting this up as a particle system. Can you make a beam-like sprite appear across two control points?

So it appears func_instances are only supported by L4D. Would others agree?

Thanks for the link Blitzkrieg.

So I tried this out. I put a func_instance referencing the beams map in another map. All the entities in the beams map showed up in the editor with a yellow tint ...everything seems to be working up to that point. I compiled, and none of the beams/sprites appeared in-game.

Tetsu0: Thanks man. I didn't know that entity existed. I'll see if I can figure out how it works and if it will help me bypass the entity limit. You're free to do more research of your own if you want, but don't feel obligated, as it's my problem.

First off I'm sorry for the ridiculousness which is this thread. Yeah, I was boastful, a smartass, and couldn't just get to the point. The reason is drugs. Not that that's any justification, but it's the primary cause behind me doing shit like this. I'm now in a mindset to be reasonable, fortunately.

As for the topic at hand, I'm finding myself wanting to create effects that the engine wasn't made for using functionality that wasn't made for it. It's pretty simple stuff but the functionality to approach it in a sensible way just isn't there. Source was made for realism. So I guess all I can do is try my hand at coding.

Strider: I could be totally wrong here, but I don't think I need to stick to a very strict budget to get what I want done. The entire map is enclosed in one small room which accounts for all of the brushes, and there are no high-end effects whatsoever, just beams and sprites. A modern computer has no trouble rendering ~1000 sprites simultaneously. Am I wrong? I realize the entities take up RAM as well as graphic memory, but shouldn't the (almost) complete lack of solids being rendered free up this space if not much more?

Moaby: I need to raise the entity limit to something more like 8192. Ideally, I need to have no entity limit because I can moderate my own resource usage perfectly fine.

(reply to Strider:)

Right. This is what scares me (from VDC):

The two entity lists are created by CBaseEntityList::CBaseEntityList() using NUM_ENT_ENTRIES and MAX_EDICTS. Neither of those values can be changed without breaking compatibility with the engine.

maybe that's why it's there... to scare people. Maybe I should stfu and try it anyway.

I have this phobia for code. But one must face his fears.

O_O

Exactly how hard on memory is an amount of more than 2048 entities? I'm talking env_sprites and env_beams here, though I guess its the case that graphic complexity has nothing to do with memory management of entities. But I mean...

WHY GOD? WHYYYYYYYYYYYYYYYYYYYY

Yes, I understand that in ordinary cases, 2048 entities should be more than enough, and I also understand that ordinary cases are the only cases that should exist according to you folks. But this is an unordinary case, and it's one I would hate not to be able to finish. This.In case you're blind or not the sharpest knife, that's not chaos. It's a series of beams forming 32 complete loops in a radial formation, all conforming to what looks like a donut with one of its sides stretched way out; each loop begins vertical on the interior, starts bending progressively until it reaches near-horizontal on the far exterior, then mirrors itself and finds itself vertical again on the opposite interior side (that only describes half of the loop, of course.) What? That meant nothing to you? Oh I'm sorry. Look my point is that this particular feat involves one mothereffin hefty system of beams, because that's what it is: one mothereffin hefty system of beams. One thing it DOESN'T involve is virtually any brushwork. HL2 maps can be big, detailed, loaded with real-time effects...(that's what Source was made for rite?) What HL2 maps CAN'T be is tiny maps with no next-gen and/or graphically intensive effects whatsoever and...extremely complex structures made of sprites. Why? Because that's not what Source was made for? Well dagumit ya dun told me so didn't ya.

I am 100% certain that if my hardware can run HL2 smoothly, it can run what I'm trying to make smoother than smoothly. I need the entity limit removed. I need it removed now. I must continue. I know what you guys are going to say. "Impossible, sorry." But, that's not what I want to hear. So tell me something else. Please.

Congrats, zeeba-G! I don't doubt that they made a good decision.

I have yet to play any of the others, though. I will when I can spare the time.

Idk what happened to map number leet but TheGrimReafer deleted 5533 as per request, in case you wanted to know.

Is it possible that someone could delete this map from the map vault? I noticed a serious flaw in it and I also want to make a few additions before re-releasing it. Thanks and sorry for the trouble.

And would using white squares of solid colors as sprites not be an exception? What I'm trying to do is create a sort of "matrix" of squares of various shades of grey which blink in and out of existence in a spherical formation, and parent the system to the player, so that it looks like an animated skybox. I also want full coverage of the sphere surrounding the player. The idea is that the player is trapped inside a tv screen showing only analog noise. Brilliant, I know. Seems pretty graphically simplistic but maybe it would be to hard on memory simply because of the amount of particles? It's not like the particles will be one pixel in size; more like 8x8.

I realize that Source wasn't particularly designed for this kind of effect but any ideas as to how to approach it, using particles or otherwise, are appreciated.

sup. k this is a real question. In the particle editor, I can't increase the max particles beyond 5004. How to change this?

Ignore this thread. I was doing something wrong.

Do I have to install EP1 and/or EP2 to be able to create particle systems, or can I just install SDK Base 2007? I would find out myself but I'd rather not install something unecessarily.