Java API questions

[Salakka 1]

I can already see in TOH something like RVEngine.onPlayerConnected handler implemented, but will there be other direct handles like RVEngine.onPlayerHit, RVEngine.onPlayerDied, RVEngine.onPlayerRespawn implemented.

Also is this fully asynchronous API, I mean if I will store something for example to "slow" database ... so it won't stall game engine while doing so, or do I need to handle synchronous way and spawn own thread for slow processing.

Oh and is there any restrictions in Java, like can I run for example HttpServlet which will start-up when map starts .. which then serves player information to web clients. (and obey normal constructor/destructor)

[.kju 3244]

Check the posts and threads Slapstick posted in:

http://forums.bistudio.com/member.php?57748-Slapstick

It will give you a good idea of the state of things.

[darkiron 1]

I can already see in TOH something like RVEngine.onPlayerConnected handler implemented, but will there be other direct handles like RVEngine.onPlayerHit, RVEngine.onPlayerDied, RVEngine.onPlayerRespawn implemented.

Also is this fully asynchronous API, I mean if I will store something for example to "slow" database ... so it won't stall game engine while doing so, or do I need to handle synchronous way and spawn own thread for slow processing.

Oh and is there any restrictions in Java, like can I run for example HttpServlet which will start-up when map starts .. which then serves player information to web clients. (and obey normal constructor/destructor)

You think like me go to make a battlelog for Arma III ?

[Salakka 1]

You think like me go to make a battlelog for Arma III ?

Something like live statistic web page with websocket came to my mind :)

[Slapstick 10]

Oh and is there any restrictions in Java, like can I run for example HttpServlet which will start-up when map starts

I know others have had security/access questions as well, and yes there are restrictions on what you can do in Java. TKOH uses (seems to use) a Java SecurityManager and a custom ClassLoader which means the game should be able to exercise a fine degree of control over what user code can do. I say "seems to" because who know what the game engine really does under the hood.

At the moment the security model is very restrictive, but I can definitely see the possibility for hosts to specify exactly what specific classes are allowed to do. Hopefully at some point in the future server admins will be able to say something like, "only classes in com.ofpec.salakka.servlet can open sockets".

But I suspect that time is quite far off.