Forum posts

In dm_mudanchee, a natural rock-formation-heavy map, I hardly ever used it, if at all. But yeah, you're right, it depends on what you're using dismaps for.

What do you mean with 'it breaks the original displacement'? Do you want to make the other faces of a brush into displacement maps as well, without having to destroy the original dismap? If so, you can uncheck the DD button in the top button row to show these other faces. You can then make them into dismaps as you would normally do.

As for per-vertex subdivision, no, that's not possible. You can, of course, move the vertices of multiple selected dismaps at the same time using the paint geometry mode. Personally, that's what I use most of the time. Subdividing may save some time on fresh dismaps but other than that, it's not a very usefull tool.

Just popping up to say 'good work'. Because it sure looks interesting. Keep it up ChickenFist!

If you're using Photoshop or Paint.NET, you can also use Nem's .vtf file format plugins. These allow you to open and save to .vtf files directly. All that's left then is creating a .vmt file.

Go to the Source SDK entry in your games menu, right-click on it and go to properties, then select launch options. In there, fill in '-engine ep1', then start the SDK. This should make the SDK look in the ep1 tools folders.

there are only 4 members at the moment

A few skilled people should be enough for now. Larger teams are harder to manage, and if you're not sure which direction you want to take with this, then don't waste time recruiting people. Decide on a direction first. Without that, you'll easily waste a lot of time on maps that you don't really need.

If you want to join

What sort of help do you actually need in the first place? The more specific you are, the better the impression you make and the easier it is to find people.

As for taking screenshots without hud and weaponry, 'cl_drawhud 0' and 'impulse 200' should do.

Most of the maps so far have a problem with lighting. They're generally too dark and monotone. Nothing really attracts attention lighting-wise. The lack of detail is acceptable during early stages imho, but still.

So what happens when you use the nodraw texture on the unused faces rather than the skip texture?

Tip: Underneath the Browse button in the texture toolbox, there's a Replace button. It allows you to quickly replace textures on either all surfaces, selected surfaces only or visible surfaces only. Combined with the automated VisGroup system, you should be able to pull it off within seconds.

@mchappy: what properties do your entities have? Do you get any error messages and if so, what do they say?

@Habboi: The Hunter is referring to the fact that HL already had an info_landmark entity.

use dev-c++ its free and like 9mb size and its one of the best ^^ - :^^:

Actually, it's not. It's development has halted more than two years ago, and the latest version ships with an outdated version of the GCC compiler. And while it's interface is less intimidating than the various Microsoft Visual IDE's, it's also a lot less powerfull.

Anyway, @thehalflifedude: check out The Wavelength. It has several usefull Half-Life coding articles. As for a 70 MB download, is that a big issue for you? A decent IDE can speed up your programming and save you a lot of hassle, so I'd say, just download it and check it out.

And no, the Source engine certainly isn't the same engine that Half-Life uses. 'bits of early Quake code' doesn't mean 'the same engine'. After all, just look at the difference in capabilities and power...

It's been a year ago since I received that file, but I found it. Here it is: hlife_hotdog's error list.

Fast vis does less calculations and is faster to compile, but it doesn't completely optimize your map, so it should be avoided for final releases.

I don't think it's as simple as that. Fast VIS performs fewer calculations and is therefor less precise, but that doesn't always make it less effective, theoretically speaking. Now it's been a while since I've done some serious mapping so I can't tell how this difference works out in practice, but I doubt this is the bottleneck. Correct me if I'm wrong though, this is more of a theory than a proven fact.

S.O.T.E, can you fire up your map, turn on 'gl_wireframe 2' (this displays a wireframe for all visible faces, including the ones hidden behind other faces, so it gives a good view of what is actually being rendered) and take some screenshots for us? Also, how many faces are being rendered in the most problematic areas (type 'r_speeds 1' to get this info)? And, if possible, can you show us an overview screenshot, so we can get an idea of the maps layout?

Twasn't Rowley. laughing -

Oops!

See? It's been years, I tell ya!

Nope. I was just on IRC today, that's all.

The Invisible Penguin of Disappearance goes to: Captain P, for he is nowhere to be found.

Heh.

poof

Rowley asked me to vote for Best of, so here we go. I actually didn't remember much maps so I had to look through the map vault a bit, but oh well. It's funny to see all those old maps... man, it's been years since I released my first map...

Anyway:
1. Issues
Contains some pretty impressive stuff. Also some ok-ish stuff but that's ok I think. The good parts were simply awesome. If I remember correctly.
2. Half-Life: Uplink Extended
I may never have encouraged Muzzle to redo an already done map-pack, but he did it very well nonetheless. Kudos!
3. Carbaseus
I never actually played in this map but when I saw it, it's sheer size and style were pretty impressive.
4. dm_crete3
Pretty abstract texturing but neat architecture. Fairly fun to play in, too, except for a few connectivity issues. But the simple fact that I remember all that puts this one on the list.
5. Annopus
Just... nostalgia. One of the first maps I ever downloaded, and one of the few maps I've ever played in. Simple rocket-launcher fun.

I may have seen better stuff during those years but I simply can't remember. This'll have to do.

Tutorials aren't actively checked nowadays. That should change with TWHL3 however. In other words, don't panic if you don't get any reaction anytime soon.

These sort of questions are easy to test by yourself. You should get familiar with console commands like 'r_speeds 0/1' and 'gl_wireframe 0/1/2', if you aren't already. They allow you to see how many world and model polygons are being rendered, and what parts of the level are currently drawn.

Most systems nowadays can handle world polycount of 1000, 1500, if not higher. Model polygons are generally 10 times cheaper to render, so if you can, modelling a new medkit is the better option. It saves you a lot of entity trickery after all.

Anyway, if you stick with a brush-based medkit, use a func_illusionary - the player can walk through it then - and killtarget it when the player walks through the pickup trigger. That will also permanently remove the entity from the game's memory. Not that a single entity gives much overhead, but oh well.

Ah, my mistake. My approach to manual leak-hunting involves hiding all entities first, so the helicopter is probably just fine. However, you're probably overlooking several leaks since they're sealed off by entities, and these are ignored during the BSP process. Note that any entity outside the level will also generate a leak.

You've got a lot of bad habits going on in that map. There are several complex objects that are left as world brushes: pipes, barrels, carts, the helicopter, etc. This complicates the VIS process significantly. Make them entities - it prevents not only face splitting, but also volume splitting, because similar to faces, volumes can't be concave. And the more volumes, the longer VIS takes. I also see you carved out some pipes. This is risky and can lead to leaks (that may or may not be visible in Hammer). I suggest redoing them and manually shaping the brushes using the clip and vertex manipulation tool, or creating an arch and aligning the outside vertices so that it becomes square on the outside.

I would also highly recommend sticking to the grid, at least for the rough architecture. It prevents a lot of unnecessary problems, like tiny, 1-unit wide leaks. And personally I find larger brushes easier to work with, for example while aligning them.

Another note: is the map you uploaded a correct version? It looks like several brushes are missing - after taking out that skybox (which complicates the VIS process a lot too because everything between it and the levels outside is also processed), there are a lot of obvious leaks present. And the helicopter misses some brushes, too.

@Stevey: don't act childish. It's just a game after all and it doesn't apply to every server out there.

Anyway, thread locked.

Looks good to me. Smooth and easy on the eyes. Good job!

I don't like the bottom though, the sidebar stops too sudden. Minor detail of course.

Yeah, some screenshots can help, and a link to the map itself of course ;). For yourself, you can check how many faces are drawn at that point by typing "r_speeds 1" in the console. You can visualize this by typing "gl_wireframe 2" - this displays all faces that are drawn with a wireframe outline. You might want to place some objects here and there that obstruct sight into some area's from there, or simply restrict players from ever getting at those low performance spots.

I hate games that reward pure time-investment. Granted, it's people themselves who devote double work-weeks per week on that game, but a game that encourages such behaviour is simply plain wrong. Games should be entertaining or educational, some relaxing after the hard work is done, not time-suckers that keep you away from forfilling your duties.

I agree with srry: those arches don't need that much faces. CS is an older game these days anyway so you can get away with some lower detail - I mean, I would blame the engine for it, not the mapper.

Looks good, but the lighting is a bit monotone on the outside. I kinda like the architecture, looks very Greek palace-like. Keep it up.

Weapons don't literally respawn, they are teleported back to their original location when they've been moved away. Does your RPG fall down or such?

Lightmaps take up quite some space. Increasing texture scales should lower the filesize somewhat because it lowers the size of the associated lightmaps. Nodrawing unseen faces will help a bit, too. Other than that, it's probably going to be cutting away brushes and stuff.

I don't think 4.5 MB is that much of a problem though, although I don't know how easily players are put off by such download sizes.

Wavelength :: Half-Life :: Coding

Anyway, the things you want probably take quite a bit of coding, so yeah, getting a programmer interested and convincing him it's worth his time would be a good idea. Note that it isn't just providing some code: it probably has to be tailored to those models here and there, and it certainly needs to be tested beforehand.

Try using a trigger_push instead, or perhaps combined with the double door system that Worldcraft dude describes. Funny enough, it's possible to clip monsters while not clipping the player, but not the other way around...

srry is correct, you'll need to enter the relative path and name of the model.

Note that both func_furniture and func_monster have a bounding box that the player collides with, and if I remember correctly, both can be blown to gibs with explosives. In most cases that collision box is too large or too small for the actual model, so I used the cycler entity as a workaround, though it's a bit harder to use. Using models in HL is a bit hacky, allas.

Perhaps there's a way to convert your model format to something that can be compiled into a Source .mdl file, but otherwise, you'd have to write a model loader for HL2 yourself. Which I assume to be pretty hard to integrate, since the source of the Source engine isn't publicly available.

In other words: you'll either have to convert your models into the .mdl format, or you'll have to stick to Gamestudio.

You mean a voxel engine? It's been done already. Polygon-based engines are far more efficient: why keep a serie of voxels in memory if the surface they form is essentially flat? A few polygons are more effective. Polygons are also easier to handle things like reflection with, and in case you need the extra relief, you can use normal mapping techniques.

And just in case you want true-to-life graphics, think of all the art that has to be made, or the expensive technologies required to generate it. I think CPU power would be the least of your concerns.

Personally I think that as a web-design oriented site, you should have a professional looking site first, and some actual content. The site looks ok-ish, though I'm not too fond of the color scheme, and the scrolling news items are too busy on the eye. Also, the layout doesn't work well for resolutions lower than 1024x768. A shame, since the content doesn't take up that size by far.

As for asking people to register, I'd say, give them a reason to do so. Put up some tutorials and templates already, for example. I'm sure that'll help more than just advertising it.

As The Hunter said. Files in the actual folders override those in the .pak or .gcf files. Though personally, I think a mod format fits better. At least it's selectable straight from Half-Life or Steam.

Oh, if you reskinned the existing monsters, then I'd certainly go for the mod format. Otherwise players will see their monsters reskinned in any other Half-Life map as well, which could annoy people.

The solution would be to have multiple valves. But yeah, it still would make life harder for the T's (since it now takes them twice as much effort to win), so some balancing elements that make life harder for the CT's would be usefull I think.

Sounds a bit like what the Splinter Cell multiplayer modes offer. These seem to be packed with all sorts of objectives and risk factors. I read some articles about it on gamasutra.com, very interesting.

For example, in one map the defenders had only a few places to defend, which was pretty easy, but the attackers could hack a few systems through some control rooms to shut down the lights and all those things, so the defenders would suddenly be at a disadvantage. Their choice basically was to stick to the small, easy perimeter, or to spread out to try to defend the control rooms, the much harder-to-keep outer perimeter.
In another map, the attackers could blow up some valves, so an easy-to-defend room would become a mistbank, giving the attackers a good chance to sneak in.

I've had this problem a few times before, and found a fix for it on the steampowered.com forums.

Download the Source Dedicated Server (it's a small download luckily) and run it once. Then, go into the 'source dedicated serverbin' folder and copy the steamclient.dll file in it to your 'half-life 2 deathmatchbin' folder. Now, the game can find it's authentication library and you can play without being interrupted.

Good point.

The same applies to multiplayer, although a bit differently. I prefer to spread items across the map so, that it balances against each other and against the advantages and disadvantages in the map itself. This gives players a good reason to keep moving from place to place in order to stock up, or to find combat, etc. In other words: I try to create a map that continually gives players small goals to work towards to. Using landmarks to make area's easier to learn, and therefor allowing players to learn where they can replenish certain needs best, is a good idea.

Just as when dealing with brushes, you can drag selection boxes and modify them in the various 2D screens before hitting enter to select what's inside. The tool may be a bit quirky if there's an unselected vertex behind the one you're trying to drag, but in such cases it may help to select only the brushes you want to modify for that moment. Sometimes, I drag away vertices in another 2D view before moving them to their final position, to prevent this problem.

A bit of a late reply, but better late than not I guess.

@Habboi: he wants differently skinned Barney's all in the same map. Some skin replacement isn't going to cut it, allas.

@bal: I'm going to explain how to do this with Milkshape 3D. It has a 30 days trial version so you'd better learn fast.
Anyway, you must decompile both the original barney model and the custom one. In Milkshape's Tool menu, go to Half-Life and click Decompile Normal HL MDL File. Open the model and click ok, then click ok on the next dialog that pops up (leave all things ticked). You'll end up with a crapload of .smd files, a few bitmaps and a .qc file. Decompile the other model just as you did with this one, but we only need the reference .smd files and textures from that one, so untick the other two boxes.

Now open the .qc file in a text editor. It's a pretty large file, but we only need a little of info from it. Search for '$bodygroup studio'. It should contain the line 'studio "BARNEY-X_Template_Biped1"' between accolades. Notice the other bodygroup, called gun, which contains 3 lines. That's because Barney can swap it's gun bodygroup: one of the lines has the gun mesh attached to the hand, another one has it placed in the holster and the last one is empty (for when Barney dies). The soldiers and scientists use this system as well: it allows them to use the same body, but different heads and weapons. Essentially it's a modular system.
Well, the idea now is to add some other Barney bodies to it's studio group (because that contains his body). You decompiled the custom Barney and got it's reference .smd's. Find out which one contains the body (you can import them into Milkshape to view them). Give it a different name to avoid name conflicts, and add a line to the .qc file, inside the two accolades, that refers to it's filename.

Now, go to Milkshape's Tools menu, to Half-Life and select Compile QC File. Select the .qc you just modified and hit go. If everything went right, you should now have a new barney model, containing a different body, which you can select with the 'body' key that you manually add to your monster_barney entities.

Well, you decompile the original models and the custom ones, and then make sure they both use the same skeleton and animations. Then, you modify the .qc file, to compile all body parts into the same model. This may mess up stuff in-game, but you can specify what submodel combination a model has to use with the 'body' key, which you can add to your monster_scientist entity (or any other model entity) with advanced edit mode.

I'll have to look up how to do this exactly at home though.

Brain Bread simply isn't that 'big' as HL or CS are. In fact, this is the first time I've heard about it. Anyway, I assume they've got a site of their own with some documentation on their entities.

You'll have to code them yourself, or be satisfied with some custom models/skins. There's no AI plugin system for HL. With some modelling trickery, you can combine custom models with existing ones, using the submodel system, so you can have both normal scientist models and custom skinned scientists in your maps, but anything beyond that will take some programming.

You can trigger a trigger_changelevel with another entity, for example by a button or other trigger. No teleporting involved.

I think he posted a wireframe 2D view some time ago. It's that big. If I remember correctly, of course.

@Orph: how about Persian Letters?

@The_soul_keeper: I'm not sure what you're actually looking for. Does the map not fit in the grid in Hammer, or do parts of the map disappear in-game, beyond a certain distance?

env_fade.

A) So you found them already ah? Well, they aren't used in HL, so there's no entity that refers directly to them. However, you can use them with the monster_furniture entity, or better, the cycler or cycler_sprite. Fill in the path and modelname of the model you want to use and you're done - though beware, HL isn't that easy when it comes to using models, mainly because there's no truly specific entity devoted to them, unlike HL2 with it's prop entities.

B) You may want to do some Googling or asking around. I remember a few sites with some furniture and tree models and such, but no civilians or the like.

C) Perhaps, if you're easily scared off by some more complex entities. Otherwise, you'll find it a pleasure to work with, since it opens up a wide variety of possibilities.

D) The same as for the ambient sounds. As long as the sounds you want to use are within the sound folder (whether that's the sound folder in the .pak file, or the .gcf file if you're using Steam, or the actual sound folder).

Just a wild guess on your theory: did you have any entities that spanned a wide area? See, entities get rendered when their bounding box lies partially or completely within a visible leaf. Raising the sky might've caused some of such entities to fall within the current leaf (since the leaf was enlarged), hence upping the polygon count. Just a wild guess.

Do you still have the map, Orph? You could check with gl_wireframe 2 to see where those 200 poly's were coming from. That might clear up some confusion.

Of course that's possible. I'd suggest Milkshape 3D over 3DS Max or any other high-poly modelling package for this, as it contains a HL model decompiler/compiler all in itself. It then takes some fiddling with the .qc file before you recompile it. I don't remember all the stuff exactly though, and it depends a bit on what exactly you want/need.

So, what model are we talking about, and what kind of problems are you having with these submodels?