A method that would be a useful addition to the lua SDK in the form of method signatures:

get_joint_predicted_position(<player_id>, <frame?>, <joint_id>)
-- the idea here being that you give us the positions of the ghosts, preferably at a specified frame but that's definitely not required.

This would allow me to write a proof of concept AI.

Yes, and it would also make sure we have access to the tools necessary to make a "best-chioice-AI" sampling all possible outcomes from a set state of joints.

If it were only usable in SP and hardcoded to ban you if you used it in MP and lied to you like 25% of the time it would make proof-of-coccept pre-sampling AI mechanics possible to develop, but why not leave it at us having to use post-sampling AI mechanics, which re a lot harder to get efficient, yet as fun to play with?

I'm going to hold off on the explanation of why this level of AI could be easily beaten by an average human player with just a little strategic sense. Still a bit groggy at the moment, and can't seem to properly translate my thoughts to words.

Anyways, "fun" is a pretty relative term, and the viewpoint you've adopted on this subject is one that has always annoyed me. Personally, I have a lot more fun hacking games as opposed to playing them. Most games these days are ridiculously easy, and it's a lot more rewarding of a challenge for me to reverse engineer the game and screw with the mechanics in order to make the game do something it's not supposed to. (although the underlying structures do take on predictable patterns after a while) I wouldn't expect you to have the same perspective, of course, since you're coming from the position of a player who takes the end-result of all that work and within seconds, has god mode. I don't fault you for having that perspective, but I do think it's important that you understand that people derive enjoyment through a lot of different ways.

Not sure if there's enough LUA savvy people in the community, but I always liked the idea of having competitions to see who could write the strongest AI.

I'll reread (and possibly revise) this when I'm a bit more awake to see if makes sense grammatically.

It'd already be lying to you because it'd be using ghost data.

The main problem with this kind of feedback is that it can use the engine to process choices, whereas if we don't allow enginebased AI simulation, as for example in SC1 compared to SC2 the tools necessary are at our disposal. Now that said a fully engine-based AI would not work that well, but having it learn a pattern and make "correct" decisions based on the action-state feedback from the game itself would highly improve the functionality as a "working" AI.

That said, the complexity of movement in Toribash would be hard to decode into an expression on the base of cause and response as found in simple games, but having direct-feedback instead of fully pattern based decisions would highly suggest the possibility of creating more of an AI than a player script.

That said, I have never written an AI with much complexity at all, more of pattern based-scripts. Howeever, even I see a method of developing an "AI" (on the form of simulation-based material and post-processing AND live-feedback from the client) which would "work" as intended as long as the computer handles the engine at a which speed, and now that we can turn of the graphical overlay already, I see no reason why we would allow bots being developed.

I'm not quite understanding your point. You readily admit that even with an api building an AI for Toribash would be difficult, but then you say there's no reason to allow us to try?

Why is 'someone might use it to farm multiplayer' a valid argument, when I can already do that more efficiently without going through lua at all?

I take it you have played around with feed-back based applications versus patter based stated applications to control an application from another sometime in your life, if so, you could easily compare the speed difference to that of binary versus linear search based on the complexity of the situation analysed. Here we have a VERY complex event which the AI should respond to, we would not only make it possible to develop an AI, rather providing the tools is just the same as asking for someone to create their own functioning bot.

You're not addressing why that's a bad thing.

I'm still not quite understanding the basis for your opposition. Obviously using lua to implement an AI isn't the most optimal solution. Anyone with a basic understanding of code execution could understand that, even those without experience writing AIs. I don't see why that should disqualify the possibility to even attempt it, though.

Following up on Leel's farming point, there's nothing currently stopping me from implementing this functionality even without the requested lua bindings. I've already previously released a proof of concept for hijacking the lua context initialization in order to add third party lua C-extensions to the global context. It'd be a pretty simple matter to build on that existing code in order to bring in an lua FFI interface, use that to load in a redistributable build of ODE, and recalculate the physics based on the Toribash constants that I've acquired in previous projects. As a developer, however, I really dislike the idea of recalculating values that haven't changed, and including a second copy of a library that's already statically linked.