Hmm, it appears that if the test boolean is false (second to last param), it won't draw either.
Anyhow, the code I posted works for me. It should work for everyone. You're running the game with -dev right?

Awesome tool! Well done!

If either the start or the end vectors are null, it won't draw. Try printing the vectors to console and see if there's adequate distance between the vectors.

Originally posted by The Fish:

Perhaps a thing to think about for future titles? I think it's a bit much to ask for for an update.

Adding a survivor bot is as easy as IVEngineServer::CreateFakeClient().

Originally posted by shotgunefx:

I thought .pos was where the trace hit, but doesn't appear to be the case. I just had a prop_dyamic scan forward and down, setting it's origin to .pos, it detected what it was hitting correctly, but not where. It just kept moving a large amount in the opposite direction of the trace. I'm sure it's something I'm just not understanding. Also, can't get DebugDrawLine or DebugDrawLine_vCol to draw anything

The "pos" is where the trace hits. You need to set the "start" key to the entity's position and the "end" key to wherever, and after TraceLine() the "pos" key holds the collision point of the ray, as you already know :) Unless you set the "ignore" handle to the prop, the ray will hit the prop. If you're trying to hit some direction from the prop, you can add a scaled forward vector to the start position (to find an end position). For dynamic props, the forward vector never seems to change because its base angles don't change, so we'd need to use .Left() as well as .Forward(). By negating we can end up with Right and Backward. All in all, I don't think it's worthwhile to emulate anymore. Maybe when Source 2 comes out, we scripters will have nearly full access to the engine (in L4D3 maybe hehe) through the VM.

Anyhow, the old vscript documentation is very, very poor for some of those functions. After a quick scan of the SDK, I found this in util_shared.h:


Therefore, this code should work in your nut script:

What I need is a callback to fire every game frame. Update() fires once every second (which is too slow).

The idea you posted would not work if the entity were to go, say, downhill. Nor would it work if there was a car, fence, or something we had to jump over since the NPC would have no idea if there is anything valid beyond the point of collision.

A modified A* pathfinding works nicely if everything was made with dynamic/physics props. Maybe that combined with radial raytracing might work.

Anyhow, it's still not easy as just creating another SurvivorBot and forcing commands on it with Valve's new functions. I wish there was a function to add a survivor bot. Sigh...

It would speed up Squirrel by 40%. That's a lot :)

And you're right-- it's next to impossible. Yet, how cool would it be to have an entity that can "follow" you around or maybe an entity that can you can talk to and have it animate in a way? You can pull those off with buttons but it's not easy without scripting (unless you parent it, which in that case just looks fake). The A* pathfinding seems to be a bit too much for a bytecode interpreter, but maybe I can somehow make use of the nav. I remember Valve added a nav function recently.

I used practically every new function Valve added. That InjectThink() ended up being super helpful.

I agree. A confirmation message after choosing a name would be great (so we don't miss-click).

That is indeed interesting. My suspicions were confirmed; Squirrel is kind of slow. However, in a real-time scale, it's still blazing fast for all of its extra language features. There are JIT compilers available for Squirrel. If Valve doesn't have one set up, they should get one. Anyhow, the calculations are all mathematical; for example, pseudo A* pathfinding based on entity locations and trace rays. I'm trying to create a fake NPC class, but of course, I figured it'd be next to impossible when the math started requiring complex loops. Sigh... I'm gonna have to put VSLib on hiatus (at least until the next VScript update).

[patiently waits]

Does your VM use a JIT compiler Valve? I profiled my code for my machine, and doing simple things is ridiculously slower than it should be had the same code been written natively or in Lua. Yes Squirrel has ref counts but simple loops shouldn't lag the hell out of my i7 processor.

Originally posted by The Fish:

4/3? :P

It was a couple of hours before 4/3, at least in central time. I would imagine Valve's location to be an hour behind on top of that, when compared to CST.