Forum posts

@I have a plan: that's Goldsource, right? Looking good!

Stress-testing Hammer a bit with a custom tool and recursive templates:I don't think I want to compile this though...

Have you tried changing the CVOXFILESENTENCEMAX define in dlls/util.h?

As for music, I have no idea what could be causing that problem - all I can say is that I can't reproduce it. Copying that gearbox track into my valve\media folder and issuing either 'cd play 3' or 'mp3 play media/Prospero01.mp3' in the console works for me. Does it fail with other mp3's as well?

These values are not hard-coded, but stored in skill.cfg, which is a plain text file that specifies weapon damage, enemy health and a few other things.

I quite enjoyed your Hundred Heinously Hidden Buttons map, but somehow hadn't noticed your Rat Hunt map. Looks like a fun diversion for the coming weekend.

But... adequate health? Just how dangerous are these rats supposed to be?

A few technical notes:

• The rat template can be simplified by removing the env_render and making the trigger_relay killtarget the cycler_sprite.
• I think it's possible to make the counter system easier to adjust. Initialize the game_counters to the total number of rats in the map, then count down (by sending an 'off' message) whenever a rat is killed. This lets you match the counter limits with their corresponding messages, so you don't need to modify other messages when you add/remove one. The initialization can be done with a single game_counter_set, so there's only one number that needs to be adjusted. Disclaimer: I haven't tested this.

A CD and manual even? You're also going to release it on-line, right?

I wonder though, isn't there a risk that you'll get a cease-and-desist letter from whoever owns the Matrix IP?

The fgd maps names like 'Luther' and 'Slick' to numerical values for the 'body' attribute. If I understand correctly then that attribute, along with 'skin' and a bunch of others, should be applicable to every entity with a model. However, the game code for barney takes direct control over this body attribute, with 0 being used when his gun is holstered, 1 when it's drawn and 2 when he doesn't have a gun, so setting that attribute is of no use - it'll get overridden immediately. The code doesn't mess with the skin attribute though, so a custom skin should be possible without having to modify game code.

I played through all of them, twice now. I'm impressed by just how much more content the other entries provided! hermanJnr.'s entry had some good surprises and cool sequences and generally worked pretty well. Burnerman56's entry had some good scenes and ideas as well, including good use of music and a few secrets sprinkled around, but relying on HL AI to stay alive long enough with so much combat is a risky thing and can result in some frustrating moments. Either way, I think both entries stuck to the theme very well, with a good balance between giving and receiving help.

I made some more notes so if any of you is interested in more detailed feedback (or if you want to give feedback on my entry), feel free to PM me.

@hermanJnr: the curved wall was done by creating a small and large cylinder, then vertex-manipulating tetrahedrons to line up with them. A bit tedious but fairly safe. The curved line was just a func_detail, so no risk of grid/leak issues. The lighting in the maintenance halls was mostly a combination of texture lights and chamfered edges to soften the transition between light and dark. I don't know how much of a difference Vluzacn's compile tools made compared to Zoner's, but from what I read it does come with some lighting improvements, so I think that helped as well.

Heh, that's cool. Is this a singleplayer or a multiplayer mod?

Almost there. Initiating wrap-up sequence in 3... 2... 1...

...and done. With less than an hour to spare. Phew.

Only 25 hours left. No pressure!

That's why I said you need to disable the countdown timer, see this post. The following changes should work (in theory - I haven't tested ):

// Always check if we need to start an auto-reload countdown:
if (FBitSet(m_pPlayer->pev->flags, FL_FAKECLIENT) &&          // Is this a bot?
    (m_pPlayer->m_rgAmmo[m_iPrimaryAmmoType] <= 0) &&         // and is it out of ammo?
    (m_flFreeammotime <= 0))                                  // and are we currently not waiting for an auto-reload?
{
    m_flFreeammotime = gpGlobals->time + RANDOM_FLOAT(1, 5);  // Then start waiting for an auto-reload.
}

// Always check if we need to perform an auto-reload:
if (m_flFreeammotime > 0 &&                                   // Are we currently waiting for an auto-reload?       <-- NEW!
    gpGlobals->time >= m_flFreeammotime)                      // and is it finally time to perform the auto-reload?
{
    UTIL_ClientPrintAll( HUD_PRINTNOTIFY, "AUTORELOAD\n");    // Show a debug message.
    m_pPlayer->m_rgAmmo[m_iPrimaryAmmoType] += 99;            // Give the bot some ammo.
    m_flFreeammotime = 0;                                     // and stop waiting for an auto-reload.               <-- NEW!
}

Tip: proper indentation of the code makes it easier to see which blocks depend on which conditions.

I don't know the rest of your code, so I can't tell whether this is the right place. I'll need to know at least in which function this is located, and in which 'blocks' it's located within that function (inside an if or else block, or part of a for or while loop body, etc.).

Either way, there is a subtle problem with this code: it will give the player ammo even when gpGlobals->time is still less than m_flFreeammotime, because only the UTIL_ClientPrintAll line depends on the if statement. This is how the compiler sees your code:

if (gpGlobals->time >= m_flFreeammotime)
    UTIL_ClientPrintAll( HUD_PRINTNOTIFY, "AUTORELOAD\n");  // Only executed if the above condition is true

m_pPlayer->m_rgAmmo[m_iPrimaryAmmoType] += 99;  // Always executed

If you want to have multiple lines of code depend on an if statement, then you have to surround them with curly braces:

if (gpGlobals->time >= m_flFreeammotime)
{
    UTIL_ClientPrintAll( HUD_PRINTNOTIFY, "AUTORELOAD\n");
    m_pPlayer->m_rgAmmo[m_iPrimaryAmmoType] += 99;
    // Both of these lines are now only executed if the 'if' condition is true
}

What you're doing is only checking if it's time to auto-reload immediately after you decided the next auto-reload time. That's like looking at the clock after you wrote down the time, but then never checking the clock again.

Don't put the if (gpGlobals->time >= m_flFreeammotime) { ... } part inside the block that starts the countdown timer.

That line doesn't start a countdown the way we humans would do a countdown. It's more like looking at the current time (which is, say, 9:30), deciding you want to go out after 5 minutes, and then writing down '9:35'. You only do that at the start - if you did that again at, say, 9:33, then you'd overwrite the original 9:35 with 9:33 + 5 = 9:38, which essentially just postpones things.

The real work happens in Think - that's similar to looking at the clock every minute or so to see whether it's 9:35 already. Is 9:30 at or past 9:35? No. Is 9:31 at or past 9:35? No. Is 9:32 at or past 9:35? No. ... Until finally at 9:35, the answer is yes, and you go out.

Computers are good at following orders, but they're not smart, so you have to be very precise with your instructions. 9:36 is also past 9:35, so a computer will happily decide to go out again. The same happens at 9:37, 9:38, and so on. Overwriting the original 9:35 with 0:00 won't help, because 9:36 is also past 0:00, so that's why you need an extra check: do I need to go outside? We people just 'know' what we want, but for a computer you really need to spell out all those little details.

You can make the code easier to understand by creating a few small functions:

void startAutoReloadTimer(float seconds)
{
    if (!isAutoReloadTimerEnabled())  // Only schedule a new auto-reload if we're not waiting for one already.
        m_flAutoReloadTime = gpGlobals->time + seconds;
}

bool isAutoReloadTimerEnabled() { return m_flAutoReloadTime > 0; }

void stopAutoReloadTimer() { m_flAutoReloadTime = 0; }

and use those throughout your code:

if (isAutoReloadTimerEnabled() && gpGlobals->time >= m_flAutoReloadTime)
{
    autoReload();
    stopAutoReloadTimer();
}

A simpler variant is to just set m_flAutoReloadTime to a really big value, like 'next year'. I prefer the above approach however, because it's more obvious that the timer can be stopped.

Starting the countdown can be done as following (you already did this in your second sample). This will set the next auto-reload time between 5 and 10 seconds in the future:
m_flAutoReloadTime = gpGlobals->time + RANDOM_FLOAT(5, 10);

Then you periodically check whether it's time to do auto-reload. This goes in your entity's Think function:
if (gpGlobals->time >= m_flAutoReloadTime) { autoReload(); restartCountdown(); }

If you don't want to start another countdown after auto-reloading, then you'll have to disable the countdown check. This can be done by adding an extra boolean variable that indicates whether the countdown is enabled:
if (m_bIsCountdownActive && gpGlobals->time >= m_flAutoReloadTime) { autoReload(); m_bIsCountdownActive = false; }
Don't forget to set this variable to true when you start another countdown.

Checking whether m_flstufftime is 0 or less only makes sense if it represents the time that is left until something needs to be done. In that case, you'll need to decrement it periodically by however much time has passed. But you're incrementing it. It's also unclear in what context this code is being executed.

I'm not too familiar with the HL SDK, but it looks like the easiest way to do this is to execute dosomething in a Think function, and to schedule that function by setting pev->nextthink to the current time + however many seconds you want to wait.

If your entity already needs to perform other work periodically, then here's what I would do: when starting the countdown, set m_flstufftime to the current time + the number of seconds to wait. m_flstufftime now represents the time at which dosomething should be executed. Then, in your entity's Think function, check whether the current time has surpassed m_flstufftime. When it has, execute dosomething, and disable or restart the countdown logic to prevent dosomething from being executed continually from that moment on.

Other notes:

• RANDOM_FLOAT's first argument is the lower bound, so you should swap the arguments in your first sample. I'm not sure why you need randomness though?
• m_flstufftime is not a very descriptive name. Something like m_flCountdownTime would be more clear.
• (while) loops are executed as fast as possible, they're not meant for code that should be 'spread across time'.

Do any of those filenames contain non-ASCII characters, such as letters with an accent or a tilde?

I was about to give the same answer, but decided to check the source code to be sure, and found that antidotes do have a function. The poison and nerve-gas damage types apply damage over time, but having an antidote will stop that effect after a few seconds. The HEV will notify you when an antidote is used.

That's HL bytheway, I don't know whether this behavior has been removed in TFC.

I'd say that both koe1's and abbadon's work looks pretty impressive. And UrbaNebula's The Core as well. And Admer456's work on terrain... good stuff.

The Half-Life engine isn't very well suited for large open spaces. It's possible to get a map like this to work, but it requires some understanding of how this engine works.

Maps must be enclosed spaces
First, HL maps must always be enclosed spaces. Whenever you see sky in a map, you're actually inside a room whose roof and wall brushes have the special 'SKY' texture. In this case, the quick and easy way is to surround the whole map with a giant 'SKY' box, but you'll likely just get long compile times and bad performance in-game. It's much better to design your map up-front as a series of rooms and corridors, where a street is just a large corridor with a 'SKY' roof and walls that look like houses. Just look at the official CS maps to see how that works in practice.

The reason for this is that many years ago, when the Quake engine was made, computers were far less powerful. They couldn't render too many polygons, and determining which ones were visible also took a lot of time. So they came up with a tool that divided maps into separate areas, and it would calculate up-front which areas were visible from which other areas. Now all the engine had to do was look up this information so it knew which areas it needed to draw. But the level-designer still needs to carefully block visibility from one area to another for this approach to be useful.

Turn small brushes into func_detail's or func_wall's
That leads me to the second point: there are lot of small brushes in your map. All of these affect this area division process, causing areas to be split up into many more smaller areas. This causes a lot more work for the compile tools and makes the process a lot less efficient. In general, you'll want to turn small detailed brushwork into func_detail's or func_wall's. And for things like that motorcycle (which looks awesome btw!) it's better to create models instead. Models can be more detailed and are easier to render, at the expense of lighting quality.

Avoid rotating brushes
I also see a lot of rotated brushes, with vertices not aligned to the smallest grid size. I'm not sure, but I think the compile tools will snap those to the nearest point on the grid, which can cause malformed faces, leaks and other kinds of problems. There's a reason why many HL and CS maps are relatively blocky and grid-aligned.

Too much detail for an open space
Finally, large open spaces take a lot of polygons to draw. Lots of small details also take a lot of polygons. There's only so much that the HL engine can handle before you'll get performance issues. In this case, I suspect that the player will never get close to those far-away houses, so I would turn them into simple blocky shapes, without any detailed brushwork.

It's a good idea to first build the general layout of a level and test that in-game. Then you gradually add more detail, while occasionally testing in-game to see how it looks and whether performance is still ok.

Yeah, what am I doing here all of a sudden?

I have been lurking a bit here recently though. Did some work for the teleportation competition a while ago, and later for TWHL Tower 2, but I didn't have enough inspiration for the first, and ran into some technical issues for the second. But this time I've got a clear picture of what I want to make, so I felt I was ready to post something.

Here's a work-in-progress screenshot:I'm going for a high-tech test environment style. The main room here is mostly done in terms of layout and coloring. Next step is to create a few additional rooms, then some scripting to get the main gameplay up and running. Then it's time for lighting and texture improvements, and maybe some finer details, depending on how much time I've got left.

I might be working on something.

To respond to the original question: in C++, you'd use std::string for things like this. Makes programming in it a little easier.

Also, string literals (the "abcdef" in your 'char *word="abcdef"') are immutable: so you can't use that pointer to modify the string it points to.

As for languages, I used to be a big fan of C++, but now that I've used it for a few years, and now that I've gotten to know a few other languages... Let's just say I'm not that fond of it anymore. I'm using Python a lot more these days. It allows me to focus on what I actually want to build, rather than making me wrestle with tedious language details first. Ah well, each language has it's strong and weak points. In the end they're tools - pick the one that's best for the given job.

I think that many internet communities die or at least shrink over time. Certainly the ones that are based on an aging subject such as Half-Life mapping. From what I can tell, TWHL's main reason of existence has shifted from being a Half-Life level sharing place to, well, a chatter-box for the regulars. Of course, that's exaggerated, but there aren't that many really active mappers around anymore, right?

And then, to keep things alive, the site gets revamped, much like what happened at Snarkpit. But the core activity has shrunk already, and a facelift doesn't change that. People didn't come to this site because it looked so pretty, they came to share their maps. They still do, but it's less than a few years ago. You can encourage that (competitions?), but you can't enforce it.

In other words, it's been a great time, but life goes on. On to new things to explore.

Sounds nice. Japanese sounds quite different from Mandarin and Tibetan (?) though. I like Tselang Lhamo more.

I actually started playing erhu a while ago. Not that I'm good or anything, but it's fun.

Looks like a map from OpFor. I think one of the first places where you get to meet those alien troopers.

Don't know the name though.

void main is not legal C++.

Not that I'm into language standards or something, and it's (imo) a rather small detail, but oh well.

Good points, m0p. I haven't seen return codes being used frequently, but they do come in handy sometimes.

@vs49688: main should return an int. And I wouldn't call your code any less complex; it's roughly the same amount of lines and a similar construction.

@The_(c)Striker: in your code, those if statements can be replaced by else-if statements. Those checks logically belong 'together' in a group, so why not link them together? Only if A is not true, go and check B, C & D. If A is true, then forget about B, C & D.
Oh, and you could link the delay to the input: if the user entered something between 2 and 4, then wait for (1000 * user-input) milliseconds.

Also, it's better to just place a breakpoint at the end of a program, rather than a system("pause") call. Right now, your resulting program will always wait for user input, whether you're running it from your IDE or not.

Speaking about years, is it 2009 yet? Or maybe, is it 2010 yet?

Kinda suitable for a thread started in 2008, I guess...

Suggestion: map an art style or form. Choose a single theme (mondrian, escher, abstract, renaissance, pixel art, vector art, origami, etc.) and create a small map that gets that theme across as strong as possible. Basically, the first thing someone should think about your mondrian-themed map should be 'mondrian'. The maps name should not contain any hints. Most creative use of the most obviously clear theme wins.

Might be a bit too texture-heavy though.

EDIT: Evil genius lairs with evil genius traps and evil genius superweapons and evil genius don't-push-me red buttons are cool.

I'd like to point out that creating decent levels and content comes down to experience and plain hard work - a lot of it. If you've never done it before, it's easy to underestimate the amount of work.

So, I'd say, start creating a few basic map layouts and get them up and running quickly. Get a feeling for how much work it is, try to determine what level of quality you'd like and how much resources you can spend on it.

After all, I'd be sad to see a lot of work go to waste because you took on too much from the start. Lack of motivation and proper leadership has killed many mod teams. If you want, you can do some research into that. There should still be various articles available on the subject of mod team management.

EDIT: Damn that coding tut, why didn't it tell me about ANYTHING being case sensitive tired -

Probably because that tutorial assumes you already know that. It's pretty standard stuff.

Don't worry, I didn't know those things either, 6 years ago.

@raver: (very nice!). Did you make those textures yourself?

@Tetsu0: nice brushwork you've got there. You may want to create models for the sails and animate them, to get some breeze in there. That'd be cool.

I've done VWO and HBO. VWO was indeed a bit long - motivation was a slowly declining curve, heh. In the end, it wasn't so bad, and I'm glad I finished it. HBO was better though: more practical, not too long. I even kinda miss the amount of spare time I had during those years.

I'm currently in touch with some Chinese students. All of them are doing a second study here in Holland. Maybe it's not so that Asians are simply smarter, but they do seem to have a more study-oriented culture. It's fun though: they practice their English with me and I learn Chinese from them.

So yeah, who needs a Berlin wall if you have a Great Wall already?

Tell me Scottie, if you can, you have destroyed so much (posters), what is it, exactly, that you have created?

Just felt like saying that.

Oh, and you do keep him away from crowbars, right?

Where?!

Yu Hong Mei & Zhao Cong - Dance of the moon.

Awesome music.

It's going to be pretty tricky, yes. I remember doing this years ago. I ended up with 100+ entities or such. trains, targetchange's, relays, invisible buttons... and I don't know if that was even completely fool-proof.

For multiplayer, I'd go for a simple platform, nothing fancy. Doors slow down gameplay and an elevator that's more often than not on another floor is just too slow for most people.

For singleplayer, it could be useful here and there, but at that point, why not use Spirit to make it yourself easier?

It really pays off.

Literally, heh.

I became a game-programmer half a year ago. Nice work, nice colleagues and free chocolate milk. Still doing some game-design and art in my spare time, too.

I'd say, take a look at some 3DS Max tutorials to find out how to set up your viewports. It sure is possible to get 4 viewports, if that's not the default setting already.

Can you give us some more information? Anything specific you're doing in that part of the map? A lot of transparency perhaps? Entity-work? Can you post some screenshots? Does this happen on your computer only or also on other systems?

I don't know what exactly could cause such sudden drops but the more you tell, the better the chance someone here will figure it out.

Depends a bit. If I were you, I'd take some time to familiarize yourselves with the Source SDK code-base, then see what things you can pull off with it. Make a list of things you'll need to do and try to estimate how much time you'll need for that, based on how easy or hard the experimenting phase was. Ultimately, you'll be the ones that have to do the programming so if you don't feel sure about it, then chances are you won't make it in 6 months.

Beethoven, 7th Symphony - conducted by Karajan.

As far as I know, that's not important as long as you don't include them in the map. At least, a quick test with the above batch file worked fine for me.

The following batch file should do the trick, when put in the same folder as your compile tools. Just drag a .map file onto it to compile it. Doesn't matter where the .map file is located.

"%~dp0hlcsg.exe" "%~dpn1"
"%~dp0hlbsp.exe" "%~dpn1"
"%~dp0hlvis.exe" "%~dpn1"
"%~dp0hlrad.exe" "%~dpn1"

If you're only benchmarking compile times, then there's no need to know about the Half-Life folders at all, only the compile tools and the .map file matter.

I just like to add something that I myself was curious about: when you edit your post, the last post time will be updated to the last time you edited a post. So, editing a post essentially has the same effect as posting another comment, so don't worry about edits not getting noticed.

One more note: personally I believe it's a good thing to clearly mark edits. Something like 'EDIT:' in front of it should do.

EDIT: As for double posting, it's merely a definition issue. Your definition differs from ours, but what matters is that in this community, posting twice in a row is frowned upon, same content or not.

You guys are using the latest version of the compile tools, right? The ones made by some members of the mapping communities (ZHLT, or whatever version is currently considered top-notch)... because the old tools are seriously outdated and limiting.

As for using multiple levels in Counter-Strike, I think you're out of luck there (and you're probably either using limited compile tools, or you're not optimizing your map sufficiently, or you're trying to cram too much into one level). I'm not exactly sure how level-changes are handled by CS - if they are at all - but it certainly would be inconvenient to wait for a level-load in the middle of a game. So don't bother trying.

Looks more like C#, not C++.

What tutorial did you look at, Spike, and what IDE are you using (and for that matter, what language did you finally decide to go with)?

Read that . You guys talk like professionals , really .

I program for a living, so yeah.

Anyway, in the forums that I hang around on nowadays, the following articles and books are occasionally recommended:

C++ Language Tutorial
Correct C++ tutorial
'Thinking in C++' by Bruce Eckel

Perhaps you'll find them useful somehow.