View source for User talk:Xor
- Archived talks
- Archived talk:Xor 20180221
Hey there!
- [View source↑]
- [History↑]
Contents
Thread title | Replies | Last modified |
---|---|---|
General Ablation Study Framework | 0 | 10:44, 19 February 2023 |
RoboRunner freeze | 5 | 02:57, 23 January 2023 |
A simple bot that dodges bullets create by ChatGPT | 0 | 11:54, 5 December 2022 |
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 |
To accurately measure the performance of different components of a bot, we do ablation study by disabling each of them. However, due to the popularity of hand-made bot frameworks, it is generally hard to compare your bot to other bots component-wise, even when source code is given.
Since we cannot have everyone rebase onto a common framework, another approach would be replacing part of the behavior of a robot dynamically. This should also work with bots without source code.
A robot can be divided into 3 basic components: Movement, Gun and Radar. Replacing behavior from one component is as simple as hooking calls like setBodyXXX, setGunXXX, setRadarXXX to IAdvancedRobotPeer. This way we can e.g. easily compare different guns from different bots while having movements fixed, even without doing anything with the code.
There are certainly drawbacks:
- Replaced components are still consuming CPU while contributing no behavior.
- No fine-grained way of comparing sub-components, e.g. Bullet Shadow
- Certain features may not work properly without manually changing code, e.g. bullet shadow may have wrong gun firing angles
Also, frameworks like this should only be used for experimental purposes, and forbidden in competitions unless given permissions from original authors.
Hi, could you help with your version of RoboRunner from github.
I use to use User:Voidious' version and was fine until several years ago. This year (2023) I tried to run it but it just freezes. Then I switched to your fork, it also freezes but at least produce some output to post.
./rr.sh -bot zyx.nano.RedBull 1.0 -c competitions/sample_1v1.rrc -seasons 1 -t 1 Copying missing bots... 0 JAR copies done! Initializing engine: ./robocodes/r1... java.io.IOException: processOutput == null at robowiki.runner.BattleRunner.initEngine(BattleRunner.java:68) at robowiki.runner.BattleRunner.<init>(BattleRunner.java:42) at robowiki.runner.RoboRunner.<init>(RoboRunner.java:166) at robowiki.runner.RoboRunner.main(RoboRunner.java:81) Challenger: zyx.nano.RedBull 1.0 Challenge: Sample 1v1 Test Bed Seasons: 1 Threads: 1 Scoring: Average Percent Score Smart battles: Off java.util.concurrent.ExecutionException: java.lang.NullPointerException: Cannot invoke "java.lang.Process.getOutputStream()" because "battleProcess" is null at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191) at robowiki.runner.BattleRunner.getAllFutures(BattleRunner.java:97) at robowiki.runner.BattleRunner.runBattles(BattleRunner.java:82) at robowiki.runner.RoboRunner.runBattles(RoboRunner.java:322) at robowiki.runner.RoboRunner.main(RoboRunner.java:87) Caused by: java.lang.NullPointerException: Cannot invoke "java.lang.Process.getOutputStream()" because "battleProcess" is null at robowiki.runner.BattleRunner$BattleCallable.call(BattleRunner.java:177) at robowiki.runner.BattleRunner$BattleCallable.call(BattleRunner.java:156) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:833) java.util.concurrent.ExecutionException: java.lang.NullPointerException: Cannot invoke "java.lang.Process.getOutputStream()" because "battleProcess" is null at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191) at robowiki.runner.BattleRunner.getAllFutures(BattleRunner.java:97) at robowiki.runner.BattleRunner.runBattles(BattleRunner.java:82) at robowiki.runner.RoboRunner.runBattles(RoboRunner.java:322) at robowiki.runner.RoboRunner.main(RoboRunner.java:87) Caused by: java.lang.NullPointerException: Cannot invoke "java.lang.Process.getOutputStream()" because "battleProcess" is null at robowiki.runner.BattleRunner$BattleCallable.call(BattleRunner.java:177) at robowiki.runner.BattleRunner$BattleCallable.call(BattleRunner.java:156) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:833) java.util.concurrent.ExecutionException: java.lang.NullPointerException: Cannot invoke "java.lang.Process.getOutputStream()" because "battleProcess" is null at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191) at robowiki.runner.BattleRunner.getAllFutures(BattleRunner.java:97) at robowiki.runner.BattleRunner.runBattles(BattleRunner.java:82) at robowiki.runner.RoboRunner.runBattles(RoboRunner.java:322) at robowiki.runner.RoboRunner.main(RoboRunner.java:87) Caused by: java.lang.NullPointerException: Cannot invoke "java.lang.Process.getOutputStream()" because "battleProcess" is null at robowiki.runner.BattleRunner$BattleCallable.call(BattleRunner.java:177) at robowiki.runner.BattleRunner$BattleCallable.call(BattleRunner.java:156) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:833) Done! Took 0.1s All scores: Exception in thread "main" java.lang.ArithmeticException: / by zero at robowiki.runner.RoboRunner.printOverallScores(RoboRunner.java:471) at robowiki.runner.RoboRunner.runBattles(RoboRunner.java:333) at robowiki.runner.RoboRunner.main(RoboRunner.java:87)
I tried to run wit openjdk 11 and 17, the results are similar.
Side note I could gradle your version only with openjdk-11.
I suspect that it is all due to jdk change, since it also broke Voidious' version which use to work just fine. But I cannot spot what is wrong.
"My version" is also a little bit old, I will publish a recently updated one, hope that it can solve your problem.
I updated the RoboRunner page to add the link to the fork. You can try and see whether it solved your problem.
Player: Write a simple robocode robot that dodges bullets.
ChatGPT:
Here is a simple Robocode robot that dodges bullets by always moving in a circular pattern:
import robocode.*; public class CircleBot extends Robot { public void run() { // Always move in a circle while (true) { turnRight(10); ahead(10); } } // When a bullet is fired, turn in the opposite direction public void onScannedRobot(ScannedRobotEvent e) { turnRight(e.getBearing()); } }
The robot moves in a circle by turning right 10 degrees and moving forward 10 units in each iteration of the run() method. When it senses a bullet being fired, it turns in the opposite direction to avoid it. This simple strategy can be effective against some opponents, but it may not be sufficient to win against more advanced robots.
Player: Detecting bullets fired by the opponent requires first recording the energy of the opponent, then check if the energy drop by a specified amount. Improve the above program so that it uses this technique.
ChatGPT:
Here is an improved version of the CircleBot robot that uses the technique you described to detect bullets fired by the opponent:
import robocode.*; public class CircleBot extends Robot { // Record the energy of the opponent double opponentEnergy = 100; public void run() { // Always move in a circle while (true) { turnRight(10); ahead(10); } } // When a bullet is fired, turn in the opposite direction public void onScannedRobot(ScannedRobotEvent e) { // Check if the opponent's energy has dropped by a specified amount if (opponentEnergy - e.getEnergy() >= 1) { // Turn in the opposite direction to dodge the bullet turnRight(e.getBearing()); } // Record the opponent's current energy opponentEnergy = e.getEnergy(); } }
This robot works in the same way as the previous one, but it also checks if the opponent's energy has dropped by a specified amount (1 in this case) in each iteration of the onScannedRobot() method. If it has, this indicates that the opponent has fired a bullet, and the robot turns in the opposite direction to dodge it. This improved strategy can help the robot avoid being hit by bullets more effectively.
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.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page.
Return to Thread:User talk:Xor/Manifold Learning/reply.
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.