I don't think it would be possible via a Wormkit module unless everyone had the module installed.  It might be a nice feature to have baked into the next version of WA but then someone could create a module to manipulate the list of modules that it sends when requested.

There are technical possibilities to secure Wormkit module loading to an extent but it's probably a terrible idea to do it.

Does anyone running 3.8 not have these files? I'm happy to assume everyone needs to be on the latest version of WA when using these mods. wkTerrainSync requires 3.8 also.

Quote from: kurs on July 02, 2025, 12:56 AMIt's interesting that I haven't seen anyone using Front.spr in their landscapes, only Back. Why isn't it popular?

I did some quick testing of front.spr a while ago. The main consideration is it obscures the view of the water and I think the parallax movement could do with some tweaking to move quicker than the terrain layer when scrolling.  It would be cool to see in a terrain though.  That layer can be animated as well.

Ahh ok, I've always been confused about why gfx, gfx0 and gfx1 all exist.  gfx0 and gfx1 take priority if they exist by the looks of it.

Yeah the wkTerrainSync sprite replacement feature is great because all players get to see the new sprites without any manual replacement. I've noticed that if you delete gfx0 and gfx1, it messes up this feature (it causes weird palette issues likely because gfx.dir uses a different palette) so you're probably best restoring those two files.  If you try the Retro Hell terrain and look at the replaced clouds, you'll see what I mean : https://www.tus-wa.com/files/file-3000/

There was no problem with you creating a new palette for your gfx.dir replacement file, it worked perfectly.  And great job with the WoG terrain!

Quote from: kurs on July 01, 2025, 11:59 AMI don't quite understand what this has to do with the wkTerrain module, as far as I know in gfx1 and gfx0 there is for people with vision problems, so the colors are less saturated and that's it. The gfx.dir archive presented here works fine regardless of what palette a specific user terrain file uses, this has been verified, and by the way wormhit1 has not changed at all.

You created a new gfx.dir file which includes some new animations with the intention of replacing these sprites globally in the game. This is cool and fine (although replacing gfx.dir doesn't work for me, I had to replace gfx0.dir / gfx1.dir)

But this got me thinking about a feature in wkTerrainSync where you can SELECTIVELY replace sprites for a custom terrain by simply including the .spr files with the terrain. wkTerrainSync supports replacing sprites from gfx0 and gfx1, so it's wise to include files for both.

So then I thought, wouldn't it be cool if you could upload just those changed .spr files so people could use them in wkTerrainSync for custom terrains if they wanted.
But then I found an issue.  wkTerrainSync merges the replacement .spr files with the gfx set that the player uses (gfx0 or gfx1) and so the palettes must match.  Your gfx.dir has a new palette so the replacement spr files wouldn't work directly, so I had to extract what I wanted to use and convert to the default gfx0 and gfx1 palettes.  This way, when people play the Halloween terrain, they will see the new animations regardless of if they use gfx0 or gfx1.

I changed wormhit1.spr so that it always shows blood (and I tweaked the image a bit), to go with the Halloween theme.

Quote from: kurs on June 28, 2025, 05:12 PMOh god! You are absolutely right, I did not want to offend those players who have vision problems, and therefore made a version with normal colors not for colorblind people, to be honest I completely forgot about it, but considering that I have very crooked hands, I will hardly be able to fix the palettes, I barely managed to cope with this volume, please take into account that I am a killer and not a coder, just an enthusiast))

I think we might be talking about different things but I see what you mean.  I was talking about the wkTerrainSync feature where you can replace individual sprites for a custom terrain rather than changing sprites globally.  But I've just had a look at the sprites and noticed that you've created a new palette for all assets so replacing individual sprites for terrains won't work so well without palette conversion.

But as an example, I've updated my Halloween terrain to include the Worms 2 death animation and the new blood animation.  I converted these sprites to the global (stock) gfx palettes for gfx0 and gfx1 : https://www.tus-wa.com/files/file-2415

So the Level.dir.txt file for the terrain has the following entries to replace the sprites :

gfx0\wdie.spr
gfx0\wormhit1.spr
gfx0\wormhit2.spr
gfx1\wdie.spr
gfx1\wormhit1.spr
gfx1\wormhit2.spr

Nice work!  It's worth mentioning that any / all of these new gfx0.dir elements can be integrated directly into a custom terrain, including the water.dir.  This is made possible with the wkTerrainSync module which will load and replace GFX0 and/or GFX1 elements that are included in a terrain for all players to see without any stock file replacement.

Example: If you just wanted to have the new dying animation in your custom terrain, you would include the sub folder and file "gfx0\wdie.spr" along with the usual files in your level.dir.

With this in mind, it might be worth adding the modified gfx0.dir contents on this post as well, as a ZIP.

Wait, so a player using hardware (a keyboard) that grants them an unfair advantage is not considered cheating in competitive games?  Anyone who thinks that this isn't cheating doesn't understand what cheating is.  Anyone who uses such a device in competitive games without announcing it first and having it agreed, is by definition a cheater.  And there's absolutely no difference at all between hardware and software performing the same 'cheat function' in this context.

Resorting to what is and isn't sanctioned in the competition rules as a defense is either a ploy to make a cheater feel better about their cheating, or it's just highlighting that the rules aren't sufficient to ensure fair play.

If people really want to get serious about fair play in a competitive game, all non-standard software and hardware in use should be declared at the start of the game.  That includes fancy keyboards, macros, all Wormkit Modules (including wkRempKeys) and any other external software.

I saw this on that WA 4chan page - I know Silkworm was Deadcode's cheat program back in the day, I'm not sure about this "Silkworm 2" though ?

https://i.4cdn.org/vm/1737530372982769.webm

It's an interesting topic but it feels a bit like screaming into the void. 

Sadly, cheating is always going to be a concern that everyone has to accept and move on.  Using tools that give a big advantage obviously isn't fair, but the person who uses them is kidding themselves; they know that they cheated and if they're serious about playing, their victory won't feel the same.  I like to think this puts prolific cheaters in the minority.

I suppose the elephant in the room is modules or loaders that hook the game's code.  The cheating possibilities here dwarf the concerns mentioned about roping.  Even anti cheat code in future updates could be patched out.  But it's not all bad; without gifted coders inspired to hack up WA and create dedicated cheat programs for fun we might not have Deadcode doing the great work he's doing with the game now.  Deadcode could have all manner of cheats running in his build during competitive games but I don't believe for a second that he does.

Quote from: TheKomodo on December 13, 2024, 01:33 PMYeah I've done that, any map I save just says "Error opening map file".

Odd! Can you post a couple of the PNGs from MapGen that are failing to load?

Quote from: FoxHound on December 12, 2024, 11:50 PMThen I don't know what I did that now I can't make it work again.

The images are in .bmp, they need to be .png for MapGen.

I'll be doing Urban Invasion next.  Meadow and Chocolate are finished.

Quote from: TheKomodo on December 13, 2024, 10:10 AMWhenever I save a map, it comes up failed to load in WA. Is there something you have to do for it to save properly?

I've not come across that issue.  I would maybe try deleting the "%appdata%\MapGen" folder, then firing up the latest version of MapGen.  Colours should be set to 96 (this is the default).

Quote from: FoxHound on December 11, 2024, 07:32 PMNot sure if I understood everything well, but if this update will allow the program to use custom terrains and make those terrains with doubled size, I will work right now on my scheme project Intermediate to the Power of 2 (Intermediate²). I would make a huge mappack on TUS and MonkeyIsland would probably suffer from headache when I do this.

All terrains still need converting to work with MapGen.  MapGen places objects and grass differently compared to the game so some stuff does need tweaking as part of the process.

MapGen themes live in the '..\data\generic\themes' folder.  All assets are PNG files.  You can use the "SpriteEddy" or "Sprite Editor" utilities to extract images from terrain files (level.dir) if anyone wants to do their own conversions.

Those links should work now Sensei.

Big thanks to Plutonic for the work on this.  Custom terrains will now display pixel-perfect. I'm working on converting most of my terrains across, or at least my favorite ones, to be included in a future release but I'll also drop them here when they're done.