Files
December 07, 2021, 08:38 PM

Example AI Battle Mission

File #2394, Viewed 401 Time(s)

Basic Information
File rate
Not rated yet
Name: Example AI Battle Mission
Type: Mission
Author: -
Submitted by: Poland TheMadCharles

Click to download: (Downloaded 108 time(s))
Example AI Battle Mission 2021-10-20.zip

Downloaded 108 time(s).

Time: September 11, 2021, 06:56 AM
Description:
example mission against AI, specifically testing CPU levels beyond 5
to be used with wkTerrainSync: https://worms2d.info/WkTerrainSync
extract to SavedLevels/Mission/Custom

map is the default SPACE

update 2021-10-20: nerfed Guardsmen Team to CPU5.0 for challenge purposes (was CPU5.5 previously)

Author Topic: File #2394, Example AI Battle Mission  (Read 452 times)

0 Members and 1 Guest are viewing this topic.

Offline TheMadCharles

File #2394, Example AI Battle Mission
« on: September 11, 2021, 06:58 AM »
here's a replay as proof that this mission is clearable
I can't upload replay files in missions files separately for some reason

NOTE: this replay (and the one posted by Deadcode below) has Guardmen as CPU5.5, which is no longer the case with this mission now
« Last Edit: October 20, 2021, 01:03 AM by TheMadCharles »

Offline Deadcode

Re: File #2394, Example AI Battle Mission
« Reply #1 on: October 19, 2021, 05:32 AM »
There's a reason I have WA range-checking the CPU level to prohibit anything higher than CPU 5.00. Higher levels behave absolutely identically to CPU 5. Apparently the author of wkTerrainSync did not even bother to test that before blindly disabling a range check they did not understand. (It would of course be possible to have higher CPU levels behave differently, but that would require changing more than wkTerrainSync does. As it stands, there is no difference whatsoever between a CPU 5 and a "CPU 6".)

This replay can be easily edited to no longer require wkTerrainSync. It is playable with vanilla WA v3.8.1, while still showing the exact same sequence of events leading to completion of the mission:

2021-08-22 01.17.57 [Offline Custom Mission] @ch4ruzu, Guardsmen, Patrol, Commandos.WAgame

Offline TheMadCharles

Re: File #2394, Example AI Battle Mission
« Reply #2 on: October 19, 2021, 11:31 AM »
Hmm, interesting, i guess that's something worth taking a look at.

What about making a TAS of this mission? Or should I first make a chally for this mission?

Offline nizikawa

Re: File #2394, Example AI Battle Mission
« Reply #3 on: October 19, 2021, 12:14 PM »
My knowledge regarding "CPU 6" is based on WKB page: https://worms2d.info/Worms_Armageddon_mission_file which, only now confirmed to be wrong, states that "CPU 6" team indeed exists.
A patch to the replay loader was made because WA was inconsistent in handling extra CPU levels - it was possible to start a mission with a WAM file that adds "CPU 6" team, but was impossible to watch a replay from such game. This was enough reason to warrant disabling the range check.

A lot of effort was dedicated to creation and further development of wkTerrainSync and my other modules to implement features previously impossible in WA and probably not present in future WA releases. I've dedicated several weeks reverse engineering WA to understand its inner workings to the best of my abilities to be able to create and share my works with the community as open-source modules. Saying that I did not even bother is disrespectful, especially from someone with access to WA's source code.

Offline Deadcode

Re: File #2394, Example AI Battle Mission
« Reply #4 on: October 19, 2021, 04:21 PM »
My knowledge regarding "CPU 6" is based on WKB page: https://worms2d.info/Worms_Armageddon_mission_file which, only now confirmed to be wrong, states that "CPU 6" team indeed exists.
A patch to the replay loader was made because WA was inconsistent in handling extra CPU levels - it was possible to start a mission with a WAM file that adds "CPU 6" team, but was impossible to watch a replay from such game. This was enough reason to warrant disabling the range check.

A lot of effort was dedicated to creation and further development of wkTerrainSync and my other modules to implement features previously impossible in WA and probably not present in future WA releases. I've dedicated several weeks reverse engineering WA to understand its inner workings to the best of my abilities to be able to create and share my works with the community as open-source modules. Saying that I did not even bother is disrespectful, especially from someone with access to WA's source code.

What is disrespectful is you assuming that a range check, that I put careful consideration into putting into the game, has no purpose and can be removed without consequence. The fact remains that you put no research into checking if CPU levels higher than 5.00 made any difference at all, simply removing the range check and calling it a day. That is deceptive to people using your software, encouraging a placebo effect, and resulting in people wasting time experimenting with higher CPU intelligence levels, thinking it's actually making a difference when it isn't. It also means that if you end up actually finding out how to enable higher levels for real, and do so, this will either result in replay files becoming incompatible (with checksum errors and desynchronized playback) or require you to implement compatibility with earlier versions of your module, perhaps by using the version number field in your embedded JSON data.

As for the WKB page on the mission file format, for one thing, it is a completely unofficial source of information; nobody has asked me to check over it and I have not done so. Nevertheless it does appear at a glance to be of high quality. But what you claim is on it is nowhere to be seen; nowhere does it claim that "CPU 6" is possible, in fact quite to the contrary, it states that "81-100 = CPU5" and makes no mention of any higher level.

If your worst mistake had been lack of research on a range-check, I would have been kinder to you. But you have been reckless and irresponsible in your activities. You released a "TA build" knockoff, without even asking me, which means that now anyone with a basic knowledge of reverse-engineering can take your work and remove its restrictions, making it work online and write replays indistinguishable from the standard build, with far, far less time and work than you put into it. This is because by its very nature your "TA build" must be a patch to the standard WA.exe (and it is, never mind that it includes the patched EXE as a copy rather than making the patch itself), making it easy for another, less scrupulous reverse-engineer to go through each individual patch and determine which ones block online use and which ones encrypt the replay, and undo those patches while keeping the rest. The only safe way to release a TA build is as a full build from source code with the online parts of the game conditionally-compiled out, which is what my TA builds do. And yes, I have been taking a very long time to get around to finishing my TA build to the point that it is publicly releasable, but I have looked forward with great anticipation to that time, when there can be full-out competition between people TA-optimizing various scenarios. It will take some patience, but the wait will be well worth it. The release of your "TA build", however, may just end up throwing the game into chaos with people invisibly cheating online and offline, forcing me to put lots of time and work into cheat-proofing WA when my time would be much better spent adding features and fixing bugs.

You have also released the source code to a module that shows worm numbering, making it even easier for anybody to build a modified version that is completely unrestricted for showing worm numbering online. Compared to the "TA build" this is a small thing, but it is by itself still bad, and has had quite a negative effect on the community.


I also noticed a while ago when you were complaining on Discord about how you were relegated to reverse-engineering and making patches for a "kids' game"...
Quote
August 25, 2021
[1:22 PM] nizikawa: knowing that other cool guys use their skills to hack modern systems like PS4, find 0day exploits, secure commercial systems or write research papers on computer security
[1:22 PM] nizikawa: while you're stuck modding 20+ year old kids game...
[1:22 PM] nizikawa: it's pretty depressing
Do you even have any respect for the game you are hacking up to bits?
« Last Edit: October 19, 2021, 04:32 PM by Deadcode »

Offline Deadcode

Re: File #2394, Example AI Battle Mission
« Reply #5 on: October 19, 2021, 04:39 PM »
Hmm, interesting, i guess that's something worth taking a look at.

What about making a TAS of this mission? Or should I first make a chally for this mission?

That could be fun, but it's a large challenge with lots of worms to kill and I might prefer to wait until the mission is finalized. I notice that the CPU levels in this mission are set to 3.5, 4.5, and 5.5, not actually 4, 5, and 6 as the flags claim. Fractional CPU intelligence levels below 5.00 actually do make a difference, so that deserves to be considered if you haven't already done so.

Have you decided whether you would prefer to:
1. Change the CPU 5.5 team to CPU 5.0 so it is accurately doing what it claims to do
or,
2. Wait until the game actually allows CPU levels higher than 5.0 to be effectively used?

Offline nizikawa

Re: File #2394, Example AI Battle Mission
« Reply #6 on: October 19, 2021, 05:54 PM »
As for the WKB page on the mission file format, for one thing, it is a completely unofficial source of information; nobody has asked me to check over it and I have not done so. Nevertheless it does appear at a glance to be of high quality. But what you claim is on it is nowhere to be seen; nowhere does it claim that "CPU 6" is possible, in fact quite to the contrary, it states that "81-100 = CPU5" and makes no mention of any higher level.

WKB states this:
Quote
CPU skill. Setting this value to 0 will cause the team to be player controlled, missions will end if all player controlled teams die. Setting this to 101-120 will result in what appears to be a hyper-accurate 6th skill that exhibits some peculiarities, it loves to aim for its own alliance teammates (including you), but will only actually fire the shot if it thinks it's going to miss because there is land in the way. This can result in some unintended friendly fire (for example, firing an uzi when there is a thin strip of land in the way, so later bullets hit). Other invalid values can cause strange behaviour and should not be used. The team's flag is determined by this setting:
which made me believe that special, 6th CPU intelligence level was possible.

Regarding wkToolAssist: Several protection techniques were put in place to prevent reverse engineering, with vital patches using virtualized code. I genuinely believe that it's easier to make your own TA module or cheats from scratch than by analyzing wkToolAssist.
I made announcement on TUS and WA's discord regarding its development roughly one month prior to its release, with plans about releasing it to public as encrypted module. No objections were raised. I reached out to StepS on the day of release and he just congratulated me on the work and mentioned the difference between patched out networking code and conditionally compiled. Nobody contacted me to prevent releasing the module, so with protections in place I really believed it was OK to release it.
It has been nearly two months since release of the module and it has gained very little attention and apparently no chaos ensued so far.

WA is my favorite game that I enjoyed since childhood and I hold it in very high regard. It inspired me to learn reverse engineering and hacking techniques. Hacking it and sharing my works with the community brings me joy. But I'm not going to deny that it is in fact a '90s kids' game and I would be better of dedicating my time to more serious tasks than game modding or arguing with strangers on the internet.

If you really consider my works to be hurting WA community, then accept my sincere apologies. I would be very happy to discuss with you possible solutions to amend this situation.

Offline Deadcode

Re: File #2394, Example AI Battle Mission
« Reply #7 on: October 19, 2021, 06:59 PM »
Thanks for your thoughtful reply. I sincerely appreciate that and hope the situation can be amended.

WKB states this:
Quote
CPU skill. Setting this value to 0 will cause the team to be player controlled, missions will end if all player controlled teams die. Setting this to 101-120 will result in what appears to be a hyper-accurate 6th skill that exhibits some peculiarities, it loves to aim for its own alliance teammates (including you), but will only actually fire the shot if it thinks it's going to miss because there is land in the way. This can result in some unintended friendly fire (for example, firing an uzi when there is a thin strip of land in the way, so later bullets hit). Other invalid values can cause strange behaviour and should not be used. The team's flag is determined by this setting:
which made me believe that special, 6th CPU intelligence level was possible.
You're right, it does say that. It is incorrect though, and has always been so; there is another part in the CPU team code where the skill level is clamped/limited to the range 0-100. That is the only place where the skill level is input to the CPU team code, so it's guaranteed that 101-128 have the same effect as 100. And my redubbed copy of TheMadCharles's replay above, playable with unpatched WA v3.8.1, demonstrates this. If the 0-100 clamp is removed, then 101-128 actually does cause the CPU to make different choices than it would at 100, but I haven't carefully read through the code yet to determine if this would be a difference making it more intelligent. I wouldn't be surprised if it had the opposite effect in some regards, due to truncated overflows/carries.

It appears that edit to the WKB page was done by Melon. WWP appears to have the same 0-100 clamp, so it's unclear why Melon would have had any reason to believe 101 and higher behave differently.


Regarding wkToolAssist: Several protection techniques were put in place to prevent reverse engineering, with vital patches using virtualized code. I genuinely believe that it's easier to make your own TA module or cheats from scratch than by analyzing wkToolAssist.
I made announcement on TUS and WA's discord regarding its development roughly one month prior to its release, with plans about releasing it to public as encrypted module. No objections were raised. I reached out to StepS on the day of release and he just congratulated me on the work and mentioned the difference between patched out networking code and conditionally compiled. Nobody contacted me to prevent releasing the module, so with protections in place I really believed it was OK to release it.
It has been nearly two months since release of the module and it has gained very little attention and apparently no chaos ensued so far.

WA is my favorite game that I enjoyed since childhood and I hold it in very high regard. It inspired me to learn reverse engineering and hacking techniques. Hacking it and sharing my works with the community brings me joy. But I'm not going to deny that it is in fact a '90s kids' game and I would be better of dedicating my time to more serious tasks than game modding or arguing with strangers on the internet.

If you really consider my works to be hurting WA community, then accept my sincere apologies. I would be very happy to discuss with you possible solutions to amend this situation.
The thing is, an unscrupulous reverse-engineer would not even need to hack your wkToolAssist module directly; they'd only need to look at which parts of the code it patches, and focus on reverse-engineering those parts in the original WA EXE in order to reproduce all of your module's functionality.

And the reason I did not reach out to you about wkToolAssist before you released it, is that at that time, I was still very depressed about Team17 sitting on v3.8 and v3.8.1 for months before allowing them to be released (forcing bugs that I'd already fixed many months before release to still be in the released version), whereas you as a module writer can release with full freedom anytime you wish to. I could not bring myself to contact you at that time, and then immediately regretted that when you finally did release the module.

I also have issues with some of your design decisions regarding that module. I have not tried running it, but its documentation says that replays created while using it are encrypted and do not contain checksums. Not including checksums was a very bad decision; they serve a very important purpose, and without them, it's much harder to determine (especially programmatically) whether a replay has desynchronized, and if so at which point it has done so. You could have put an extra layer of encryption on checksums, or used a different checksum algorithm, but instead you apparently left them out, and I very much object to that.

And the point still stands that wkWormOrder was a bad move, especially releasing its source code, and has had negative consequences to the community on a level you might not be fully aware of. You should have just requested that I add showing worm order as a scheme option, and been patient for that to appear in the next WA release (I've already implemented it and it will be in v3.8.2 or v3.9, whichever the next version ends up being).

Offline nizikawa

Re: File #2394, Example AI Battle Mission
« Reply #8 on: October 19, 2021, 07:36 PM »
I encourage you to take a look at wkToolAssist then, by both running it and loading it in IDA or other tools. If you don't trust my modules, then try running them in isolated VM, though you have my guarantee that no malicious intent or code was put into the module. Unfortunately wkTA does not work under wine due to one of several layers of protection not being compatible with wine, so you will need a Windows VM. I did some tricks to make it harder to compare patched WA.exe, which itself does not contain any TA patches, only various protections.

Overall, more work was put into the protections than module itself. Still, I agree with you that a potential hacker/cheater can get a head-start by analyzing the patched code areas.
Despite not announcing it I've ultimately left checksum code intact, so replays produced by the module do contain proper state checksums. Also, even if the wkTA chat message is removed with hex editor from replay file, it is still possible to identify replays created with wkTA, due to protection I've included in the module. And the replay saving code is obfuscated by virtualizer to make it harder to identify what has been altered in the replay.

I agree that releasing wkWormOrder was a huge mistake. Even though I am very careful with releasing potentially dangerous modules, I simply did not foresee that revealing worm numbers would cause so many problems.

Offline TheMadCharles

Re: File #2394, Example AI Battle Mission
« Reply #9 on: October 20, 2021, 12:58 AM »
Hmm, interesting, i guess that's something worth taking a look at.

What about making a TAS of this mission? Or should I first make a chally for this mission?

That could be fun, but it's a large challenge with lots of worms to kill and I might prefer to wait until the mission is finalized. I notice that the CPU levels in this mission are set to 3.5, 4.5, and 5.5, not actually 4, 5, and 6 as the flags claim. Fractional CPU intelligence levels below 5.00 actually do make a difference, so that deserves to be considered if you haven't already done so.

Have you decided whether you would prefer to:
1. Change the CPU 5.5 team to CPU 5.0 so it is accurately doing what it claims to do
or,
2. Wait until the game actually allows CPU levels higher than 5.0 to be effectively used?
I guess for now I'll set it to 5.0, and I don't mind having fractional levels here. I'm looking forward to seeing CPU levels higher than 5.0 tho, but I'm really questioning the possibility of them appearing in the frontend

also brb grabbing popcorn
« Last Edit: October 20, 2021, 01:08 AM by TheMadCharles »