PDA

View Full Version : Was Playing Around With Worms And Some Interesting Things Happened


PharmD4.0
10 Jan 2008, 03:50
I am sure I am not the only one that has ever does this but sometimes it is fun to build a worm cannon and annihilate worms with banana bombs :) Well I was setting this board up by dropping worms down a narrow pit with the intent of putting a banana bomb at the bottom and launch the poor little guys :) The board is set up with 48 worms and as usual when a worm is dropped onto a large number of worms they take a little longer to hit the ground as it 'hits' all the worms and they all say ouch. However on the last worm drop the game gets stuck in a loop and the worm never hits the ground they just continually hit each other over and over. I let it run for like a minute just to make sure and it never went. So I tried to forced sudden death and that didn't do anything either so I just quit the game. The interesting thing is if you view the replay it never ends, the replay just goes on forever you can even do 'Playback at.." like at 5 hours and it still keeps going. I did the same setup a second time and it did the exact same thing when the last worm is dropped. Not like this comes up in an everyday game just thought it was kind of interesting.

I also noticed that even though all the worms are dropped from the same height the amount of damage they take increases as the number of worms increase. i.e. The first worm that gets dropped takes 10 damage points for the fall and increases to 11 points on the fourth worm and increases every couple of worms. So that on the last couple of worms they are taking 37 and 38 points of fall damage.

Cybershadow is that a bug or are the additional worms supposed to cause additional damage? I was wondering if the amount of damage they take is based on the amount of time they are free falling or based on the height they fall. In this case they all fall from the same height but take longer to hit the ground because of the delay when they hit a large number of worms so it might think they have fallen from a further height.

PharmD4.0

PharmD4.0
10 Jan 2008, 04:03
Forgot to mention that it is the newest release of Worms 3.6.28.0 (Beta).

PharmD4.0

CyberShadow
10 Jan 2008, 06:04
Thanks for reporting - we'll look into it.
(I guess that's a bit like extreme crowd-surfing).

bonz
10 Jan 2008, 20:02
Yay! :D
First the pixel-gliding and now crowd-surfing!

This game never gets boring. I wonder what will come next.

PharmD4.0
10 Jan 2008, 20:52
I missed the post about what pixel-gliding is, I will have to check that out! Don't worry I am working on finding the next new thing as we speak :)

Happy Worming!
PharmD4.0

Plasma
10 Jan 2008, 21:15
I dare someone to try do a full crowd-surf by choosing a map with a shallow pit, filling it with worms, and then trying to get a worm to 'bounce' across it.

franpa
10 Jan 2008, 22:54
is the surfing to do with skimming over a single pixel at the apex of your forward jump?

Muzer
11 Jan 2008, 07:23
Since I can't be bothered to watch the replay, what's it all about?

CyberShadow
11 Jan 2008, 07:43
Yeah, since your time is obviously much more important than everyone else's.
Just WTFR ;)

Plasma
11 Jan 2008, 08:05
Since I can't be bothered to watch the replay, what's it all about?
Aw, c'mon! He even explained what happened himself in the first post!

bonz
11 Jan 2008, 09:44
I missed the post about what pixel-gliding is
If you jump with your worm to the left and you hit a pixel that is at a certain height (the highest point of the worm's jump), your worm won't land on the pixel, but glide over it (still with the jumping animation).
This can in fact be continued over 5(?) pixels, if they're set up deliberately. (Check out DC's teststuff map for that!)
It does however also happen ocassionally in normal maps. You'll notice that when your worm has a strangly longer jump than usual.
Also, since the worm is technically in the air continually, you can use all the weapons that you can use in mid-air or drop from a rope.
Another fun fact:
In Worm 4 Mayhem there is also some sort of gliding.
If you jump onto a sloped surface (e.g. a log), your worm will slide down it and you can even control its direction a bit.
This was programmed on purpose though, I believe, but I wonder if the Teamsters were inspired by the pixel-gliding from WA, since it's been known for a few years now.
I shall upload a replay of the pixel-gliding soon.
Aw, c'mon! He even explained what happened himself in the first post!
He probably can't be bothered to to read that long post either... :rolleyes:

franpa
11 Jan 2008, 12:25
is the surfing to do with skimming over a single pixel at the apex of your forward jump?

i kinda already explained it bonz ;\

GrimOswald
11 Jan 2008, 12:35
i kinda already explained it bonz ;\

Yeah, but he kinda explained it better. ;)

Besides, what you said was a question, implying that you were not sure. Not to mention it was confusing. And stuff.

bonz
11 Jan 2008, 13:18
Yes, but I indeed explained it better, mentioning all the details.
For example that it only works when jumping to the left.
And that it works over more than one pixel.
And that you can use droppable weapons.

Another thing I forgot was that you have to prepare the correct starting point of the jump.
If you want to get it right every time, you need to align by doing a backflip against a wall, then from the point where you landed you need to do a single tap forward, then jump.

BTW, did I already mention that a pixel-gliding game scheme would be fun?
I was thinking about a map with several of DC's pixel setups where you have to climb up, to the pixel-glide and drop a dynamite onto a target below.
Then advance to the next gliding station.
If you mess up the jump, you'll fall through the pixels and will get all the dynamite on your head.
Also, if you fail to drop the dynamite (and place it onto one of the pixels), you'll need to get back up and repeat.
And stuff.
And franpa. :rolleyes:

CyberShadow
11 Jan 2008, 14:38
It doesn't have to be at any specific point in a jump. And (I think) the worm doesn't need to be jumping. And (I think) it doesn't even have to be a worm - any object moving to the lower-left.

Deadcode probably knows a lot more about pixel glides. I used to know more but I forgot, and I can't bother looking it up again...

bonz
11 Jan 2008, 15:13
It doesn't have to be at any specific point in a jump. And (I think) the worm doesn't need to be jumping. And (I think) it doesn't even have to be a worm - any object moving to the lower-left.
Ah! Didn't know that.
Using a jumping worm is the most easy one to recreate though and also the way Deadcode showed me.

Now I'd like to see a mine, an oil barrel or a crate gliding over a full set of pixels.
The latter two have a nasty habit of exploding should you try to shove them over the pixels by force. :D
Deadcode probably knows a lot more about pixel glides. I used to know more but I forgot, and I can't bother looking it up again...
Yeah!
Seems to me he needs to continue gutting the innards of WA again.

KRD
11 Jan 2008, 16:04
Now I'd like to see a mine, an oil barrel or a crate gliding over a full set of pixels.
The latter two have a nasty habit of exploding should you try to shove them over the pixels by force. :D

Earthquake is your friend. Good luck controlling it, though. :p

#ffc700
11 Jan 2008, 16:08
I guess everyone here knows this replay,
but as you said you wanted to upload a pixel glide ...

here you go :))

PharmD4.0
11 Jan 2008, 16:52
Wow I hope Deadcode used the frame by frame replay editor tool to get that one to work! I can only imagine how many times I would have missed that first pixel coming off the rope like that :) Interesting replay though.

PharmD4.0

Plasma
11 Jan 2008, 17:22
Another fun fact:
In Worm 4 Mayhem there is also some sort of gliding.
If you jump onto a sloped surface (e.g. a log), your worm will slide down it and you can even control its direction a bit.
This was programmed on purpose though, I believe, but I wonder if the Teamsters were inspired by the pixel-gliding from WA, since it's been known for a few years now.
It's much more likely there to represent how, in real life, you're not supposed to be able to stand up on a steep slope!
Although there is 'some' form of gliding in the game. If a worm manages to, luckily, get blasted onto the top of a pointed log walls, moving along the wall, then they can keep gliding across the entire wall, even with a small push.
However, considering how the majority of the pointed walls in the game end out just before the sea, it's not very fun if it happens to your worm.

Deadcode
17 Feb 2008, 04:35
Firstly... very nice bug find, PharmD4.0, and thanks for reporting!

Also... what an incredible coincidence that it's only the 48th worm that goes into an infinite loop!

Wow I hope Deadcode used the frame by frame replay editor tool to get that one to work! I can only imagine how many times I would have missed that first pixel coming off the rope like that :) Interesting replay though.

PharmD4.0I did more than just that... I wrote a program to enumerate all possible glides, with the initial velocity as a variable. This program would tell me the range of velocities that would get me each glide (a pretty narrow range), and I would then have to reach that velocity. At first I used the jetpack, but that has a speed limit. It took many tries to get the proper rope velocity, but once I did, my special modified W:A created the glide pixels as my worm moved (which I then solidified into an actual map). It needed to happen this way because even within the narrow range of speed, even a infinitesimal difference would mean all the pixels would have to be moved. (So no, a 32-glide could not be featured in any non-tool-assisted gameplay scheme.)

The only limit was the map size, 1920x696. With a big map, I could do far more than 32 glides. The limit would become the maximum rope speed.

Deadcode
17 Feb 2008, 05:30
Now I'd like to see a mine, an oil barrel or a crate gliding over a full set of pixels.
The latter two have a nasty habit of exploding should you try to shove them over the pixels by force. :D

Earthquake is your friend. Good luck controlling it, though. :p

Sadly the glide glitch only happens with worms. Half of what makes it happen is in the projectile collision code, but the other half is in the worm collision code.

bloopy
17 Feb 2008, 23:23
The only limit was the map size, 1920x696. With a big map, I could do far more than 32 glides. The limit would become the maximum rope speed.

I look forward to seeing that. :p

PharmD4.0
18 Feb 2008, 04:26
Deadcode or CyberShadow were you able to figure out why it was occuring? I just love to hear about the inner workings of worms and why stuff happens and how you guys fix it :)

PharmD4.0

#ffc700
18 Feb 2008, 08:18
The only limit was the map size, 1920x696. With a big map, I could do far more than 32 glides. The limit would become the maximum rope speed.I look forward to seeing that. :p

Me too :D
And as you will know, Deadcode, with the address WA.exe+52B824 set to that specific value there is no rope speed limit!
I therefore would like to see a biiig pixel glide, limited again by the now bigger mapsize =D

I'm not quite optimistic, though.
Sounds like a lot of work, dunno whether it's fun :P

Muzer
18 Feb 2008, 08:24
Everyone viewing the replay will have to set that, though.

#ffc700
18 Feb 2008, 08:45
That's not right!

I don't have much experience with this stuff (a friend of mine is testing around there),
but everyone is able to view replays with that value changed.
You're right for example if you look at that "weapons don't end turn"-value, though.

CyberShadow
18 Feb 2008, 08:52
That address makes no sense neither for 3.6.28.0 nor 3.6.26.5.
Also, what Muzer said.

franpa
18 Feb 2008, 09:27
the address he speaks of just changes what version/engine the game uses. and replays are fully viewable when this value is changed since the version emulated is stored in replays.

#ffc700
18 Feb 2008, 10:56
What franpa says!!

I'm just playing around with this stuff,
my friend tells me the addresses and values ^^

Muzer
18 Feb 2008, 11:51
Ah, so it's like OVG

pisto
18 Feb 2008, 12:24
it's the address in the form that cheatengine shows (WA.exe stands for "base address of wa.exe", 0x400000), it controls the engine version. 0x41 is teststuff3 with big maps support.
and teststuff3 has no limit on roping speed.
but why are we speaking of that gliding stuff instead of the bug shown in the first post?

Deadcode
18 Mar 2008, 00:37
Ok, here's an explanation for the infinite loop, bringing this thread back on topic!

A projectile (such as a falling worm) can only collide with two things in one frame. If it collides with two things, its continued motion is postponed until the next frame.

A standing worm, hit by a falling worm, will commence the "Getting Up" animation. During this animation, any falling worm will fall right through it without interacting.

Thus, a falling worm will "hover" until it has hit each and every worm in a pile; on each frame it hits two worms. During this time its velocity increases (so it isn't true hovering); once it hits the ground it will hit harder than it would have if it hadn't "hovered" above the worm pile.

However, once a worm finishes its "Getting Up" animation, it once again acts as an obstacle to falling worms. So if there are enough worms in a pile, a "hovering" falling worm will not have time to hit each worm before one it already hit finishes the "Getting Up" animation; in this case there will always be worms in the pile that act as an obstacle, keeping the falling worm "hovering" forever.

(It's actually a bit more complicated than that, but the gritty details don't change the essential explanation.)

One solution would be to remove the 2-collision-per-frame limit. The possible side effects of such a change need to be fully investigated, though, because it could make possible a totally different infinite loop bug! (If this is true, then merely increasing the limit to something like 64 could result in some conditions where the game slows down immensely — which would not be desirable either.)

Of course, increasing the limit from 2 to 3 would prevent an infinite loop from being possible, but only because of the 48-worm limit; and the "hovering" bug would still exist, just in a slightly attenuated form. Such a solution would be an ugly workaround.

PharmD4.0
19 Mar 2008, 03:20
It would be interesting to be able to exploit this bug and have the loop go on for a couple of minutes and then pull a worm out of the pile and have the hovering worm hit the ground at about Mach 3 to see what kind of damage it would take and embed itself a couple feet into the terrain :) Anyway you could arrange a replay of that Deadcode? That would be hilarious!

PharmD4.0

Etho.
19 Mar 2008, 04:36
The game has limits set as to how much fall damage can be given. The maximum damage your worm can receive with the standard fall damage setting is 67.

PharmD4.0
19 Mar 2008, 04:59
Well that just doesn't sound as fun and exciting now does it! Thanks for raining on my parade :)

Deadcode
20 Mar 2008, 20:54
It would be interesting to be able to exploit this bug and have the loop go on for a couple of minutes and then pull a worm out of the pile and have the hovering worm hit the ground at about Mach 3 to see what kind of damage it would take and embed itself a couple feet into the terrain :) Anyway you could arrange a replay of that Deadcode? That would be hilarious!That's an awesome idea, and Etho was a bit hasty to rain on your parade! With TestStuff5, there's no maximum projectile speed and the maximum fall damage should be 1820, acheived after about 55 seconds of acceleration... so yes, I think your idea is doable!

Plasma
20 Mar 2008, 21:26
With TestStuff5, there's no maximum projectile speed
Wouldn't that give some high-velocity projectiles the ability to skip through small land masses due to the collision mask being too small to check for terrain between steps?

Deadcode
20 Mar 2008, 21:30
Wouldn't that give some high-velocity projectiles the ability to skip through small land masses due to the collision mask being too small to check for terrain between steps?The collision algorithm checks almost every pixel between the two positions of a projectile on consecutive frames (these in-between positions are interpolated). If it didn't do that, even the maximum rope speed of 16 pixels per frame would sometimes allow a worm to go through things horizontally (since its mask is only 9 pixels wide).

The Super Sheep is not treated as a projectile, and it can go through things.

Plasma
20 Mar 2008, 21:43
The collision algorithm checks almost every pixel between the two positions of a projectile on consecutive frames (these in-between positions are interpolated). If it didn't do that, even the maximum rope speed of 16 pixels per frame would sometimes allow a worm to go through things horizontally (since its mask is only 9 pixels wide).

The Super Sheep is not treated as a projectile, and it can go through things.
Ah, it was just the Super Sheep. I thought every projectile went through very thin pieces of land.

Melon
20 Mar 2008, 23:46
I thought every projectile went through very thin pieces of land.
You can fire all of the F1 row weapons except the sheep launcher through a tiny patch of land, provided you're standing next to it. At first I thought this was a way of preventing projectiles colliding with the worm when the projectile is created*, but it doesn't happen for the other weapons, so it's a bit wierd.

*What I mean is that if you always create the projectile at a distance of, say, 20 pixels away from the centre of the origin of the worm, then you can always guarantee the collision masks will never cross regardless of the angle you fire it at.

franpa
21 Mar 2008, 01:03
It's most likely done so the bullet doesnt spawn on the gun and instead spawns at the end of it.