Forum posts

But they also take time to switch to, closing your editor, firing up the batch, and so on. The ultimate situation is an in-game editor, with direct results. For me, Hammer makes compiling a little easier by providing a hotkey and a config system of it's own - it may take some more resources, but I feel more comfortable jumping straight from, and back to, Hammer.
But, that's a mappers personal preference. Both have their advantages and disadvantages and finally, there's zero difference for the results, so just go with the one you're comfortable with.

As for your map, how large or complex is it? There are many things that increase compile times that you can avoid, like putting small or complex brushes into func_walls (to prevent face-splitting - less faces, to decrease VIS complexity - faster VIS compile times) though be aware that only world brushes 'block visibility'.

I wonder... do you ever read the Valve wiki? Do you look at file extensions? Do you google for program names and functions?

These things really aren't that hard to find out if you read the right documents (and those aren't hard to find, either).

In other words: a little searching and experimenting solve a lot of questions.

Never played DoD nor DoDS. Looks interesting, but I'm not into multiplayer games that much so I'll just stick to what I'm mapping for - HL2DM. And I don't play that much either...

Ever played Brothers in Arms? I think you'll like it a lot.

Basically, instead of giving the player (most) choice at a higher level, where combat is just a part of the gameplay next to puzzling and exploration, you want to give the player (more) choice within the combat?
Interesting. Looking forward to that demo.

Welcome back.

As for your idea, it's a good idea to use paragraph titles now and then and for such long texts, a short overview or conclusion wouldn't be too bad either. I mean, I can't really say what that was all about after a quick scan. Yeah, a 'different gameplay mode', but what specifically?

Using a func_rotating is an easier way to get something to rotate.

But for best effects, modelling is the way to go - animating them allows for more interesting patterns than simple rotations alone.

A 3DS Max-like movement handler would be pretty cool for dismaps too.

I assume Doom 3's patch mesh creation is more like modelling than the traditional brush approach?

Expanding on what Habboi said, I've always found it annoying that the other non-dismap sides of that brush become invisible. You'd have to delete the dismap to get the brush visible again to put more faces into dismaps then.

Luckily, there's a few dismap related buttons in the top button panel, and one toggles the visibility of these faces. Made me happy when I found out.

A guy at my job played a trick on me. He put some tomato juice and water over his hand, threw the knife he was cleaning somewhat in my direction and struggled toward me, his hand at his stomach. At first, I was confused - nobody is that clumsy to hit himself in the stomach - but then a girl (they were all in the complot...) ran towards him, shouting I had to call emergency and whatnot.
Now I'm no good with the interal comm system so I stood there, dazed... and then he stood up, laughing at me.

Then it suddenly hit me it was April first...

Evil colleagues indeed. Evil.

Yep, it's really that easy.

Displacement maps aren't brushes in the traditional sense. Below the surface, brushes aren't that solid either. They just exist of several surfaces, and since convex surfaces and volumes are much easier to work with, it's natural to choose some restrictions for brushes.
And rendering surfaces in a batch means less overhead for the program so dismaps are a blessing for both level-designers and programmers.

Gamedev.net had a good one, too. The whole site front had the appearance of Flipcode, another (now dead) big game development community site. Fun stuff.

Valve had to do that yesterday: "New HL2DM game mode released! Seagull hunting competition!".

Oh well...

<Slaps Captain P for not editing his post! ZOMG!>

Editing does not revive. Slap!

"I've got a present for ya!"

"Keep em comin!"

"Unit reporting!"

"Engineering!"

Those were good. Simple but good.

Perhaps you've placed it (partially) inside the table? What models did you use and what game are you mapping for (CSS physics are less accurate than HL2 physics)?

I wonder how many hits that page has gotten by now. Pretty clever joke with all the hype around his maps.

Project readjusted due to corporate pressures.

Requirements of employment necessitate alterations in project structure, and since funding now obtained from major, franchise-based development studio as of 2006-04-01:

I think he got hired... to whoever was the highest bidder.

We'll see. We'll just see.

.rmf is the format Hammer uses, it stores other information like the camera's and visibility groups you're using in Hammer. Sending the .map file is good, if not better - it's smaller to start with.

It's indeed some new .dll's that come with Steam, no render settings or whatsoever that do the trick.
I believe there's still an old article about it on the VERC. Ah, here it is. Note that that article never got updated since 'new tools got available'.

Uploading your .rmf is simple - zip it in and if it's under 2 MB, you can upload it to this site directly in the map vault.

The reason I think that would be a good move is that you're still having very long compile times and optimization guides, while usefull, may not directly provide the insight gathered by years of experience.

Interesting, if not intrigueing, style you're going with. Those curved ceiling beams do feel odd though - it feels 'impossible' with that stone texture, wood would fit better. But, these are temp textures so oh well.

The map is somewhat dark and I assume that's by choice, but personally I prefer lighter maps, things set at daylight. They just play 'happier' for me somehow.

And yet another thing, which I think Poison Garden suffers from too: small, steep walkways. Those don't look too good for navigation and moveability to me. You may also want to avoid using the same texture of that floor on the wall so close by - it's hard to discern what's actually a path and what not. Don't want to confuse the players in a hot action zone, right?

Well, besides the need for optimization (hey, perhaps you can upload your current .rmf to the problems vault so some of us can take a look and give you some specific tips for that) you could also use the Cordon tool to compile only a part of the map - handy when you just want to check a small part you just modified.

Now I have heard stories about people losing the rest of their map after cordon compiling (as far as I know the cordon tool determines what Hammer writes to the .map file). Personally I have never had trouble with this, but it's one of the reasons to backup your map now and then. I usually save my map after every major change, resulting in a long row of maps as 'mapname_01' up to 'mapname_32' and the like - usefull in case something goes wrong but also when you want to look back at your progress and such purposes.

@bratty: Limited one.

Afaik you need to restart a map after building cubemaps. The cubemaps are embedded into the .bsp and since the map is already loaded into memory while you build these cubemaps, changes are not reflected untill you reload the map.

That isn't true either, Strider. Not if you want some good materials as opposed to 'programmers art'.

Well, technically it's pretty easy to compile a model or material and personally I find creating meshes not that hard either, but it's the texture art that keeps me back the most so far.

Why match the originals map layout exactly? You're working with a different engine which allows more and sometimes different things. Besides, changing things could improve them (though I definitely agree that's not an automatic result).

Well, for the walls, using some paintings and such could help, and having some papers or other small props lying around on the floors might do the trick...

Several materials reference env_cubemaps for their reflection, so I think it's quite obvious you're getting errors when your map doesn't contain any cubemaps. Execute the 'buildcubemaps' command in-game to build a default one (which uses the sky textures) and restart the map.

What's wrong with starting a thread for this? It'll get much more attention than in the map vault and at least here you can format posts properly...

As for the map, from the screenshots it looks interesting. The outside certainly has some unique parts to it, and that's a good thing to make the map stand out.
It does look a bit rough at some places though, caused by some blocky brushwork. Most indoor area's feel a bit empty - as if the area's are too large, too much repetetive things going on (all those computers and light fixtures on a row) while the floors and walls are otherwise quite empty. Carefully placed props could break it up a bit but I think those area's should be made a little more compact. They're a bit darkish for office rooms too, I think.

I'll take a run through this to give some more specific feedback.

And as Capn' P said, wally converts bmp's into 8 bit when you import them, so they will lose a little quality if you made your textures initially in 24 bit or higher.

Not exactly what I meant to say. What I mean is that Wally converts pretty good - you'll notice a little loss perhaps but that's only normal. Especially Paint is horrible for this, as it simple picks a standard pallette and remaps every color to the closest one in that pallette - with ugly results. Wally creates a pallette that fits the image as good as possible to minimize quality loss.

I would certainly use 24-bit image files as source files - it's much easier to work with than with 8-bit images. Working with 8-bit means you'll have to stick to a certain pallette beforehand, while using 24-bit means you're free with the colors you pick and a fitting pallette can be created in the end.

Using more than 8 wads should be harmless, but in case of trouble is very suspicious. On top of that, from a designers point of view, a map doesn't need that many anyway - it would certainly become very inconsistent if you'd use all of these wads.

Don't use cached.wad in any case, it's a worthless .wad for textures. Look at the ones you think are usefull for your map (not necessarily halflife.wad, depends on if you like these textures or not). It's best to keep the amount of .wads as minimal as possible as any .wad loaded into Hammer at the time of saving the map will be seen as necessary by the map. You don't want your map to be unplayable because you forgot to exclude a .wad file nobody else has (I couldn't play it for example, because the cstraining.wad file isn't in my valve folder but in my cstrike folder).

The .pts file is not important, it's the .bsp file that it's all about.

The map itself looks fine - there's little to go wrong in such a map. If removing the unnecessary .wads doesn't work, could you post your Hammer config?

2tylergig: if you could post a screenshot about what you really mean, it could clarify a lot.

I've had problems with my textures looking messed up because I used somewhat odd dimensions - 64 x 48 or 24 x 32 and such. I'm not really sure what those dimensions were, but they may not all have been powers of two...

Then you may have trouble converting your images to 8-bits, but Wally handles that quite well (unless you use something like Paint for that)...

So, some more information is required here if you want your problem solved.

People post foreign languages here all the time. I've seen quite a few threads with scattered Swedish and Dutch.

Dutch. Ahem.
At least those languages use ascii characters. You'd need unicode or such for Chinese, right? How exactly does that work on their systems? Looks like quite a hassle to me with that many characters...

I'm not into HL2 modding books, as I believe I can get any knowledge I need pretty fast through on-line tutorials, articles and communities and I already know a great deal so far, but if it's a good one it'll certainly help you up to speed a great deal. Good idea if you don't want to spend years of experimenting and learning before getting productive.

I'm reading some game programming books at the moment and those offer a lot of insight in professional game programming - definitely things I would never have dreamed of anytime soon.

There's no DM Hammer - it's the game you've set before you start Hammer that determines which content it loads. At the bottom of the Source SDK menu you can set what game to map for.

As for CS: S having more 'custom content', every CSS player has that content - it has it's own .gcf files and all.

As for player_weaponstrip, it seems to be a Source entity, both used in HL2 and CSS. You can check this site for entity references.

I'm thinking in that direction too - some wrong file reference or such. However, you can still fill in names manually if you have to.

What happens if you open the model viewer from the SDK menu, or from the sourcesdkbin folder?

Nope, FF and XP don't make me see anything else than ?'s, except for some words then...

But that's because you're spoiled, Haz. You know it.

One word: models.

Reminds me of one of the Unreal 2 levels, the one in the organic planet. Going down to cellular level, it'll certainly allow very interesting looks, but to get the most out of it it'll be very difficult. I'd say use Source, too. But oh well.

I agree with Tycell that using veins and the like is better, but some jumping puzzles a la Xen, with cells instead of floating platforms could be interesting. Being so small within a cell is going to be difficult for the simple reason that bsp-tree's are built to handle levels you can cut up into various spaces. Such a large, free environment would certainly limit the amount of detail and overall size...

And usefull that program is - autodetect, include and done. All custom stuff gets included.

I disagree. They're usefull as a subtle form of advertising. I put a link to my portfolio in my sig on any forum that allows it and I believe that's one of the ways my site gets its traffic.

The problem is, some people just abuse it with their images. I think limiting the amount of characters, or disabling images, or both, works well to prevent that.

Looks like a general game forum to me, not really a community site like TWHL. They use way too large signatures bytheway!

You can't put dismaps into entities, indeed. It's documented bytheway.

Strange. You're sure you didn't put the new stuff into a visibility group and had it hidden while compiling?

I strongly advise you to get used to doing normal (or fast) compiles every now and then. I believe you would've spotted this problem much earlier if you had done so.

Well, after taking a quick look at the map, I can see some troubled things that greatly increase the compile difficulty. I haven't compiled myself, but these are things I learned over time to keep compile times down and work more tidy.

1. Take those hills for example. They're nice, but cause a lot of extra work for the VIS process. Make them func_walls to ease this process - the same goes for cylinders and other small or complex brushes (like all of that arty statue). Unless these objects hide other area's behind them (as in, a great wall or building or such) or are used to seal off the map, such objects are best made a func_wall. In case of cylinders this also saves you some polygons in-game.
2. The 'splintered' arch somewhere in the lower left corner of the map. Horrible brush-work, I assume it's caused by carving (evil tool when used with cylinders). Use the arch shape instead. It's best to avoid brushes to overlap each other too, maps quickly become hard to work with otherwise.
3. Not really something that will optimize compile times, but certainly will be helpfull along the way (to prevent leaks to occur and to make handling larger maps easier) is to stick to the grid. The larger, rough architecture is best kept at the grid lines so you can make sure there are no leaks and then putting in the details with smaller grid sizes can safely be done.
4. The use of sky brushes is sloppy. You put one brush on top of it all but there's still a lot of area's connected to each other where that isn't needed. Put more sky-brushes on top of those low buildings to divide the map into more smaller area's, and try to minimize the visibility between those area's for performance sake.

As for compiling through Hammer, there are tutorials here to help you set it up correctly. Batch compiling works fine too, though, so that's a matter of taste.

As for the map itself, the first thing that strikes me are the horribly long corridors. I'm sure those will not be good for gameplay... the plaza at the CT start looks nice, with some interesting use of height difference and such. Overall, most area's are probably too large and lack cover. I haven't playtested myself and I'm not a die-hard CS player, so I can't go into much detail here, but these are quite general rules for fast gameplay.

Saying that you don't have it won't give you any, either...

Words sometimes are self-forfilling prophecies - you say you can't do something, and that prevents you from even trying.

By making them normal brushes, not entities... There's a 'To World' button for that in the right panel, next to the 'To Entity' button...

As for hiding all entities, take a look at the side panel in Hammer, there's a block that deals with visibility groups there. Go to the tab that contains the auto-groups or however they're called, and untick the entity groups.

I take my inspiration from reading books, playing other games, just walking through school or some other casual activity. Music sometimes, too.

What's also interesting I think is how to handle this inspiration. What I found usefull is working out a theme a bit into something workable, and then if I can't use it straight away store it in some form (usually sketches, sometimes some test maps as well) for later use. I've got several themes and idea's around so when I'm done with Mudanchee I'm can simply pick the best one of them and get going again immediatly.
Don't throw away something because you think it's bad - perhaps if you come back at it later you'll see more possibilities to turn it into something good.

//CP - Inspiration handling, 1:1

Overall, your themes aren't really my style, but you work the out graphically well and that's a good thing.

I did notice one thing though and that's the navigation and certain gameplay aspects in your maps. Poison Garden had some small and icky corridors, some obstructing little brushes (holding ammo, those thingies) and was generally a bit too close-quarter I think. There were those small dead-ends in that long room with the pipe running through it - those 4 places did hold ammo but I don't think that's enough reason for their existence. And the RPG 'trap' was downright annoying...

Having that said, I think you've got stuff to work on. Not meant in a bad way but your themes deserve a better gameflow. Keep it up.

Hmm, no_decomp and locked texture? What exactly do these things do (in a technical way)?

Don't delete these objects - they're simply the entity most close to the leak usually. That Leaks article explained it (but indeed not very clear - I've added a small part to clarify this now).

You should find the place where the void connects with your playable area. Look in the vicinity of the mentioned entity, hide all entities and look for small gaps between brushes. Works for me every time. Alternately, loading the pointfile in-game may lead you to the leak, too.