User talk:Xor
- Archived talks
- Archived talk:Xor 20180221
Hey there!
- [View source↑]
- [History↑]
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| SecurityManager replacement | 5 | 14:43, 8 July 2022 |
| Thoughts on entropy | 0 | 16:56, 1 June 2022 |
| Manifold Learning | 2 | 16:20, 29 July 2021 |
| Good to see robowiki is back! | 0 | 13:04, 12 June 2018 |
![]() First page |
![]() Previous page |
![]() Next page |
![]() Last page |
As per JEP411, SecurityManager is deprecated for removal as of Java 17. However, robocode (before Tank Royale) is fully dependent on SecurityManager in order to ensure fairness. Unfortunately, there are no official alternative to SecurityManager, which left us only three options:
- Stick to Java <=17, which may be the last LTS version with SecurityManager support.
- Switch to Tank Royale, and develop some container based security (which is platform dependent, unfortunately).
- Find alternatives to SecurityManager, which can be used in both original robocode and robocode Tank Royale. SecurityManager alternatives can be used as pure Java sandbox solution for Tank Royale, which is cross-platform.
Good news: Java 9 Modules have complete support for encapsulation, which can be used as a shallow sandbox mechanism. Direct and reflective access to public members of non-exported packages are forbidden by the language, making robocode engine potentially safe from attacks. Custom ClassLoaders can be used to forbid or replace certain risky java APIs. File & network access can be further restricted by creating dedicated user, and Linux systems can take advantage of chroot & cgroup for enhanced control over resources.
By taking advantage of multiple layers of security countermeasures, we can achieve even safer & fairer environments for robocode competitions.
How comes that User:FlemmingLarsen kept the Tank Royale announcement outside of this Wiki? I think it seems to be the clear direction for a switch. It would be nice to have a bridge for legacy bots to run to avoid loss of historical stats. But the use of standard coordinate alone would justify the switch for me :) Also we would need a new rumble logic to be done.
I also get tired of java where a lot of high level math libraries need to be reinvented. I would love to see what is possible if we do not have to build our own implementation of machine learning tools.
We might get new flock of people if a python API is available.
Tank Royale is very exciting in allowing Python & C++, since a lot of us are tired optimizing Java code to make it more C.
However, Python & C++ are not as platform independent as Java, so in order to build a rumble ranking that everyone can run on their own, we must find some solutions. This could be the long term choice anyway.
In the short term, Security Manager is still there, and sticking to Java <=17 isn’t very bad as a lot of companies are still using Java 8. We have plenty of time to develop our own sandbox solutions, which is still useful for Tank Royale.
Tank Royale definitely sounds exciting. I feel like we would get a lot of new people if people could use more than just Java. I haven't looked at the technical details of Tank Royale but WASM sounds like a secure environment and a variety of languages can be compiled to it.
WASM is a great idea, we could keep a list of supported languages, where Java can use existing JVM sandbox, and C++ & Javascript into WASM. Not sure how Python can be adequately supported in this mode though, popular frameworks such as Numpy, Tensorflow & Pytorch are all not fully Python.
Update: Pyodide is a full WASM CPython implementation with Numpy support, which can be a good starting point.
- Targeting maximizes cross-entropy
- Wave-surfing minimizes cross-entropy
- Random movement maximizes self-entropy
- But random movement doesn't minimize cross-entropy
- Flattener minimizes "self" cross-entropy
- But flattener doesn't maximize self-entropy
What deeper insight can you get from this?
Guess Factor based methods generalize well, based on priori knowledge about robots moving in circles & max escape angle. Better methods such as precise max escape angle helps greatly. However given enough samples, I wonder whether some deep enough model can learn the shape of escape envelop, as well as precise max escape angle, etc. And generalize even better.
I could imagine developing some sort of "LearnedFactor" function that takes as input the firing angle along with the enemy's position, velocity, maybe more complex features like precise MAE, etc. As long as the function is invertible with respect to the firing angle you could then do KNN with those instead of GuessFactors.
The biggest challenge will be how to deal with different settings in recorded and aiming. Guess Factor indeed do this with orbital movement assumption, and PIF with not moving out of wall.
I'm thinking about some end2end deep model, where transformations between recorded and aiming angles can be learnt automatically. E.g. Given a sequence of historical wave intersect location, movement and bullet hits, try to predict the next wave intersect location.
![]() First page |
![]() Previous page |
![]() Next page |
![]() Last page |



