Thanks for your thoughtful reply. I sincerely appreciate that and hope the situation can be amended.

Quote from: nizikawa on October 19, 2021, 05:54 PMWKB 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.

Quote from: nizikawa on October 19, 2021, 05:54 PMRegarding 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).

Quote from: TheMadCharles 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?

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?

Quote from: nizikawa 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.

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"...

QuoteAugust 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?

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

Quote from: Syc on September 01, 2021, 07:13 AM
I just did it and I don't mind the fast walk Deadcode. You have to compare the fun of time-saving jumps with the agony of slow walking through a long walking portion. I guess with the right map you wouldn't really have long walking portions, but this map had a few, so I was glad to have the fast walk.

Good for you, but I refuse to lend any legitimacy to this, abusing battle race maps by playing them with fast walk. Especially old school ones like this, which were very much designed to be played without fast walk.

And to be clear, I am all for using maps in ways they weren't intended/designed for, if it's good or interesting. But adding fastwalk to battlerace is neither of those things.

Quote from: TheWalrus on August 31, 2021, 09:22 PM
Fun fact, deadcode hosted this map for a cl2k?  wl?  challenge back when replays first started cropping up.  Could have been the first ever submit your replay contest?

I don't think that is correct. I helped GARG0YLE palettize the map on 2005-04-27, but that version had the banana in the upper right placed badly, preventing the map from being completable. The final version has the banana moved a bit to fix this, but I only downloaded it on 2012-12-31, and have only placed it once, on 2013-10-31 with 4 other people (including Walrus). He and I tied for first place. (I also played it with ShyGuy on 2020-09-16, but he surrendered at the part with dark grey pixels that can be barely seen.)

Quote from: Korydex on August 31, 2021, 09:05 PM
I'm not quite sure there are many time-saving jumps instead of fastwalk but there are places where you can't jump at all.

There are plenty of time-saving jumps in this map. But with fastwalk, there might be only one that saves any time at all.

Quote from: Korydex on August 31, 2021, 09:05 PM
Fast Walk was used in pretty much every walk race chally before.

That's not a reason to keep using it. It never should have been used in the first place. Time-saving jumps are one of the big sources of fun for me in BRs, and having fastwalk just ruins it.

It's a real shame that this scheme has Fast Walk in it. That nullifies the advantage of taking almost all the nice time-saving jump opportunities in this map. (And in general too, it's just a really bad idea. Why did it ever become accepted to do this?)

If it didn't have Fast Walk I'd take part in this challenge.

T17 is strongly skill-based. What I've observed is that with a sufficient gap in skill, the differences in luck within any given round will almost always average out, and the stronger player will win. I would conjecture there to be at least 4 tiers of skill in which the person with higher skill wins at least 85% of the time.

I accidentally put that the scheme was my pick, but it was blitzed's pick.

Danelius went into /afk mode starting at 4:55 (with no explanation at the time – learned afterward it was a needed bathroom break). I was already winning by a wide margin... so I treated it essentially as a Surrender. I hate to win in this way though.

This game had some interesting TA opportunities. Here is the full pack:
TA pack for 2021-05-04 20.48.20 [Online Round 1] @Deadcode, ob`blitzed`zar.WAgame.7z

The shotgun at the end is actually a bit hard. If done even slightly inoptimally, blitzed's Airstrike can do 1 or more hp of damage to my worm if aimed perfectly. In this TA, my worm is perfectly positioned to avoid damage from any Airstrike... if I were just a tiny bit to the left or right, I could still be killed.

Of course, perfect aim of the Airstrike would not be guaranteed, so even an inoptimal Shotgun execution would probably have been good enough for my worm to survive. And all I needed was to survive 1 turn, because I had rope and thus would be able to do the kill and win on my next turn.

First replay file is the wrong one, it was actually 2021-05-01 20.36.00 [Online] ob`blitzed`zar, @Deadcode.WAgame. We voided it because my worm got irreversibly stuck, due to a bug in the map's design.

In closing, I'd just like to highlight this:

Quote from: Deadcode on April 18, 2021, 12:58 PM
Also, Lancelot, if you had stuck to your guns, and kept the exact scheme you originally attached to the cup without change, at least I could respect your integrity in some way for that. But your credibility as a mod dropped through the floor when you changed the scheme... for no reason. It still had all the things wrong with it that I had explained, so why did you do it?

You had every opportunity to make a reasonable change to the scheme. Instead you chose to make a nonsensical one, why? Out of spite?

I have tried my best to turn this disaster of a cup around back into something fun, and you have refused at every step to communicate clearly. You've flat-out ignored the most important points out of what I've said, repeatedly.

And also now, because of this, I don't particularly want to play with SIBASA ever again, and I expect he might feel the same way. Which is a shame, because he's a good player and I had fun playing T17s with him.

Do you refuse to use the latest scheme options so as to support pirates of the game who are still using WA v3.7.2.1?

Goodbye.

Quote from: Lancelot on April 18, 2021, 03:32 PM

QuoteI gave SIBASA the choice of whether to agree with the scheme or not. He was free to choose, and he chose to agree to it.

He told me on discord that he had to agree. And it sounded not voluntary, but under pressure

Well yes, obviously it was under pressure, but it's not like I was holding a gun to his head or anything. And I had already played 9 Team17 games with SIBASA before using that exact scheme, and he spectated an additional 2 that I played with Chicken23, so it's not like he was unfamiliar with the scheme itself. He was free to choose to disagree with the scheme choice, agree with the scheme choice, or delay our match until having a chance to make the decision with a clearer mind. He chose to agree with it immediately. It's all there in the log file he quoted.

Furthermore, his protest was not about the scheme itself, but about the rules. He believed that it was against the rules to play using any scheme other than the cup-attached prescribed scheme. But given that you were willing to let me re-upload my games with Syc, that's apparently not the case; if the players agree, using a different scheme is apparently allowed. So SIBASA's entire reasoning behind protesting the scheme change in the first place is apparently not based on fact?

Quote

QuoteTruly I wouldn't mind much if you took my scheme, and changed its weapon probabilities to suit your liking. That is the thing I care least about. Have you read anything I've written? I've made it clear again and again what I most dislike in your scheme, and it's not the crate probabilities.

I'm more worried about this than increased damage from digging tools or glitch bans
Because the balance of the main weapon list is the same, with rare exceptions. If you look at the fact, for example, the mole and dynamite weapons are weapons of different strength.

You haven't even replied to my proposal. About copying your crate probabilities into my scheme.

Quote

Quote"Conditionally prohibited"? Huh? As "they" did? Who's they? I haven't the faintest idea what you're talking about. Language barrier...

I meant that the fact that glitches and walking on the ceiling can not be used without applying the latest innovations

What do you mean by "applying the latest innovations"? Do you mean upgrading the game to v3.8.1? There's no excuse not to do that. The patch is easily available to anyone using the CD-ROM, Steam, or GOG version. Are you using a pirated copy of the game?

Apparently not, I just checked one of your replays and you're using WA v3.8.1. So I have no idea what you mean by "can not be used without applying the latest innovations".