Forum posts

If you guys want a room compo, then a room compo it shall be.
Team compo sounds good too, perhaps not on these short terms but definitely something interesting. I'm thinking towards texture artist + mapper somewhat though that's probably not feasible here on TWHL.

Results coming up within 2 days or so, I've already made some notes but it's going to take a little time to decide who really won, and to prepare the combi-map.

And I'll happily prepare a next compo page, with timer, image and rules 'n stuff.

Nice stuff, Trapt. I'd add some fences by the buildings up on the ridge though, because the lighting on the side of the buildings indicates there's a path there (otherwise you wouldn't need lights there, right? :)), and since there's a rail below... I'm talking about the yellow building specifically.
Alternately, take out those lights to put more focus on the entrance of that building plus the truck.

Rabid, your architecture is looking great and it breathes a worn-off industry athmosphere. I'm not sure about the greenish lights though, in combination with the red brick and reddish skylight. Some more yellow would suit the red better, I think. Also, consider upping the brightness some. It's nice and moody, but a bit too dark to show off the good stuff. Might be just the screenshots though.

Good luck guys, nice stuff.

The screenshot looks rather dull really, the colors aren't fresh or pool-like. But the conveyor water trick works nice, ah? I used it several times in The Playtest, only without an added func_water.

It does affect clipnodes, but a clip brush isn't a node itself. See a clipnode as a convex 3D passable block, the player can only walk through clipnodes. By covering complex solid brushes with a clip brush, you prevent them from splitting the rooms clipnode up into many small clipnodes, creating only a few instead.
It's like face splitting, but 3D volume splitting instead. A simpler clipping hull means shorter compile time and faster in-game behaviour, theoretically. The in-game gain is usually not really significant, but since we lack specific profiling tools for HL there's no way to tell.

It's one of the reasons I'd recommend to make small detailed brushes func_illusionaries rather than func_walls, or to cover them with clip brushes.

You could use a little hack: place large brushes over the parts of your map you don't want compiled. It's not only usefull for finding leak sources...

As for .rad files, as far as I remember you could give VIS some parameters to let it know what extra .rad files to use. Don't remember the exact param, but I think Muzzle knows. After all he's been working on a compiler front-end.

This is a problem with their placement, not with applying textures.

Try moving the prefab around somewhat with Texture Lock off. Perhaps you can find the position on which the textures mapped correctly to the prefab. Otherwise, good luck manually fixing them.

I've received 3 entries so far, from Worldcraft dude, n00b #2 and rowleybob. I must say, they're all very nice. No map is very similar, everyone has things that stand out.

It's going to be interesting to judge this one.

// As for a next compo, feel free to post idea's. I was thinking of a 'hide your easter egg as sneaky as possible' a.k.a. a secrets map (including bling sounds and secret counter? :)) - but since that's more design-oriented instead of advanced brushwork oriented, I think we'll see better idea's pop up soon.
Go ahead brainstorming, I'll post the compo results within a few days.

It must be 8bits as far as I remember. Try converting it (Wally is much better than MSPaint for this btw) and see how that goes.

Then what's your definition of 'advanced brushwork', Ubreakable?

I don't say this is advanced or so, however, nobody's stopping you from doing advanced stuff in a miniature city.

Let me think... did you use 8bits bitmaps?

Hmm, I assumed the interior and exterior were distinct maps, but they're in the same map, right? I wouldn't do that if I were you, Rowley. Too restricting, and with a little trickery you can fake the player a long way without ever breaking the immersion.

ROFL @Rimrook!

Rowley, I'd say we simply vote for the best idea. I think that allows the most popular compo's.

The idea behind my original map, and therefor the example map that sort of started this compo, is my interest in RTS game development. By creating such a map, I aimed to get a better understanding of (urban) RTS environments. I'm creating some unit models now and then too, just to get a feeling for it. I think it's quite a challenging thing, such level-design, since most RTS'es use a heightmap and depend on models for the rest of it. Quite a different method. Combining both modelling and level-design into one package sounds more interesting the more I think about this.

Uhm, no, that heli isn't just a different model, there's also some different AI under the hood there.

However, you can change models, provided you don't change anything the code needs, like attachment points and the like. Not something you can do with Hammer only though. Well, since the citizens for example have a variety of models they can use, you could give it a try of course, but I can't guarantee the game won't crash or something...

Depends on what you call 'advanced' of course - this compo is quite tiny-brush heavy. Plus, you can decide the size of your city part yourself, a larger map isn't necessarily a better one. Well, perhaps I shouldn't have emphasized the custom content usage so much (especially models).
But, you can't please everyone, so yeah, better luck next compo.

Looks nice, WCD and rowley.

Heh, looks pretty cool. You could spice up the exterior more with some custom textures containing the smaller details, to add some more sense of hugeness to it.
Can't say I like the interior so much really. I've seen too few Star-Trek episodes to be able to comment on their recreation, but from a mappers point of view, they look kinda flat and dull. It's probably the textures you chose too - not quite the most beatiful ones from the HL set. Plus they're mostly empty rooms for now. Adding objects, which you're probably still going to do, will spice it up for sure, but creating some more interesting rooms, like multiple catwalks leading through the same room (start area of BlueShift, for example) and such might be a good idea. Oh well, it's still early stage...

Nice shots, Trapt. I like the light details, good contrast.
You should put some light bulbs under the roof too, as that's a natural place for lights. You'd loose the interesting bench shadows, but you could retain that effect by 'breaking' one or two of the lights at the end of the roof. Hmm.
I'm not so sure of those red lights at the tracks either. They catch too much attention for my taste, attention that is better given to the buildings you still have to add on the other side of the tracks.
The background building is cool, I like the cold light beam over there. Good athmosphere building.

srry, a camera showing off the city is fine. Screenie looks good bytheway.

As for inspiration, Google Image some city shots, or use a program like Google Earth or such. Highways, harbors, military bases, mountainside ski resorts, just a few things I can think of right now. A country-side village or such is fine, too.

And indeed, no size restriction to the area you map, you only need to take care of the scale.

Nice idea, Kasperg. Throw in a water caustic effect (animated, or layered scrolling, textures) and you're set and done.

That's right Kasperg - also, the example map provided at the end of the page should give you a fair idea of the intended scale.

As for submitting the map, you need to provide both a playable .bsp and the source of the map (.rmf and textures/models/other necessary stuff). You don't need to put this source open for public if you don't want to, it's only for the combined map at the end. I'll update the rules page with this info.

Elon, that's the good stuff. Keep it coming! Anyone else with some results already?

EDIT: Page updated! You may need to refresh the page to see the new info.

The first shot feels wrong in terms of lighting. A very bright sky and an almost pitch-black shaft... better would be to let light stream in from one side, creating interesting shadows, and using artificial light sources down below.
Otherwise, for what I can see, it looks ok. A bit standard Shaderlab feeling - it seems everyone that uses these textures adapts the same architecture style - with long, broad corridors and such, so you may want to deviate a bit more from that. Perhaps adding some machinery here and there, and finding a more defined lighting style - those blue default HL light textures are ok, but I think they aren't the best to fit with the Shaderlab texture set. Hmm...

And of course, up the brightness some more. Usually, bright area's are more inviting to play (or at least, that's my personal preference).

Oh, bytheway, you can submit your maps by posting a download link in this thread, or PM'ing it to me if you don't want to put your map public before the deadline.

@Muzzle: you're in?

Ok people, countdown page is up:

BrushoPolis contest page

The deadline is set at friday 14 juli, midnight, universal time. The page includes the basic rules and an attachment containing an example map and some simple textures to get you started. I'm looking forward to see the results.

// If anything is unclear so far, just say it and I'll update the competition page.

1 week sounds better yeah. Gives some room for content creation.
About size restrictions, perhaps an area of 1024 x 1024 or 2048 x 2048 max, to prevent people from taking on too much for the time set?

Countdown page is on the way, which will also contain the rules and further explanation, as well as an example (not base!) map for the scales.

Currently, I've set the following rules:

1. The map must represent part of a city. Whether that be housing, offices, industry, military, other. You're free to pick the style/culture, it can be human or alien, as long as the purpose of the buildings is clearly visible.
2. The scale is set as 32 units per floor, which is approx. 2.5 meter per 32 units.
3. Custom content - textures, models, sounds, sprites - is allowed. In fact, even encouraged, because you work at a much smaller scale so creating some specific textures for buildings to cover them easily is probably a good choice. I'll provide an example map and .wad soon, and those that have problems creating custom stuff can always give me a yell - this might be a nice opportunity to broaden your skills.
4. The map must be playable under Half-Life. You're allowed to create it for other mods, but this will be of little use as all maps will be checked with plain Half-Life.

Maps will be judged a little on originality, mostly on the general impression and feeling of the map. Which means, detail ahead, but detail wisely - where it counts and really adds to the map.

Sounds good with everyone?
When shall we start and what deadline shall I set?

I think Spirit isn't really usefull here either. If it's all about the brushwork detail, then entity work isn't going to be very necessary anyway.

Try this page at Snarkpit. And perhaps Ten Four reviews has reviewed some HL mappacks between the many mods there...

Yeah, high poly city...

I could make a count-down page, just give me a yell. Also, I think it's good to decide a scale so the maps can be combined in the end. Might give a nice result.

I've done it a few times. Made a small city-map, intended for a compo, with some military vehicle models I was going to animate to set up some scripted sequences. Never got past creating the map and a few models though - the deadline was over by then.

Good idea, but when you put your snap-to-grid to 1 unit, you can do some pretty detailed stuff, but nothing near as close to the quality of a model.

That was my idea: you stick to the 1 unit grid and essentially make the object at a larger scale, then make it an entity and set it's scale, so the compile tools scale it down.
But it has little to do with this competition so I'll leave this thread now. Good luck to you all.

How about mapping large objects on a small scale? Like creating buildings as if you were modelling one for a RTS game... complete with streets and 1-unit thick streetlights...

If you set a scale beforehand, you could combine the contest entries into TWHL city.

Can you post a screenshot of your level showing the problem? It may help us giving some specific tips.

I think the 'no custom content' rule is a fair one, but how about (say, for a next compo) a 'share your custom content' rule? If you use it, you must put it available for public use...
That would give prop usage some fresh air...

// Hmm, now that I think of it... perhaps some compile tool modifications and trickery would allow finer brushwork... I'm thinking towards scaling brush-based entities down at compile-time... in the end, brushwork and models differ only by the way the engine handles them, they're all a collection of surfaces. Not that I'm going to attempt this, but hey. Nice to think about.

Looks more like a graphics glitch than something you could've done wrong in your map. Does it only happen in your own map or...?

If so, what entities did you put in it? Also, have you checked the compile log? Perhaps you have a leak (though that shouldn't cause this effect, but anyway)...

Nah, makes his commands stand out from the excisting ones.

Sounds cool bytheway.

That battle tank never moves.

Rowley, the HL engine has nothing to do with this. It's gamecode we're talking about, and the ability to set it to your hand using entities.
a, the Half-Life gamecode simply doesn't give you such options. Go with Spirit of Half-Life.

Can you post the content of your .qc file, as well as describing what files exactly you exported, and with what options?

EDIT: How do you compile? Using the built-in-Milkshape compiler, I assume?

HL ladders are brush-based entities: select a brush, press Ctrl + T (or the Tie to Entity button in the left panel) and select your entity of choice. Triggers, doors... generally any entity that needs a volume is a brush-based entities.

Woah, that's a lot of wrong settings there. No wonder compiling gives you headaches.

Those settings still refer to the old compile tools. Instead of qcsg, refer to your freshly downloaded hlcsg - do so for the other 3 compile programs as well. Also, you should fill in the game executable option in that panel - in this case, that's Steam. And place the compiled maps in your Half-Lifetsmaps folder, because that's where TS looks for it's .bsp files.

Then, in the Game Configurations tab, fill in the mod directory where you've filled in the game directory (valve). It's not officially correct of course, but makes sure the right folder is used.

Now see what happens.

Decompiling should work, really.

Anyway, here's a typical .qc file with some additional comments, I hope that explains all you need to know.
As for .smd files, there are two types of em: one contains the mesh data, the actual model shape, the other contains animation data. A model should always have at least one animation, even when it'll never moves - the animation then simply is just pretty empty. You'll be given the choice between mesh and animation .smd when exporting, so that shouldn't be a problem. Ok, onto the .qc file:

[quote]// output model name, smd and texture pathnames
$modelname "C:SIERRAHalf-Lifevalvemodelsoutputmodelname.mdl"
$cd "smd_directorysubdir"
$cdtexture "skins_directorysubdir"

// dunno what this was for exactly...
$cliptotextures

// just in case you want to scale up the model
// scaling up the skeleton in Milkshape would mess up all animations
$scale 1.0

// attachments, only usefull if you've got custom code that uses these
$attachment 0 "bone_name1" 20.000000 2.000000 5.000000
$attachment 1 "bone_name2" 20.000000 2.000000 5.000000

// bone controllers, these can be directly controlled by the gamecode
// think of facing upwards/downwards
$controller 0 "bone_name" XR -30 30
$controller 1 "bone_name1" XR -30 30

// hit boxes, again only really for models used by gamecode
$hbox 0 "bone_name" -4.690000 -4.440000 -6.750000 4.000000 5.560000 6.750000

// the smd filename that contains the mesh
$bodygroup body
{

studio "mesh_smd"

}

// sequences, first the sequence name, then the sequence smd filename, then some engine-specific info
// like speed and gamecode tags (for example, ACT_IDLE will be used as an idle animation,
// ACT_IDLE 1 and ACT_IDLE 4 will be used randomly, where ACT_IDLE 4 has a lower use frequency I believe)
$sequence anim_name "anim_smd" loop fps 14 ACT_IDLE 2
$sequence idle "idle" loop fps 14 ACT_IDLE 1
$sequence deep_idle "deep_idle" loop fps 12 ACT_IDLE 4 [/quote]

So essentially, a model that will only be used as a static detail would have a .qc file like this:

[quote]
$modelname "C:SIERRAHalf-Lifevalvemodelsoutputmodelname.mdl"
$cd "smd_directorysubdir"
$cdtexture "skins_directorysubdir"

$cliptotextures

$scale 1.0

$bodygroup body
{

studio "mesh_smd"

}

$sequence anim_name "anim_smd" loop fps 14 ACT_IDLE
[/quote]

Some things are learned the hard way...

Not that this was too hard, but hey...

The .dll's came with some Steam update, actually...

Just a note: don't care too much for degree perfection. It may cost you a lot of time, while players may hardly notice the difference.

Personally, I'd keep such angles at a 1:2 factor, rather than moving a vertex a few units so it's a 22.5 degree angle. Makes working on higher grid sizes easier, and working with rougher grids is safer in terms of preventing leaks. Of course, for detail, you'd use lower grid sizes, but rough architecture is better done at rough grid sizes.

In images:Easy to clip, easy lines that map to the grid pretty straight. Stairs can be clipped out of the middle brush pretty easy with the 3d clipping mode. That middle brush was created by sheering it so the left and right side got 45 degree angled, then vertex manipulating the yellow node of the right side, moving it up 2 grid units, then moving the top right corner vertices to the top-left somewhat. After that I clipped the stairs out of it and then it's a simple drag'n'copy job.

There's an article about this on the old VERC site. Turns out you need a compiler that supports the transparancy. I'm not sure if the download on the VERC still works, if not, contact me and I'll dig it up from my HD somewhere.

And they used thhe Q1 engine!!!

As DK said, a modified Q1 engine, some Q2 engine code involved as well. Haven't you done your homework?

// Heh, sounds like a discussion about stuff even the game dev team finds unimportant... like happens with so many popular games...

Worldcraft, created by Ben Morris as a Quake level-editor, was used. Ben joined Valve and continued to work on Worldcraft, though he doesn't seem to be involved with Hammer. Interesting enough, Marc Laidlaw joined Valve at the same time...

// This post was made possible by: Google, VERC, Blue's News...

Could be an odd-behaving entity, could be an old version of the map (compile problem, no new .bsp is written), could be something entirely different...

Perhaps submitting the .rmf or .map file to the problem map vault would help, so some of us could take a look?

People didn't even see my custom shadows tip because of that! :/

How can you know? Not everyone who reads, posts...

Well, if Jimmi, or Doctor Cheese, is the same person as ToastedKing, then he has written a tutorial about the Alt-trick.

But that wasn't before Ferret wrote about it, really.

@Muzzle: yeah, why the talk about that suddenly started, dunno. Pretty senseless. So, come on, talk about custom colored ZHLT shadows man!

Finally played through Ep1. While I prefer games as a long run rather than in episodes, I must say I'm not disappointed. Not at all. Valve managed to put some good fun in the game, and the commentary mode provides interesting insight in the process - I'd recommend all mappers or actually, level-designers, to listen to these comments.