User talk:Robin Walker

Wiki Notes

Instead of all these 'See Also's, how about an 'AI commands' category? --TomEdwards 01:33, 8 Jul 2005 (PDT)

Sounds good to me. "AI Commands" would be a subsection of a "Debugging Commands" section, which would be a subsection of the overall "Console Commands" section. I'm not up on fancy wiki tactics, so feel free to create that structure however the standard method would be, and I'll follow it. -- Robin Walker 02:28, 8 Jul 2005 (PDT)

Just a nitpick...AI commands is a subcategory of AI, so having both as categories dupes the article's listing. --TomEdwards 03:32, 16 Jul 2005 (PDT)

Only just noticed this comment, Tom. Feel free to fix it if you haven't already. -- Robin Walker 01:10, 14 Jan 2006 (PST)

Question about future SDK features

Hi, I'm just starting to mod with source and I'm EXTREMELY impressed with it. (Especially the animation) However, being the beginner that I am, I find myself to be very imtimidated with all the outside programs (such as decompilers) that I have to download. Are there any plans to incorporate any of these necessary outside features within the official SDK? Thanks for your time! Cfive 17:55, 26 Sep 2008 (PDT)

Did you not see my reply? You don't need anything else, mdldecompiler is all you need to decompile. It's very basic stuff, can't see how anyone would need help on it. Besides, Valve aren't going to make a decompiling tool are they? Who would incourage decompiling? --Craziestdan 18:02, 26 Sep 2008 (PDT)

Yes, I saw the reply, but I was just wondering. That and I'm intensly intimidated. Especially with all the scrolling, the scaling, the rotating, it all looks so 3d! Cfive 19:50, 26 Sep 2008 (PDT)

VERTEX_BUFFER_SIZE

Hey Robin, would you happen to know if valve is planning on changing the VERTEX_BUFFER_SIZE, or is it a hardware limition?-Zevensoft

You shouldn't be hitting this limit at all. We're not even sure how you've managed to hit it. Could you tell me what you're doing that causes it? -- Robin Walker 19:55, 22 Jul 2005 (PDT)

I've only seen people hit this error if they have an extremly poorly optimised map. Try changing some of the uneeded brushes into func_details ^Ben 08:34, 23 Jul 2005 (PDT)

I'm new to mapping and having the same problem. I created a wooden floor about 10m x 10m, out of lots of small brushes , representing planks and i have thiis error when i try and compile it. rockstar91 08:34, 23 Jul 2005 (PDT)

vphysics.dll crasher

Can you elaborate on exactly what the "Fixed a rare crash in physics" was in http://steampowered.com/index.php?area=news&id=430 ? I get vphysics.dll crashes about once a day - usually they seem to occur when players pile lots of objects from the level in one big heap.

Since updating, I'm getting a vphysics.dll crash every 4 hours or so, when I used to only get them about once every 4 days. For what it's worth, prior to crashing, the physics engine usually gets in a state where objects (including some players) can float through solid walls, and physics has no effect on some objects, as they get stuck in mid air.

Ah this crasher seems to be a consequence of "#2 Physical Mayhem" as listed on http://forums.steampowered.com/forums/showthread.php?threadid=248425 !

Well Jay explained what the "Fixed a rare crash in physics" was here http://www.chatbear.com/board.plm?a=viewthread&b=4991&t=942,1111717336,22797&s=20&id=892119#29 but per the steampowered.com board posts, nothing has been fixed for the "Physical Mayhem" issue.

Fractal 09:28, 11 Dec 2005 (PST) wrote: Good news, relating to these issues: http://www.chatbear.com/board.plm?a=viewthread&t=942,1111717336,22797&b=4991&id=894422&v=flatold&s=100

Standoff leaders

This is something I've still yet to work out, can you help? One of the events that makes a NPC look at ai_goal_standoff's Reaction to tactical change keyvalue is the 'leader moving', but I can't work out what a leader actually is in this context? --TomEdwards 13:40, 22 Jul 2005 (PDT)

The leader is the player, as long as the player is a friend. So combine soldiers won't use this at all, but citizens will, if their relationship to the player is "Like". -- Robin Walker 19:55, 22 Jul 2005 (PDT)

Combine combat

Another problem, and this is the only place I know to find an answer. ;-) I've got a setup with Combine behind a makeshift physprop barricade fending off a constant stream of antlions. The problems I've hit are:

• Sometimes the Combine don't shoot at antlions right up against the barrier. They know they are there and there is a good helping of antlion hitbox sticking above the prop (usually the upturned table) but they just don't shoot at it, resulting in their deaths at the hands of the more sensible antlions.
• One of the Combine is armed with a shotgun, and he doesn't seem to take into account the lower sling of the weapon. He unloads round after round of shells into the top of the barricade without hitting anything.

I'd have to trace into the code a bit to be certain, but there's a couple of things at work here. They may be bugs, or just side effects of the way your level is constructed. Since we didn't run into this in HL2, it's likely that we never built anything quite like this. That in itself is an important point: You can't solve problems you don't know about. So the AI code solves all the scenes in HL2, but is not necessarily going to solve anything beyond that. Luckily, it's often easy to fix the problems in your areas, due to the base AI system being powerful & flexible.

• The combine not shooting at antlions are probably having trouble seeing the antlions (i.e. they can't see the eye position of an antlion), or they may be seeing the antlions but are unable to get a shot at the part of the antlion's body that they'd like to hit. You can debug this a little by using the ai_debug_los command, which will show you all entities that block AI LOS. See if there's something blocking the LOS to the antlions. You could try putting an enemyfinder in the combine soldiers's squad that tells them where the antlions are (make sure you set the appropriate fields in the enemyfinder). Then they'll always know about the antlions existence. If they still don't shoot, then your problem is most likely that they can't see the bit of the antlion they want to shoot. If there's a prop blocking their LOS, the easiest way to solve that is to turn off the prop's Block LOS setting. Unfortunately, the only way you can do that without changing some code is to change the Prop Data of the prop model and rebuild it. If you don't mind changing code, it's a trivial bit of work to add another spawnflag to prop_physics/prop_dynamic that turns off Block LOS. Use the ai_debug_los command to check to make sure your setting worked. If that still doesn't fix it, or if there's nothing blocking LOS between the combine soldier & the antlions, let me know and we'll move on to less likely things.
• The shotgun combine sounds like he is doing what you think he's doing (i.e. not taking into account his muzzle position). This would be a pretty easy thing to fix AI-wise, but the net effect would be that he'd run around the barricade to get a clear shot at the antlions. Fixes that avoid that would be to change his anims to raise up the shotgun, or to lower your barricades. Not necessarily easy, but straightforward.

-- Robin Walker 20:56, 25 Jul 2005 (PDT)

Here's what it looks like right now (the concrete slab behind them is the uncompiled entrance to the area). The antlion is just coming up to the point where he isn't shot. It's clearly blocked LOS, but wouldn't unblocking it only make them shoot at the metal? You can also see the shotgun guy with his muzzle pointed into the bedframe.

The problem is a little clearer here: the Combine would only shoot when an antlion moved into the gap between the two props. The rest of the time nothing happened except for everyone shuffling about a bit.

It's also slightly ironic that you shouldn't have made something like this when the entire scene is lifted straight from one of the concept sketches in Raising the Bar. ;-) --TomEdwards 02:25, 26 Jul 2005 (PDT)

Ok, so it definately looks like its because the combine soldiers can't get a LOS to the enemy antlions. There are multiple ways to fix this:

• CODE: Add a new spawnflag to the prop_physics, which turns off Block LOS, and set that on the props there.
• CODE: Tweak the position in the antlion that the combine soldier is trying to see to calculate LOS. This would have repercussions on other levels in your game, and may break existing, working levels.
• MODELS: Rebuild the prop models you're using there, changing their Prop Data so that they don't Block LOS. This could also change AI behaviour in other levels where those props are in use.

-- Robin Walker 12:58, 26 Jul 2005 (PDT)

Well, all three of those are beyond me. I'll have to make do. Just out of curiosity though, on the second point would it be possible to make the Combine calculate LOS using ALL areas of a model?

The shotgun problem on the other hand has solved itself!

And one other quickie: is it possible to disable the APC firing missiles? They keep turning a tight circle in the air and hitting the barricade area instead of antlions. --TomEdwards 13:57, 26 Jul 2005 (PDT)

When deciding how to do AI LOS checks, you need to figure out how much CPU you're prepared to spend. The next obvious step up would be to have the combine soldiers trace to each of the corners of the antlion's bounding box, but that's a bunch more traces. It's always a tradeoff between how smart you want the AI to be, and how many NPCs you want to be able to have in a scene, because you always have a finite amount of CPU. Of course, nothing in HL2's AI prevents you from changing the tradeoffs in your mod. So if you'd like fewer NPCs, but with better LOS checks, it's an easy change for you to make.

To prevent the APC firing missiles, you need to stop the NPC APC driver (npc_apcdriver) from doing so. The first spawnflag on the APC driver is "No Rocket Attacks", which will stop him firing the APC's rockets.

-- Robin Walker 10:38, 27 Jul 2005 (PDT)

OK, thanks. Turns out I was using npc_vehicledriver, which was why I couldn't work it out. --TomEdwards 11:17, 27 Jul 2005 (PDT)

Just had a thought: might it be possible to add sequential LOS checks, so if the first traceline isn't clear a second one to another area is run, until an opening is found or all the areas are covered? That would probably still be more CPU, but streched out over time and with a conservative number of check points it might be manegable. --TomEdwards 05:14, 3 Aug 2005 (PDT)

Definately possible, and if done correctly, wouldn't really use any more CPU. The simplest would be to make the NPC have a list of positions on the target to trace to, and have it iterate through the list, tracing to a single position in the list each frame. An easy change to make in your mod. -- Robin Walker 11:44, 3 Aug 2005 (PDT)

Engine Limits

You seem to be a sensible person to ask questions, so here goes. I've been building a rather large map for a few months now, and it appears I've just hit an engine limit - thanks to loads of scripting and so on, the map's entdata is now at 94.7%, or 'VERY FULL!'. The next highest is physics, at a mere 37.7%, and I'm pretty sure I know how to optimise that (by making many prop_statics non-solid, etc.) - while my map will be easy to split into two parts, I'm wondering about the best way of reducing the entdata load in future.

For instance, will making entities' names shorter help (I do tend to be fairly verbose in the naming)? Reducing the number of static props? AI nodes?

Any help would be greatly appreciated.. :-] --Cargo Cult 15:04, 30 Jul 2005 (PDT)

Ent data is the entity data block, and it's not something you really need to worry too much about until you actually go over it. Many of the shipped HL2 maps show up as 'VERY FULL'. The easiest ways to reduce the amount of ent data you're using is to shorten entity names, remove names on entities that aren't ever being targeted (i.e. don't actually need a name), change entity logic to reduce the number of entities required (you can often rework complex entity structures to reduce the number of entities you're using), reduce the complexity of your AI nodegraph, and so on. If you have groups of entities being copied around the map, point_templates can be used to only have one copy in the map and instance it in all the places you want it.

I can't remember off the top of my head whether or not you can increase the ent data lump size in a mod, so I'll look it up when I get back to work on Monday. You shouldn't need to though... it's unlikely you've actually filled the ent data lump entirely with necessary data. -- Robin Walker 16:57, 30 Jul 2005 (PDT)

Thanks for all that - as a result I'm now going through my map, pruning things as necessary. I had soldiers named things like powernode-1-assault-2-soldier-1, so it's not surprising I ran out of space!

When I've finished, I think I'll collate a lot of this information into an optimisation article. Most existing articles seem to concentrate more on graphics and networking load rather than single-player stuff. Anyway, thanks again... --Cargo Cult 08:15, 31 Jul 2005 (PDT)

An optimisation article sounds like a good idea, but ent data shouldn't really be on it. There's pretty much no point to trying to reduce your ent data unless you've actually gone over it. It's just a chunk of text, so it takes up very little memory compared to everything else (models, sounds, textures, etc). You won't get any significant performance improvement reducing its size either, unless you manage to significantly reduce the number of entities you have (reducing the ent data block without actually modifying the entity count isn't really going to do anything at all).

Oh, and I checked out the ent data limit, and it turns out there really isn't one. VBsp is warning you that it's "full" because it's getting close to 384k, which was a size we considered a reasonable amount of ent data. Even though it uses 384k for reporting, it doesn't use that as a limit. It will go ahead and allocate as much memory as you need.

-- Robin Walker 10:29, 2 Aug 2005 (PDT)

Ah, it's merely a guideline rather than a hard limit - I did a lot of mapping on the original Half-Life, so I'm paranoid about hitting limits. Thanks again! --Cargo Cult 03:36, 3 Aug 2005 (PDT)

Direct VGUI drawing & AA issues

I don't know how familiar you are with VGUI, but I was told you're very helpful for programmers so here goes. For a mod I've been developing, I'm making a custom GUI. Most of it is finished, but I have one general issue I fail to isolate. I paint my HUD elements directly on the corresponding panel's ISurface using e.g. vgui->surface()->DrawPolyLine(...) in the element's Paint() function which I override. This all works a charm until I turn on Anti-Aliasing in the game's options. All the lines drawn with that call get AA'd as well, making them all blurry. I noticed however that the default VGUI elements do not suffer from this. I was wondering if you knew how I can prevent a surface to be subject to anti-aliasing, regardless of the user's settings? Thanks a lot for any help you could give. -- Keats

AA is a framebuffer operation, so there's not really any way you can turn it off for your lines. It's edge triggered though, which is why you don't see the VGUI elements being AA'd: They're not lines, they're textures, and the edges of the textures would be visibly AA'd except that the edges are fully transparent. If the lines you're drawing could just be a texture (i.e. they're static), then all you have to do is use a texture instead, and you'll be fine. If they're dynamic in some way, your only real option to avoid AA is to render them to a render target, and then draw that render target on the HUD as a texture, which would have its edges AA'd, but not the lines within it. That's a bit of work though, so make sure it's worth it. -- Robin Walker 11:10, 2 Aug 2005 (PDT)

Interesting information, and worth a lot, thx. The hud elements are dynamic in that they change size depending on the screen resolution, but moreover they have a zoom in/out effect (zooming in on the minimap, going to the spawnmenu, etc). I went with the texture-based approach first, but when the engine rescaled the textures I got nasty artefacts as well. But the last option is a good one. [It can not nearly be as much work as what I've done on the HUD already so far; and work never scared me off :).] Thanks for the help! -- Keats

I'm trying to use textures in stead of drawn lines for the static HUD elements now, and I'm stuck on a related problem. My texture consists of a semi-transparent square frame with a 1 pixel solid black border and an icon in it. When I draw it on the hud, it looks all blurry. If I set mat_filtertextures to 0, it renders sharp, so it's the texture filturing (be it *linear or anisotropic *x) which is blurring a sharp texture. Is there a way to keep HUD textures from being filtered without turning it off globally? (I'm thinking either in code or a .vmt parameter, but I haven't found any yet... they should've been better documented imo :) ). Sorry to bother again, and thanks again for your time! -- Keats 9:49, 9 Oct 2005 (GMT+1)

Sorry to have bothered you, but I couldn't get any sleep so I kept searching 'til I found the solution. Apparently setting the flag "Point Sampling" in the .vtf file solves my problem. While actually being a "lower quality" way of filtering, in this case it gives better results, since the blur is a result of more complex forms of interpolation. Of course, if there are better solutions to the same problem, they are still welcome. [E.g. I'd rather disable filtering altogether than use point sampling as a hack.] -- Keats 13:40, 9 Oct 2005 (GMT+1)

Single player level setup

ive been looking at thie page and thanks for being so helpful to people :)

okay, my question im currently fiddling with a mod for half-life 2 single player ive been trying to find how you set up the levels for the game but cant find how to when you click 'new game' i currently get a blank menu , and would like to have some levels ive made show up there help would be appreciated --InvaderZim

I believe you're referring to this question. If not post on the forum, as this is just a basic SDK question. --Bloodykenny 19:10, 6 Aug 2005 (PDT)

Not exactly my problem, the menu is setup correctly, there are just no levels to select since the mod is not aware that any exist -- InvaderZim

To add chapters to the New Game menu, you need to add chapterX.cfg files to your <mod dir>/cfg directory. The .cfg files are simply a list of the commands executed when the user starts a new game on the corresponding chapter. You can specify images for each chapter in the <mod dir>/scripts/ChapterBackgrounds.txt file. Take a look at the HL2 versions of each of these files, and it'll be pretty self explanatory. -- Robin Walker 16:26, 8 Aug 2005 (PDT)

Thanks Robin I got it setup now :) -- InvaderZim

Firetarget

What's this "firetarget" command I found while digging through the console do? --DmD 20:29, 11 Aug 2005 (PDT)

Looking at the source code, triggers it. I don't know about you, but this page is getting a little long now. How about we all give the poor guy a break and ask questions on the relvant talk page? --TomEdwards 06:32, 12 Aug 2005 (PDT)

"firetarget" is a bit of a throwback to old HL1 style entity logic, and is pretty much replaced by the ent_fire command. Back in HL1, entities had a single input called "Use". Different entities would do different things when their "Use" function was called, but in general it did things like activate buttons, move platforms, open doors, etc. HL2 added a concept of entity inputs, each which does something specific for the entity that's receiving them. Much more powerful, and also more easily understood. But, the HL1 "Use" concept is still there for for backwards compatibility. Calling "firetarget <entity name>" causes the "Use" input to be fired on all entities that match <entity name>. -- Robin Walker 10:20, 12 Aug 2005 (PDT)

MAX MAP BRUSHSIDES

Is this 65536 limit because of the 'int' variable type used in the BSP19 format, or does it go deeper than that? Would I be able to alter the VBSP compiler to allow for more brushsides? And will Lost Coast bring any new features apart from HDR to the HL2 engine, like parallax shaders or dolby digital support? --Zevensoft 20:04, 18 Aug 2005 (PDT)

Someone should...

Create a Q&A page on this wiki, and steal all the things from this page lol. --Pon 00:54, 24 Aug 2005 (PDT)

Glview bugs

Hey Robin, could you perhaps look into some bugs in the glview.exe code? There are some rather annoying errors in glview.cpp. The main thing is that the command line parameters are in a different sequence than they are according to vvis.exe's "too many portals on a leaf"-error, and that glview opens the portalfile by searching for the first dot in the glfile path and replacing everything after that with .prt, but this method doesnt work for all the people who have a dot in the pathname (e.g. in the steamname). I guess strrchr would work better? also, glview seems cabable of a lot more than is mentioned in the docs (ReadDisplacementFile, ReadPolyFile). Can you elaborate as to what these do? --zombie@computer 14.36, 24 Aug 2005 (PDT)

Simulated Bullets

Can you help me with this? The error is on the talk page—ts2do ^(Talk | @) 10:59, 23 Nov 2005 (PST)

Sure. Which bit do you want help with? -- Robin Walker 01:10, 14 Jan 2006 (PST)

Aussies in the Industry

Hey, I couldnt help noticing that you had an Australian Accent. Im curently doing Multi-Media Design at University of Queensland and im just woundering how you got into the big business. -- Scarecrow

I made a mod called TeamFortress with John Cook and Ian Caughley. After we worked on it for a couple of years we joined Valve in Seattle, where we've been ever since. Making a mod is definitely a great way to get into the industry. Not only can you show potential employers what you can do, you can also find out what working on games is actually like, and what aspects of it you enjoy most. -- Robin Walker 01:10, 14 Jan 2006 (PST)

"Making Mods with Source" PowerPoint

Robin, thanks for being in touch with the Mod community here - great to see the communication lines open. I was especially jazzed to see your recent PowerPoint "Making Mods with Source" from the IGDA Kansai posted online. Good summary of HL2 Mod wisdom.

One note - as I was flipping through the slides, I wasn't sure what some of the screenshots were meant to illustrate. You probably composed the PowerPoint for your own reference, and you know the materials so you don't need to annotate them. But now that the PowerPoint is loose on the web, it would be helpful to other readers to see something in the PowerPoint "Notes" field describing what we're looking at, and how it proves your points about Source. -- JustinHall 08:20, 11 Feb 2006 (PST)

I've mirrored the presentation at http://www.orst.edu/~holtt/ModPresentation.ppt - it can be a bit hard to find at times on the Japanese site. --Holtt 14:00, 11 Feb 2006 (PST) That link is broken now, but I found the presentation here: http://www.hidden-source.com/downloads/ModPresentation.zip --MMmaster , 29 Oct 2009

The mod presentation was supposed to serve as a quick primer on HL2 mod making, and then go into some of the ways a mod maker can make their life easier. The focus wasn't on telling mod makers what they were doing right or wrong, but instead to examine some of the decisions they make, and the risks they're taking on as a result. Here's a quick summary of the main points:

• Questions a mod maker needs answers for:
  • Why should someone bother playing my mod? What new experience am I promising players?
  • How is my mod better than the other games?
• Game design is the cheapest way to differentiate your mod from your competitors.
  • Quantity of content & Quality of content are the two most commonly chosen differentiators, and the hardest.
  • Don't use copyrighted material. The copyright owner will make you throw away all your hard work.
• Scope your game design by the resources you have. Don't grow your resources to fit a bigger design.
  • Keep your team as small as possible. More people can make things harder, not easier.
• Release as soon as possible, and then keep releasing new versions regularly.
  • Mods generate users through continual change & addition.
  • Have a plan for where your mod is going to go, instead of considering it a discrete thing that you must ship at version 1.0

Then I spent some time going through screenshots of existing mods. The point of this exercise was to get mod makers to apply some of the above points to other mods as a learning tool. The exercise was to look at each mod, and ask:

• What is the experience this mod is promising? Have we had it before?
• How is this mod trying to beat other games?

From these questions, the idea was to gain an understanding of how hard it'll be for each mod to be successful, and realise that it's the mod makers themselves who have chosen to make it that hard on themselves. Note: the focus was not on singling out mods that are making good or bad decisions, but to focus on the choices contained within each mod (since the quality of the decision depends on the resources & goal of each mod). So please don't be offended if I state that your mod is really hard to do, because I'm not factoring in the work you've actually done (if you succeeded at something really hard, great!). The presentation was also a general introduction to mod-making, so there is some redundancies due to my desire to show people the wide variety of mods out there. The slides were:

• Insurgency : Promising a realistic weapon based MP experience. Aiming to win by Quality of content. Big challenge here, because they're competing in a genre that's full of commercial products with large production teams. Will require a large team.
• Kreedz Climbing : Promising a MP climbing game. Aiming to win by Game Design. New experience, no known competitors. Probably do-able with 1 or 2 people. A good example of how competing at game design can make your life much easier.
• Hidden Source : Promising a twist on MP Team DM. Aiming to win mostly by Game Design. No real competitors to speak of. Their challenge is to ensure their twist is meaningful enough to create an experience separate from normal Team DM. Could have been done by a couple of people if it'd re-used HL2 assets. Do-able with a small team since they've chosen to create new assets instead, and as a result they're somewhat competing on Quality of Content.
• Crazy Ball : Promising a twist on MP Team DM. Aiming to win by Game Design. Like Hidden Source, they don't really have competitors, but they need to make their game design twist impact Team DM enough to make their experience unique. Re-using HL2 assets by the looks of it. Do-able with 1-3 people.
• Dystopia : Promising a twist on MP Team DM. Aiming to win by Game Design, Quality of Content, and Quantity of Content. No competitors with the same twist. Like the last two, the challenge is ensuring its twist creates a unique enough experience. The large amount of new content means that it can take some of the load of attracting players off the game design, but on the other hand, if the content isn't executed well enough it could drive people away. Will require a good sized team.
• HL2: Substance : Promising a twist on SP HL2. Aiming to win by Game Design. No real competitors. A great example of how a level designer applying the "Scope the design by the resources" rule can go off and build a mod single-handedly.
• Source Forts : Promising a twist on MP Team DM. Aiming to win by Game Design. No competitors with the same twist. Same challenge as the Hidden/CrazyBall/Dystopia. Like Crazy Ball, they're mostly re-using HL2 assets. Do-able with 1 or 2 people.
• Battle Grounds : Promising a twist on MP Team DM. Aiming to win by Game Design, Quality of Content, and Quantity of Content. Not really any competitors with the same DM style. Like Dystopia, its challenge is a mix of ensuring their design provides a new enough experience, and their content being sufficient quality. Will require a good sized team.
• Minerva : Promising a SP HL2 experience. Aiming to win by Game Design & Quality of content. Another good example of how a level designer applying the "Scope the design by the resources" rule can go off and build a mod single-handedly. Do-able with 1-2 people.
• Unknown : I can't remember the name of this dang mod. It's an HL2 DM mod where players are mostly focusing on fighting each other with combine turrets, mines, and explosive barrels. Aiming to win by Game Design, with a similar challenge to the other DM twist mods. It's a good example of a programmer applying the "Scope the design by the resources" to design a mod they could build single-handedly.

While some of the mods have a similar challenge at a high level, their risks can still vary based upon the specific designs they've adopted. For example, Dystopia's game design risk is higher than Source Forts, because Dystopia has to design & balance all new weapons as well as their nifty cyberspace stuff, while Source Forts "only" has to deal with the impact of a couple of new player tools to HL2 DM.

Overall, the point of all this is to help you look at your own mod and evaluate how hard you're choosing to make it. You can then reduce that difficulty, through tools like game design & re-use of assets.

-- Robin Walker 10:40, 13 Jun 2006 (PDT)

The turrets and mines one is Fl3x DM. --TomEdwards 11:00, 13 Jun 2006 (PDT)

World Cup

• Nice start for the aussi team! It looks as Hiddink has done it again, I think that even a draw Vs Croatia will be enough to get you past the group stages--RP 00:43, 13 Jun 2006 (PDT)

• Aussie Aussie Aussie! Oi Oi Oi! -- Robin Walker 10:40, 13 Jun 2006 (PDT)

Defiently far better than those frogs :P Might be going to Australia (and NZ) somewhere around February 07, many people from my country (Israel) have been there and has never heard a single bad thing about it. And btw (And please don't kill me for doing this :P), have you by a chance seen this mod, I was wondering what you and John Cook thinks about it--RP 11:17, 13 Jun 2006 (PDT)

Win32 Specific Data: physics

I've compiled a map that manager to "break" this limit. To wit:

Win32 Specific Data:

physics [variable] 4918262/4194304 (117.3%) VERY FULL!

Looking at the vbsp code, I see this:

Msg( "\nWin32 Specific Data:\n" );

// HACKHACK: Set physics limit at 4MB, in reality this is totally dynamic

totalWin32Specificmemory += GlobUsage( "physics", g_PhysCollideSize, 4*1024*1024 );

Msg( "==== Total Win32 BSP file data space used: %d bytes ====\n", totalmemory + totalWin32Specificmemory );

Msg( "\nLinux Specific Data:\n");

// HACKHACK: Set physics limit at 6MB, in reality this is totally dynamic (make this higher than win32 as it doesn't use MOPP)

totalLinuxSpecificmemory += GlobUsage( "physicssurface", g_PhysCollideSurfaceSize, 6*1024*1024 );

Msg( "==== Total Linux BSP file data space used: %d bytes ====\n\n", totalmemory + totalLinuxSpecificmemory );

So does that mean that I get to just ignore this? Johnsheu 18:07, 18 Aug 2006 (PDT)

It will run, yes. Many of the bspinfo "limits" are there for budgeting purposes (see Engine Limits up above). It's often the case that if you've broken a limit you might be doing something incorrectly though (i.e. setting every brush in the map to func_detail, or conversely not using func_detail at all in areas of high brush detail). You might want to check out the Optimization (level design) and Troubleshooting_Level_Design pages to see if anything there jumps out at you. -- Robin Walker 20:49, 24 Aug 2006 (PDT)

Spectator mode in TF2

Hello! I'm studying human-machine interaction at Stockholm university, and I play TF2 in a clan at the same time. And I realised, when specing a game, that you could add a neat feature to the spectator HUD. Say that I press down CTRL and a cursor appears. After that I can click the "button" in the top screen which represents the player I want to spec and then press it and instantly go into 3rd person spectator mode for that player. That would be really nice! Could it be implemented? :) -- Slicke 23:22, 4 January 2010 (UTC)

Like this! I know this is Commander view, but it's still super awesome! SiPlus 06:14, 12 July 2011 (PDT)

Mesh data

Is it somehow possible to access the Mesh data of a model to modify it? --Pfannkuchen 01:57, 5 January 2010 (UTC)