User talk:Robin Walker: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
(About You)
(About You)
Line 1: Line 1:
Instead of all these 'See Also's, how about an 'AI commands' category? --[[user:TomEdwards|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. -- [[User:Robin Walker|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. --[[user:TomEdwards|TomEdwards]] 03:32, 16 Jul 2005 (PDT)
----
Hey Robin, would you happen to know if valve is planning on changing the [[VERTEX_BUFFER_SIZE]], or is it a hardware limition?-[[user:Zevensoft|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? -- [[User:Robin Walker|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 [[User:^Ben|^Ben]] 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.
'''[[User:Fractal|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? --[[user:TomEdwards|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". -- [[User:Robin Walker|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.
:-- [[User:Robin Walker|Robin Walker]] 20:56, 25 Jul 2005 (PDT)
::[http://www.btinternet.com/~varsity_uk/maps/gameplay_tester/gameplay_tester0018.jpg 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 [http://www.btinternet.com/~varsity_uk/maps/gameplay_tester/gameplay_tester0020.jpg 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. ;-) --[[user:TomEdwards|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.
::: -- [[User:Robin Walker|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 [http://www.btinternet.com/~varsity_uk/maps/gameplay_tester/gameplay_tester0001.jpg 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. --[[user:TomEdwards|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.
::::: -- [[User:Robin Walker|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. --[[user:TomEdwards|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. --[[user:TomEdwards|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. -- [[User:Robin Walker|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 [[MINERVA|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_static''s 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.. :-] --[[User:Cargo Cult|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. -- [[User:Robin Walker|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... --[[User:Cargo Cult|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.
:::-- [[User:Robin Walker|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! --[[User:Cargo Cult|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. -- [[User:Robin Walker|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! -- [[User:Keats|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.] -- [[User:Keats|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  --[[user:InvaderZim|InvaderZim]]
I believe you're referring to [http://www.chatbear.com/?P881959 this question].  If not post on [http://www.chatbear.com/?P881959 the forum], as this is just a basic SDK question. --[[User:Bloodykenny|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 --[[user:InvaderZim | InvaderZim]]
::To add chapters to the New Game menu, you need to add chapterX.cfg files to your <code><mod dir>/cfg</code> 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 <code><mod dir>/scripts/ChapterBackgrounds.txt</code> file. Take a look at the HL2 versions of each of these files, and it'll be pretty self explanatory. -- [[User:Robin Walker|Robin Walker]] 16:26, 8 Aug 2005 (PDT)
::Thanks Robin I got it setup now :) --[[user:InvaderZim | InvaderZim]]
== Firetarget ==
What's this "firetarget" command I found while digging through the console do? --[[User:DmD|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? --[[user:TomEdwards|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>. -- [[User:Robin Walker|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? --[[User:Zevensoft|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. --[[User:Pon|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? --[[User:zombie@computer|zombie@computer]] 14.36, 24 Aug 2005 (PDT)
----
Can you help me with [http://developer.valvesoftware.com/wiki/Simulated_Bullets this]?  The error is on the talk page&mdash;'''[[User:Ts2do|ts2do]]'''&nbsp;<sup>([[User talk:Ts2do|Talk]]&nbsp;|&nbsp;[mailto:tsdodo@gmail.com @])</sup> 10:59, 23 Nov 2005 (PST)
----
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.
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.

Revision as of 22:03, 13 January 2006

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.

Retrieved from "https://developer.valvesoftware.com/w/index.php?title=User_talk:Robin_Walker&oldid=20881"