since it's a long time that I don't release a new version of the RubberWorm module, and it's still a long way to version 1.0, I share with you a "pre-alpha", which has a new feature: aliased bounces.
I explain.
32624
the first image show how a grenade would bounce if launch it straight to the girder. In worms, the concept of slope doesn't exists, all the objects are composed of lots of pixels, each one with their vertical and horizontal surfaces, and it's on those surfaces that an object bounces.

With aliased bounces, an algorithm is used to calculate from a bunch of pixels a slope. So, the bounce is more realistic, like in this figure
32625

Actually, the second diagram shows the case where crash absorption, and friction do not matter. Instead, the last two figures show the real result: in the first case the absorption is greater than the friction, in the second it's the contrary. As far as I know, there are no objects that have less crash absorption than friction (unless you set it with RubberWorm, with the command /friction).
3262632627


This is a test build: so, no netplay, no stability, no full features. Anyway, alised bounces is always on (and cannot be turned off), so you can play it over internet with friends. You can test other stuff offline.
Expecially, you should try the new crateshower. Now, the /crateshower command takes an argument, that controls how many seconds the crates are dropped. Then, crateshower can work in conjunction with craterate. Finally, crates can be spawned while other crates are moving, and they never appear between turns.

Bug reports are highly appreciated. Please include the replay and also the file crash.dmp (located in the worms folder), if the problem was a crash.

**This module requires (for no reasons, at the moment) two other dlls: wkPackets.dll and borlndmm.dll. These dlls are part of the WormNAT2 module, shipped with Wormkit**

http://www.webalice.it/micioptah/test/wkRubberWorm.dll

Amazing! This could be great fun indeed I'll test it soon :D Good work!

Bug report!
If u fall in a clif with a specific direccion the worm keeps hovering till u use the chute.....if u dont have chute,endless turn.

thanks. I think that I will post here builds until at least this features is fully working.

Today my new super-pc has been delivered, so I have no more excuses to delay RubberWorm:o

This... is... AWESOME!

The physics for this should be made an option in official builds in the future!

http://fc07.deviantart.com/fs46/f/2009/211/4/a/imarvel_by_FxSanyi.png

This... is... AWESOME!

The physics for this should be made an option in official builds in the future!

http://fc07.deviantart.com/fs46/f/2009/211/4/a/imarvel_by_FxSanyi.png

That's essentially my reaction. vfn.

The physics for this should be made an option in official builds in the future!
Agree 100%.....this physics are better, if we didnt count the bugs xD

---------------------------------------------------------------------------------------------
Another bug
Custom grave (using a gfx), bounce loop ("6:XX to 8:XX" in the replay)

EDIT: nevermind.....the replay is messed up D:
EDIT2: there are a lot of bugs with the grave bounce take a look at that

Bug report
loop on mine bounce
The mines and the graves may cause crashes when bouncing
ED: also got a crash with a mine strike 2 times D:

Pointing something out if you aim straight down and throw a grenade on a worm it won't bounce unlike before!;)

Bug report
loop on mine bounce
The mines and the graves may cause crashes when bouncing
ED: also got a crash with a mine strike 2 times D:

Is that how you test by doing random things?

anything is useful.

Is that how you test by doing random things?
Is there other way to testing....
oh!....maybe i should make a giant table of possibilities with mines/worms/barrels,the diferent bounce angles and the different Wkrubberworm options specially for u (?)

For testing.....i always try the worst situation possible (For example spamming weapons)
BTW.....using earthwake has a high chance of causing "loop mines" D:

OK you are a good tester! :D

OK you are a good tester! :D

I dont think u can call me a tester.....i just found that bugs playing the game.....not testing at all.

The physics for this should be made an option in official builds in the future!

Agreed. But I don't think it will be an easy task, as it greatly affects the game logic, and it may need the engine to be rewritten.

I don't know what Deadcode and CyberShadow will say about this, though.

I don't know what Deadcode and CyberShadow will say about this, though.

Let Pisto handle it.

I don't know what Deadcode and CyberShadow will say about this, though.
They have both thought about aliased bounces much before me, and Deadcode wanted to implement it, I think in a testuff-like version.

Personally I think that the algorithm that I chose here is the best choice between ease of implementation and precision. It might have some unperfections (expecially cases where the algorithm itself fails and let the normal bounce happen), but these cases can probably be well foreseen by the player while playing, and this saves consistency and avoids excessive randomness, two things that's I have always liked in the w:a engine.

I couldn't explain this algorithm to Deadcode due to lack of time and english. He also makes a distinction betweeen anti-aliased bounces and aliased-bounces. I don't know what he is referring to, but after some wikipedia-learning I think that the correct name of this feature is anti-aliased bounces.

Btw, I noticed that it desynchs online. I believe that the problem isn't this feature though. So, stay tuned for next builds.

I like this (although I've not tried it yet). I think the bounce mechanics are an area where Armageddon could really benefit from improvement. As I understand the current algorithm, it doesn't bounce off horizontal and vertical surfaces, but bounces in whichever direction (horizontal or vertical) the object is moving fastest in. It seems like a fudge to me -- it's easy and safe but not remotely realistic. I never bounced things much because it never seemed to work, and that explains why. Proper bouncing physics like this would make grenades far more predictable and therefore useful.

Any kind of perpetual motion should be avoided by making sure objects come out of a collision with less energy than they went in. I gather that's not really in the spirit of RubberWorm but it works well enough in reality.

I like this (although I've not tried it yet). I think the bounce mechanics are an area where Armageddon could really benefit from improvement. As I understand the current algorithm, it doesn't bounce off horizontal and vertical surfaces, but bounces in whichever direction (horizontal or vertical) the object is moving fastest in. It seems like a fudge to me -- it's easy and safe but not remotely realistic. I never bounced things much because it never seemed to work, and that explains why. Proper bouncing physics like this would make grenades far more predictable and therefore useful.In the ccurrent algorithm pixel are really threated as sqare shaped surface. Given this limit, bounces are quite precise. And of course it's more likely a bounce in the direction in which the object is moving faster.
Any kind of perpetual motion should be avoided by making sure objects come out of a collision with less energy than they went in. I gather that's not really in the spirit of RubberWorm but it works well enough in reality.It is instead. A workaround like that is already present since the first version of RubberWorm, and is just an enhanced (because it is self-adjustable) version of something that's already in the default engine of w:a. The infinite bounce loops here will be fixed in the same way.

This version of the dll has merely the aliased bounces, and so it doesn't desynch in a network game (tested).

http://www.webalice.it/micioptah/test2/wkRubberWorm.dll

Awesome. :D

I couldn't explain this algorithm to Deadcode due to lack of time and english. He also makes a distinction betweeen anti-aliased bounces and aliased-bounces. I don't know what he is referring to, but after some wikipedia-learning I think that the correct name of this feature is anti-aliased bounces.pisto explained his algorithm to me today, and now I understand that it scans for two "corners" at most 8 pixels apart on one axis and 1 pixel apart on the another axis, meaning the slope it measures will always be a reciprocal of an integer (1/2, 1/3 ... 1/7, 1/8) or an integer (1, 2, 3, ... 7, 8). This means that the closest measured angles to 45° would be 26.6° and 63.4°, with nothing else in-between. This is certainly much better than the current bounce algorithm W:A uses, but I have mixed feelings about it (I would like the precision to be consistent).

I think the term "aliased bounces" is correct for describing pisto's algorithm, since it measures its slopes from aliased terrain (i.e., maps with a 1-bit alpha mask).

My idea of "anti-aliased bounces" would involve giving the terrain an anti-aliased mask, which would mean a very precise slope (1/256, 1/128, 3/256 ... 127/128, 255/256, 1, 256/255, 128/127 ... 256/3, 128, 256) could be measured from just two adjacent pixels. This would of course involve a much more extensive modification to the engine.

A nice compromise might be an "aliased bounce" algorithm that always scans 8 or so adjacent pixels, but does a cubic or higher-degree regression of the coordinates to get the slope at a given point. (A linear regression would give uncorrelated slopes too much an effect on the measured slope of the point being hit.)

On the other hand, making the algorithm as simple as pisto has done means it will be easy for players to predict a bounce, and that's a big advantage.

I don't know an algorithm for vectorization (if that is what you mean). Firstly, I'll finish the feature as it is now, then, maybe, I'll try to implement your idea.

On the other hand, making the algorithm as simple as pisto has done means it will be easy for players to predict a bounce, and that's a big advantage.

Wasn't that the reason you wanted to change the bounce physics in the first place, to make them easier to predict? Implementing realism into a video game doesn't always make a game better.

Wasn't that the reason you wanted to change the bounce physics in the first place, to make them easier to predict? Implementing realism into a video game doesn't always make a game better.

It pretty much does in the physics engine. You can get away with the odd fun tweak like improbable bouncing or gravity fields that don't correspond to reality (as in Mario Galaxy) but usually the more you can make it like reality without messing up your game the easier it will be for players to pick up.

At least, for that subset of players who live in reality. I realise that excludes some users here.

Wasn't that the reason you wanted to change the bounce physics in the first place, to make them easier to predict? Implementing realism into a video game doesn't always make a game better.
In this case I would say it's less about realism and more about expectations. The way WA handles grenade bouncing at the moment isn't really intuitive, and although it makes sense once you understand why it works the way it does, it's a nightmare when you first start tossing grenades.

I don't think games need to be realistic, and Worms is certainly far from realistic, but I can't imagine that anyone would expect a grenade/mine to bounce the way it does when they first start playing, and that can be frustrating.

I don't think people who would get frustrated over a design decision like this and quit the game because of it are the sort of people who should be playing computer games in the first place. Certainly not PC titles dating back to an era when men were still real men and played real games, not some sissified quick ego boosters... but this has little to do with this thread.

That's just me, though. I never liked the idea of sacrificing anything in an attempt to make obstacles that can veritably be overcome [resulting in great satisfaction in this case and many others] easier to overcome just because someone once thought it was too hard or envied those who have mastered it. It feels wrong from an evolutionary point of view. :(

I agree with KRD's sentiment - pick up any game from the early 90's and it will be at least a little harder than most you can buy off the shelves today.

I like the way pisto's algorithm works in this case - it's not so realistic and predictable that worms stops being fun, but improves the gameplay experience. There's still plenty of opportunity for wacky bounces and hilarious consequences - in fact, I don't think that has been mitigated at all.

EDIT: Here's an annoying little bug; if a worm dies and leaves a grave, the grave gets stuck in an endless loop of bouncing.

OK let me just clear something up first before anyone thinks otherwise (not saying that anyone here thinks this but you never know). I'm not saying that WA's physics should be changed now. That would be lunacy for such an old game. I also understand why WA's physics is how it is, back in the days when most computers might have struggled to run the game at a smooth 50 fps, bogging it down with more calculations for more accurate bounces would have made the game unplayable on many machines. With that out of the way...
I don't think people who would get frustrated over a design decision like this and quit the game because of it are the sort of people who should be playing computer games in the first place.
This is crazy talk. Video games have only become a popular form of entertainment because designers have realised that most people don't want to have to wade through confusion and frustration to get to the enjoyable bits. You could write the best story ever told, but if you spelt half of the words wrong, nobody would read it.
That's just me, though. I never liked the idea of sacrificing anything in an attempt to make obstacles that can veritably be overcome [resulting in great satisfaction in this case and many others] easier to overcome just because someone once thought it was too hard or envied those who have mastered it. It feels wrong from an evolutionary point of view. :(
More realistic grenade bouncing wouldn't alter this in the slightest. Most of the people who I know in real life who have played WA (i.e. not the people from the hardcore Worms community here) just don't throw grenades because they don't work in a way that appears sensible to them. I couldn't use grenades in the time between Worms 2 and WWP because the bouncing seemed wrong. It took me forever to understand how it was working (maybe I'm dumb) and I believe I'm in the majority here. The masters would still be able to pull off awesome shots that make everyone go "woah!", but the majority of players would at least be able to get grenades roughly in the area they want them to go, and so hit somethnig now and again. Why is this a bad thing?

The best games are easy to play but hard to master. Grenades aren't easy to play with.
I like the way pisto's algorithm works in this case - it's not so realistic and predictable that worms stops being fun, but improves the gameplay experience. There's still plenty of opportunity for wacky bounces and hilarious consequences - in fact, I don't think that has been mitigated at all.
I don't understand how a more predictable physics engine stops things from being fun? Wouldn't it make things more fun? Does a game like Peggle suck because the ball doesn't act in the way that everyone assumes it will, all the time? Isn't the fact that you can sort of guess how things are going to play out from a shot you're about to take supposed to be the entire point of Worms, where you're encouraged to try and use skill to pull off ridiculous shots? When a grenade doesn't bounce the way you expected it to, it's normally not very fun at all.

play the game and use grenades and it becomes obvious how they work and you can then use them to pull off good shots. Think of it as physics for an alternate reality.

Anyone starting a game and expectiing realistic physics will only set themselves up for disappointment until more games start using PhysX etc.

i support this however i'd be more inclined if it were an option than a change. I have nothing against the current physics, it's fun sometimes when the grenades don't bounce the way they should. Other times it's frustrating but I still enjoy it. Much like anything else it should simply be a scheme option and hosts can use it if they want to.

That's my opinion too. A scheme setting would be perfect.

That's my opinion too. A scheme setting would be perfect.
remember, this is a test, pre-pre-alpha build. A settings will be there in the final version of course. RubberWorm, as it is now, will be able to be loaded and still be compatible with non-rubber players.

I meant as an option to be included in the official beta builds from now on.

In fact, the rubber options should be too. It's a great feature and it's loads of fun.

Wow! Great module! Best work, Pisto! But at all versions of a rubberworm there is an unpleasant bug: when rubbreworm features are enabled, from the weapon list some superweapons vanish, and these weapons can be received only from crates... (screenshots in attachment) :(
You can fix this?
With impatience I wait a release version ;).
////Sorry for my bad english..

for armageddon and indian nuclear test, it might be that the crate probability (used by RubberWorm to store its scheme data) affects the ammo in some way. This is not the case of earthquake though, it is never touched:eek:.

RubberWorm, as it is now, will be able to be loaded and still be compatible with non-rubber players.

OMG!!!!........ thats fc***ing orgasmic!! D:

But it's fact :(. There is no difference, enable one option or all at once. These weapons missed only. :(. Scheme extracted from replay contains all weapons, as well as it is necessary. But in game these weapons has no present :(. 3 schemes in attach (2 options enabled (sdet, ldet), all options, 0 options). In all schemes, ammo of weapons established to infinity...

I know, but I don't know the cause. Next RubberWorm won't tamper the wsc scheme files.

for armageddon and indian nuclear test, it might be that the crate probability (used by RubberWorm to store its scheme data) affects the ammo in some way. This is not the case of earthquake though, it is never touched:eek:.But it's fact :(. There is no difference, enable one option or all at once. These weapons missed only. :(. Scheme extracted from replay contains all weapons, as well as it is necessary. But in game these weapons has no present :(. 3 schemes in attach (2 options enabled (sdet, ldet), all options, 0 options). In all schemes, ammo of weapons established to infinity...With RubberWorm, those three weapons do get removed. But without RubberWorm, they don't (using the same WSC files). So it's a bug in RubberWorm, not any direct effect of changing the crate probabilities.
I know, but I don't know the cause. Next RubberWorm won't tamper the wsc scheme files.You'll continue to use the same format of storing settings in unused superweapon crate probability bytes, right?

Is there a reason why everyone desyncs after enabling craterate and cratelimit? All I want is more crates in worms armageddon without people desyncing.
I have also tried editing the CRATE option under scheme. I click the skunk which shows super weapons and make sure they don't have a crate next to them, but everyone still desyncs right at the beginning of a game only when using rubberworms.

Is there a reason why everyone desyncs after enabling craterate and cratelimit? All I want is more crates in worms armageddon without people desyncing.
I have also tried editing the CRATE option under scheme. I click the skunk which shows super weapons and make sure they don't have a crate next to them, but everyone still desyncs right at the beginning of a game only when using rubberworms.

all players need to be running rubberworm, you know that, right? and also the same version of wkrubberworm.dll :p

all players need to be running rubberworm, you know that, right? and also the same version of wkrubberworm.dll :p

Thanks for the advice. I think I got confused because the first post said non-rubberworms compatible, but I guess he was talking abou the physics only?

Thanks for the advice. I think I got confused because the first post said non-rubberworms compatible, but I guess he was talking abou the physics only?

The first post actually says there is no netplay support at all in this preview version.

The first post actually says there is no netplay support at all in this preview version.

So that means I can't use this online even with rubberworms 1.0 players?

correct, no beta v1.0 player can play it online at all until the final version 1.0.

in this version aliased bounces is always on. so you can play online, just against players using this version, and it will always desynch with normal (or normal rubber) players.

franpa, there will never be a complete version of this.

in this version aliased bounces is always on. so you can play online, just against players using this version, and it will always desynch with normal (or normal rubber) players.

franpa, there will never be a complete version of this.

Maybe I have the wrong idea of desyncing, but how can you play against the players if they desync? Whenever I try to play someone even with this version as soon as the game starts they can move around for 5 seconds and then the white flag comes up and says they've been disconnected

Unless specified otherwise, all players must have the same version of RubberWorm. W:A only sends the keyboard/mouse input over the network. RW patches W:A to modify how the physics work, it can't magically send itself over the network so the exact same thing would happen on their computer.

You can check the disconnect reason (incl. desyncs) by looking at the chat panel.

W:A only sends the keyboard/mouse input over the network. RW patches W:A to modify how the physics work, it can't magically send itself over the network so the exact same thing would happen on their computer.

I understand that because RW is kind of like a hack in the way it modifies the team17 data so I know they have to have the same version. My thing was, we both have 1.0 and my friend moves around and then desyncs. I was just wondering what that was not how RW works, but thanks for the advice.

so, probably it is a bug. This version is full of them, it is only a "proof of concept"

Bug is always possible, but I was thinking since this is kind of like a hack will they start banning people for using it?

Because I can't connect to Wormnet anymore. It happened a day or two after I used RW.

No, they don't ban you for it because there is no ranked servers. If ranked servers were to be implemented and you use this to "cheat" then you would be banned.

Make sure your friend and you both run Wormkit.exe.

No, they don't ban you for it because there is no ranked servers. If ranked servers were to be implemented and you use this to "cheat" then you would be banned.

Make sure your friend and you both run Wormkit.exe.

Ya, I would hope they would not ban me for it, but last time I logged in it said they monitor what clients (wormkit) you use to login wormnet and said you would be banned.
That was there MOTD.

Yes, that is primarily aimed at people using bots to advertise and spam.

Cybershadow, one of the people who still updates W:A created Wormkit, so I don't think he's likely to ban you for using the tool he made in the first place. :D

Wow! Great module! Best work, Pisto! But at all versions of a rubberworm there is an unpleasant bug: when rubbreworm features are enabled, from the weapon list some superweapons vanish, and these weapons can be received only from crates... (screenshots in attachment) :(
You can fix this?
With impatience I wait a release version ;).
////Sorry for my bad english..
So it's a bug in RubberWorm, not any direct effect of changing the crate probabilities.
I've been asked again about this issuse, so I ran some tests, and I found out something interesting.

It is not a bug of RubberWorm, but it's a feature of W:A. When sdet is on, those weapons with "global effect" do get removed in armory and crates. You can guess why: if you have one of those weapons and a couple of tools to hide one or more of your worms, you can destroy the enemy teams with too much ease, so that getting one of those in a crate would be an "unfair" luck.

There is a way to enable those weapons even if sdet is active, but I won't release a new RubberWorm before the next beta update. So I made a trainer which must be activated before the game starts, and by all the players of an online game.
http://pisto.xoom.it/SuperWeaponsWithSdet.exe