Object Selection *without modding source*?

#1 It should be possible, take a look at this thread on picking where I asked about this. In particular, if you look at what Stephen said, he does give us the nitty gritty on how to do it... should be possible to do with scripting only.

That said, I'm with you - it shouldn't be that hard to just steal the picking that's used by the editor.

#2 The trick is getting the canvas to catch the mouse click without writing an onMouseDown callback for it in code.
Don't know how easy that would be. Maybe an overlay element in the playGUI could catch the click and pass it to the canvas? Never tried this, I just recompiled the engine it was a pretty easy change =)

#3 Would it be possible with the GuiMouseEventCtrl? Or are we going to run into the same problem we did with right clicking where it only caught them when the mouse was hidden (i.e. mouselook mode).

#4 I've been messing around with the raycasting stuff, and it works easily enough. I'm stuck on trying to translate the 2d cursor position into 3d world coordinates. All the tutorials I've looked at require the camera's matrix, but there doesn't seem to be anyway to access this from script (?).

If anyone knows how to do this, that would be great. If I could just get the 3d cursor coordinates, then picking an object would pretty much be done ...

#5 If this is intended for an actual networked application (ie, client(s) on one machine, server on another),
then i believe that you will always have poor picking performance without modding the engine.

This is because the stock script function containerRayCast() is coded to search only the server-side copy of the scenegraph, which doesn't exist on a client.

Thus you'll have to do all the raycasts server-side, which will be fine if you only do a raycast on infrequent events such as a mouse click, but not so hot if you want to raycast on frequent events such as mouseMove.

Note that modding the engine so that containerRayCast() works on a pure client is trivial.

#6 Any idea why containerRayCast() doesn't work on a pure client by default?

#7 Yes,
because in the engine it's hardwired to use the server-specific scenegraph.

the engine has two different scenegraphs,
one for server and one for client.

a dedicated server has only the server one,
and a plain client has only the client one.
a stand-alone instance (both server & client in one session) has both.

they're named something like ServerContainer and ClientContainer. (not exactly that, but something close)

it's pretty trivial to add a parameter to containerRayCast() to specify which one you want to use,
or, arguably better, just have the function itself decide.

#8 Why would the engine be hardwired to use the server-specific scenegraph and not the client when the client is faster? Security?

#9 By the way, these posts have reminded me of the original purpose of this post and I'd like to add that, while this is not a canonical answer and I haven't dug real deep to make sure I'm right, I believe the difference between being able to pick in the editor and not when actually playing is because of differences between the EditTSCtrl instead of the GameTSCtrl.

#10 @rick - You nailed it.

in an FPS you basically never want to trust the client, because the client could be lying.

of course, you can let the client to the picking and then have the server verify the client's "hey, i picked such-and-such" report, thus getting both security and much, much better network & server performance.

i guess tribes just didn't have the need.

#11 @cliff - you may be right. but of course, if you can run the world editor, that implies you're running a server.

#12 Orion - Yeah, just Stefan and I had been discussing this for a while, and we'd both kept coming back to "Picking works in the editor, so it should be easy to allow in game." In the end, I used Dave Meyer's Object Selection engine modification, but seeing the posts on this thread made me remember that I had done some additional research on this that I'd forgotten to mention to Stefan.