Hey,
I just wonder when we (ropers) will have a new rope collision mask ?!
I mean for people addicted to rope races, it's very frustrating to see our rope going trough walls !!

Ok I agree, this poll is not helpful :D.
In fact it's just for fun, to see how many people are frustrated too because of this !

Oh and I guess it's not going to be solved soon, because I think that it may cause issues with people having a non updated version of the game, who won't see the same thing happen on their screen, because actions will be different from a updated game and a non updated game, causing desynch (not sure it will close the game and disconnect players (like we know it actually)).

So, this post is here to carry a hope ! And maybe a solution ? :)
Here is a replay to show you what I'm talking about :P !

Thx for reading.

Rope collision isn't unpredictable at all. Do you see how the rope is divided into little segments, 8 pixels long? For performance reasons, the game checks for collisions only at the edges of these segments.

Rope collision isn't unpredictable at all. Do you see how the rope is divided into little segments, 8 pixels long? For performance reasons, the game checks for collisions only at the edges of these segments.

Hmm okay ^^, I know there was a reason, i just turned it this way to add conversation and details. By unpredictable, I meant that in roping situation it's not really predictable.

I agree with this performance issue, for computers as old as the game is, but now most of them should really easily handle the physic engine with no any problems. :cool:.
Can we (still ropers community :D) hope that in future (soon or later :D) this might be changed in something more comfortable ? :o.

how about to build some bug free maps? including walls > 8 pixels. can't be that hard and probably only can help building some nicer looking roperace maps.

i came across that issue, when building maps with pixels to rope on - easily solved with a) a bigger diameter of the pixel or b) filling out the pixel, if it was actually big enough but black on the inside.

i came across that issue, when building maps with pixels to rope on - easily solved with a) a bigger diameter of the pixel or b) filling out the pixel, if it was actually big enough but black on the inside.

Yes, everybody know that, but it's not my point. We could have a diameter of 1px, that it could work if we multiple its collision checking size by 8.

It will add more precision to everybody, and not only in rr. Don't you ever have seen a rope getting stuck in a pixel ? :D

It's been like this for a decade, so why change it now?

It's been like this for a decade, so why change it now?

Because as you said, it's as old as the game is...
Why not change it now ? As the game is still being updated, I think it's now or never =).

Because as you said, it's as old as the game is...
Why not change it now ? As the game is still being updated, I think it's now or never =).

yep...the game is still being updated.....but they dont update things that can affect game play (like editing weapons or adding new ones).

In my opinion, it's more like correcting a bug... This was obvious, or maybe, that in the past this bug was necessary, but now, as we can without any doubt, why not ?

it probably all depends on the kind of performance impact 16 pixel long segments would cause...

yep...the game is still being updated.....but they dont update things that can affect game play (like editing weapons or adding new ones).

Many weapon bugs have been fixed in the last dozen updates :)

it probably all depends on the kind of performance impact 16 pixel long segments would cause...

You've got the wrong end of the stick here franpy; It's the 8 pixels in between the collision-checking edges that are the problem devolution is discussing :P

Many weapon bugs have been fixed in the last dozen updates

I know.....but this isnt a bug at all.....if they increase the size of the rope pixels to fix this problem they rope will become solid (nonflexible) or less flexible than now.

It's the opposite, if you reduce this 8px of non colision to 1px, you will have a better flexibility on the situations I showed in my replay, and it won't change anything particulary in other situations :

Imagine, you are roping and your rope is 500px long.
Let's say we change this "8 pixels in between the collision-checking edges" size to 250.

I think you agree that your rope will only have a flexibility in its center don't you ? :).

I agree even though I am not a roper.
The high chances of rope not-getting attached to very small pieces of land and/or getting stuck on a pixel it went through like 10 times (right during the swing you planned to release the rope and make a flight) are quite annoying.

Edit: /me slaps himself
Although if this "fix" means the rope being more stiff (therefore affecting the rope physics we are all used to) then I have to say I am 100% against it.

Although if this "fix" means the rope being more stiff (therefore affecting the rope physics we are all used to) then I have to say I am 100% against it.

It's the extreme opposite, isn't it ? :)

I thought this was a petition to add a jack the ripper mask to worms when they were roping around.

Now that's something I could get behind with.

Seems like people are not reading Cybers reply. Text demonstration time.

O = Visible sprite pixel of the ninja rope
X = Flexible connection in between these sprites

X Collides with solid objects and O does not.

The current Ninja Rope is formed:
XOOOOOOOOXOOOOOOOOXOOOOOOOOXOOOOOOOOX etc.

Devo is suggesting these spaces in the collision masks are reduced. I.e.
XOXOXOXOX etc., or even XXXXXXXXX etc.

XOXOXOXOX: more flexibily (agree with that)

XXXXXXXXX: a girder lunched from worm?

XOXOXOXOX: more flexibily (agree with that)

XXXXXXXXX: a girder lunched from worm?

There is one very important question implicit in my previous post that Dev0lution doesn't seem to understand:
Do rope-pixels collide with other rope pixels?.
So far I've never seen the rope colliding with itself, worms, oil drums or weapons, so I would think the answer is no. But I might be wrong.

I think most of us read what "the guy with the hunter avatar" wrote, and probably most of us never understood that with "performance" he was talking about the rope flexibility due to rope pixels colliding with other rope pixels.

i think rope pixels just colide with nearby rope pixels other way the effect of flexibility in rope would be imposible.

ooo[c]ooo
ooo[b]ooo in that case "a" collides with "b" but no with "c"
ooo[a]ooo

[a] [b] [c] rope pixels

You've got the wrong end of the stick here franpy; It's the 8 pixels in between the collision-checking edges that are the problem devolution is discussing :P

True, you want to halve (or better) the number of pixels between collision checks and this will double the number of calculations needed to work out how the rope should interact...

Still, I believe the deciding factor for this feature is the performance impact the change will have.

.
So far I've never seen the rope colliding with itself, worms, oil drums or weapons, so I would think the answer is no. But I might be wrong.


Good answer ;).

Thank you GreeN for your explanation, this is exactly what I meant ! :cool::cool:.

Franpa, I really don't think that a decent CPU would be overloaded to calculate something that is, sorry about that, ridiculous, in my opinion (one more time, correct me if I'm wrong). ;)

Franpa, I really don't think that a decent CPU would be overloaded to calculate something that is, sorry about that, ridiculous, in my opinion (one more time, correct me if I'm wrong).
true, but keep in mind that there are still quite a few players out there using pentium 2 machines which may not be able to handle such a change to the rope.

true, but keep in mind that there are still quite a few players out there using pentium 2 machines which may not be able to handle such a change to the rope.


* Pentium 100 MHz processor (Pentium 150 MHz recommended, Pentium II at 200 MHz optimal)

I really really don't think that people play Worms with as old CPUs, I guess I can be wrong again ;), even if I'm sure that at least 95% aren't anymore (At least for online players !)

Where's the "I Don't Care !" option?

Performance is important, even on new machines. See my topic in the support section - I can't play at max resolution because my CPU isn't fast enough (2.4GHz Intel Core 2 Duo). Considering this is a minor issue, it's probably not worth it.

Performance is important, even on new machines. See my topic in the support section - I can't play at max resolution because my CPU isn't fast enough (2.4GHz Intel Core 2 Duo). Considering this is a minor issue, it's probably not worth it.

:/ W:A runs fine for me @1920x1200 on a computer using a 2.53GHz Intel Pentium IV processor...

different processor architectures are good at different things.

Dude Worms runs on 133 MHz machines, there's actually no way your 2.4 GHz Duo Core can't handle it.

Yeah, at that resolution? I doubt it.

His graphics chip probably lacks some, so all the physics calculations and all the graphics ones are being loaded onto his CPU. He might also have a bunch of background applications too.

I believe theres something a pentium 2 does substantially more efficient then a Core 2 DUO. the Core 2 DUO wins in raw speeds when it comes to most things it is inefficient at.

robowurms, unless your using a video card older then a Nvidia TnT 2 or something similar, your video card should be handling the graphics.

He might also have a bunch of background applications too.

That only has impact over the RAM. If those applications don't stress the CPU while being idle, they won't stress it while playing worms (unless some services go crazy when going on-line).

Some processes can cause screen lag even without showing a noticeable CPU usage. This can be caused either by short spikes of CPU usage, or by hogging other resources (such as I/O).


About a year ago, I wrote a program that lowers the priority of most processes. I noticed that it helped reduce screen lag and increase FPS. Please use this at your own risk, since it messes with your system processes' priorities (which, according to Task Manager's warnings, could lead to system instability): Download (http://dump.thecybershadow.net/be439db96530f40b346e3829518e5b63/gamemode.exe), source code (http://dump.thecybershadow.net/349e7b7fb5466d97ba3177d66c5712e2/gamemode.dpr).

Regardless of background processes currently running, their priority, CPU usage and available memory, some occurrences in a game of WA just bring my laptop to its knees, in spite of the fact that it surpasses the recommended system requirements by at least four times [even with the CPU throttled to run at only 800 MHz]. The most noticeable of these are the Skunk and Suicide Bomber gas clouds. Another are large amounts of fire and/or explosions. Yet another is roping through PNG maps above a certain size limit. Throw in full background detail, a couple of exploding mines and very quick worm movement, and you have a recipe for disaster...

I'm guessing this is something that could be "fixed" through recoding the way those events and their effects are calculated and displayed, but I very much doubt it would be worthwhile in the long run and I would actually be against it if the maintainers decided to spend time on getting it done [unless it was only a side product of a larger fix and great care was paid to not changing the physics even a little].

The game, fully updated, runs great on old but well-maintained machines right now; I believe this is something we should applaud David and Vladimir for. However, this is really no reason to ask for features that work against this simply because your computer could probably handle it. Especially something as experimental as altering the way the most versatile and popular utility in the game works! Generations upon generations of awesome players have proven that the Ninja Rope is beautiful the way it is now; changing it would be a crime. And don't even mention making it an option, that'll only tick me off more. :p

Just my lighthearted, not entirely on topic €0.02.

Regardless of background processes currently running, their priority, CPU usage and available memory, some occurrences in a game of WA just bring my laptop to its knees, in spite of the fact that it surpasses the recommended system requirements by at least four times [even with the CPU throttled to run at only 800 MHz]. The most noticeable of these are the Skunk and Suicide Bomber gas clouds. Another are large amounts of fire and/or explosions. Yet another is roping through PNG maps above a certain size limit. Throw in full background detail, a couple of exploding mines and very quick worm movement, and you have a recipe for disaster...
It's sounds more like your graphic card and your RAM aren't powerful/big enough. I don't think this is about the CPU calculation (Well it is, but it might be interesting to check how optimized graphics are.I could try to fire as many skunk I can in one turn and see how much my GPU/CPU can handle it, then you do the same and we check, compared to our PC's configuration, if there is a big % of difference (As W:a uses only one CPU, even if I've a Quad core I don't think other 3 cores are used for any threads of wa.))


The game, fully updated, runs great on old but well-maintained machines right now; I believe this is something we should applaud David and Vladimir for. However, this is really no reason to ask for features that work against this simply because your computer could probably handle it
Well, there is nothing about the fact that my computer could handle it or not. My point is that it is a bug, there is no any logic that what happens, happens :D.
I really wondered a try could have been done, but obviously, evolution seems to scare some of you (ye, I know, this is all about performance, but no one of us know how harder it's going to be for our CPU without letting CyberShadow try it and compare !).

And,
changing the rope the way I would like it to be will not change roping at all in every situations ! The real difference will be a better prevention of this bug, and will only affects what I showed in my replay.

There is no problem about the "off topic" posts, this is a debate, everybody is free to have an opinion and even more, to argue. But if you really want to, I'll give you informations about how to send me money on my Paypal account :D.

It's been like this for a decade, so why change it now?

No.

I mean, sure, there are things that aren't worth fixing, but the fact they've been there since release isn't the reason or else nothing would be worth fixing.

No.

I mean, sure, there are things that aren't worth fixing, but the fact they've been there since release isn't the reason or else nothing would be worth fixing.

But it's a very valid reason itself not to change something.

But it's a very valid reason itself not to change something.

This is nothing but a negative thing.
So can we hope anything or is this a "dead born" thread ?

But it's a very valid reason itself not to change something.

Arguably.

We had a similar discussion about the grenade bounce mechanics -- the original ones make no sense, but they're a big part of the game and people would have to relearn a bit of stuff if they were changed. The change would be inconvenient for long-time players, but it would make the game objectively better. This is exactly the same as that, except for much, much lower stakes on both sides.

I don't know what the best thing to do is, but my instinct is always to fix problems wherever it's practical to do so. Some people may like the problems, but I would belittle those people with Luddite references that half the forum likely won't get.

Still nobody has publicly answered the most important things about it:

1- Would this "fix" really change a thing about the rope physics besides preventing it from randomly* going through thin walls and getting stuck** in sharp (and sometimes not sharp at all) edges of the terrain?. I really don't know, but I have get very strong feeling (feeling coming from things I see every time I use the rope) that such fix wouldn't bring any negative effects on the rope physics.

*100% predictable in a pixel by pixel analysis where you can accurately measure the distance in pixels. But in a real game it is random and I don't think there is a single player in the world that would be capable of knowing if the rope will go through a thin wall or not when he releases the rope in the middle of a jump/flight.
Also this "randomness" means that you are not really changing something players were used to, just read how ridiculous that argument would look:
This fix you made is bad, you are changing the rope physics that experienced ropers were used to. Before an experienced roper knew that sometimes the rope could get stuck or go through a wall and sometimes not, now they will have to re-learn everything and know that the rope won't get stuck or go through a wall (or the chances of that happening are smaller), it's not fair!
Obviously, nobody said something like that, yet.

2-Would this "fix" really affect the performance? Has anybody ever used a rope with a different collision mask and check if it causes screen lag at all? Would those extra pixels make the slightest difference considering the fact that throwing a petrol bomb (with all the extra dynamic pixels that puts in the screen) doesn't?.

3-Would this "fix" have any other negative side effects? Maybe by changing the collision mask it is less likely for the rope to go through a thin wall but at the same time more likely to get stuck in the terrain.

I think that it is pointless to discuss about if it should be done or not without knowing what we are dealing with.

** By "stuck" I am talking about those annoying situations in which a part of the rope different than the tip gets attached to the terrain in odd ways (attached image). Also referring to those situations in which you can swing through a bunch of pixels, and then you can't, and then you can again.

I could only assume that the pictured glitch there is another disadvantage of the larger collision mask distance. Logic would suggest that an obtruding part of the land there is disregarded inbetween the collision masks, yet taken into account when the rope 'bends' and the position of the collision masks alters - I.e. The solution Devo is querying would be an ample fix for this too.

The way I see it, these mechanics all work as designed to. Therefore, these are not bugs or problems and they don't need to be fixed. They are gameplay mechanics which make W:A play the way it plays.

If you want alternative physics (ropes, grenade bounces, gravity) and so forth, play a different Worms game.

No other worms game offers the accuracy that is being discussed here... I agree with GreeN on his analysis of that pixel glitch.

Question: is there a gap between joints in the rope? if there is, wouldn't increasing the # of joints increase room for more pixel related problems? o_O

The joints are where the collision masks lie. The sprite inbetween is the 'gap'

This does not change my opinion or anything, but this replay is an example of how much land the rope can actually go through. Pretty awesome.

Yeah, that is pretty cool, actually.

They are gameplay mechanics which make W:A play the way it plays.
See, I knew someone would say it.
"I am sorry, I can't rope like this, now the rope never fails to hit a pixel!!, I can no longer expect my enemy to lose just out of such bad luck".
(My opinion here is obviously influenced by my extreme despise for needless randomness that rather than a fun factor ends up being a frustrating factor.)

With the same argument you could ask to "unfix" the erratic proximity polling by a mobile mine (http://worms2d.info/Erratic_proximity_polling_by_a_mobile_Mine) bug, the pneumatic drill malfunction (http://worms2d.info/Pneumatic_Drill_malfunction) bug, the dud mine explision (http://worms2d.info/Dud_mine_explosion) bug and other gameplay mechanics that make W:A play the way it plays.
Because knowing that a moving mine could, or couldn't, explode when going close to a worm was part of the game, knowing that the drill could fail depending on the vertical sub-pixel alignment was part of the game, and exploding dud mines was also part of the game.

Also saying that T17 staff wanted the rope to randomly go through pixels and get stuck is just a wild guess unless it's the T17 staff saying it.

Also saying that T17 staff wanted the rope to randomly go through pixels and get stuck is just a wild guess unless it's the T17 staff saying it.

That's not what I said. What I was trying to say was that when Team17 came to the task of writing a rope mechanic, they arrived at the solution which is currently present in the game. That solution was successfully coded as per the design document and is therefore functioning as intended.

I didn't say the solution was perfect but you cannot call it a bug as the final result functions in the manner they decided it should.

What you can call it, if you are so inclined, is bad design. Cybershadow and Deadcode have not been tasked with redesigning the game's fundamental mechanics, as far as I am aware. If they were to change it, the way they would go about it would probably involve additional calculations on the current rope mask's behaviour, rather than redesigning it from the ground up. Of course, that's a presumption I making based on what I know of their work and I could be wrong.

Genuine bugs, such as releasing extra cows with a backflip, have been fixed as they were not by design. The rope getting stuck isn't by design, either, but the rope's mask is.

I can't imagine it's even possible to fix the issue without redesigning the rope entirely due to the way Worms seems to work. It draws a sprite in one location in one frame and another location in the next. I think it would take a full rewrite to change that.

By the way, the Super Sheep can fly through small bits of land as a result of this mechanic. Cybershadow made a video of a sheep basically flying through loads of land but I can't find it now. It's a good demonstration of how it all works, though, and shows just how small the sheep's collision mask really is.

Oh, and for the record, I feel that the slightly random elements in the gameplay add to the fun. Sure, I might get lucky once in a while when a bouncing mine scrapes my head without going off but then so do my opponents. It evens out in the end, so arguing that one would only favour these elements staying in for their own benefit is illogical.

And now everyone is welcome to correct me. Have at ye!

I can't imagine it's even possible to fix the issue without redesigning the rope entirely due to the way Worms seems to work. It draws a sprite in one location in one frame and another location in the next. I think it would take a full rewrite to change that.
True, but for most sprites, it checks each pixel, and possible even subpixels, between the two points between which it jumps, for collisions. The Super Sheep is just an exception.

By the way, the Super Sheep can fly through small bits of land as a result of this mechanic. Cybershadow made a video of a sheep basically flying through loads of land but I can't find it now. It's a good demonstration of how it all works, though, and shows just how small the sheep's collision mask really is.
The replay on this page (http://worms2d.info/Super_Sheep_going_through_walls) is probably the example you mean, although it's Deadcode rather than Cybershadow.

Yeah, that's the one.

Corrected twice in as many posts!

Anyway, my point about bugs vs bad design remains. The rest was just gravy.

It does depend on your definition of a bug. For example, I'd (and I'd say he does too) disagree with that a problem can only be considered a bug if it wasn't forseen; that's what I'd call a glitch. I consider a bug to be any problem in the game that simply shouldn't be there.

And I mean 'shouldn't be there' in terms of the game's actual design, not the game's programming.

That's not what I said. What I was trying to say was that when Team17 came to the task of writing a rope mechanic, they arrived at the solution which is currently present in the game. That solution was successfully coded as per the design document and is therefore functioning as intended.

I didn't say the solution was perfect but you cannot call it a bug as the final result functions in the manner they decided it should.

What you can call it, if you are so inclined, is bad design.
True, but as said early on. The current implementation used was most likely used only for performance reasons. Anyways, does the rope check pixels and subpixels between each frame for a collision? or does it fall into the same exception as the sheep? The reason I ask is because the rope also moves at a fast speed just like the sheep and probably/likely travels multiple pixels per frame when fired.

It does depend on your definition of a bug. For example, I'd (and I'd say he does too) disagree with that a problem can only be considered a bug if it wasn't forseen; that's what I'd call a glitch. I consider a bug to be any problem in the game that simply shouldn't be there.

And I mean 'shouldn't be there' in terms of the game's actual design, not the game's programming.

I'm using the definition which every publisher and developer I've worked with uses. I think they call that an "industry standard definition". The word "glitch", in my experience to date, is synonymous with the word "bug", as is "issue", "defect" and "error". It all depends on which publisher you're talking to.

True, but as said early on. The current implementation used was most likely used only for performance reasons. Anyways, does the rope check pixels and subpixels between each frame for a collision? or does it fall into the same exception as the sheep? The reason I ask is because the rope also moves at a fast speed just like the sheep and probably/likely travels multiple pixels per frame when fired.

From looking at the map in the replay (http://forum.team17.co.uk/showpost.php?p=689990&postcount=46) mentioned earlier, it seems that the collision masks do in fact check every frame (See the spider web cut-outs) - The 7 pixel* 'gaps' are filled on the map, but there are continuous lined cut-outs for the ropes collision masks where the rope has connected to the landscape.

*I misunderstood Cyber's initial comment; The collision masks are placed on every eighth pixel of the rope, thus only actually leaving 7 pixels in between each collision mask

It does depend on your definition of a bug.
You can say the same thing about almost anything. You can legitimately claim evolution isn't true if you define 'evolution' in a silly enough way. Vader's definition is standard usage, so we should use it. We have enough problems with people not understanding each other without everyone working to different definitions of common words.

I'm not sure it's massively relevant, though. Whether you call the quirk a design flaw or a bug doesn't really affect matters: the fact is that the game does not consistently behave how a human would intuitively feel that it should. Solid in-game objects pass through each other, in clear defiance of the implied in-game physical laws. It would be better if that did not happen. What the decade-old design documents say is neither here nor there.

The important factors here are how much time it would take to fix, how likely it would be to break other things, and how much benefit (if any) the community would get from the fix. Arguing about semantics isn't going to answer any of those.

You're right, Andrew; what I said would be true for a new game and doesn't definitely apply to the updates. I just wanted to highlight how and why it could be considered an unworthy fix, from that point of view.

If Deadcode and Cybershadow do 'fix' bad design in their updates then it's an extension of their work that seems to have passed me by. Apologies to them both for that.

I feel like I need to up this thread.

I really wonder if this will be planned or not. If it's not a worthy glitch correction for you, devs, just let me know, I won't cry, I promise ...

Could we have any final answer ? Are glitches supposed to stay in the game or not ?

Thanks.

I think this giltch should be mentioned in the Worms Knowledge Base. (with the replays)

Feel free to add it to the Ninja Rope page (http://worms2d.info/Ninja_Rope).

Regarding changes in the behavior: we'll probably add it as a scheme option, but I'm not sure about making in the default behavior. We still need to see how much it'll affect normal roping and performance.

The gaps in the rope's collision mechanics should indeed be eliminated. The original design was obviously done for performance reasons, and personal computers have come a long way since then. Also keep in mind that the Worms2 engine was not designed with single-pixel terrain features in mind. None of the included maps (missions, etc.) and randomly generated maps have anything close to pixel-thin walls. Before online color maps, you had to Import a map and allow it to be textured, which distorted pixely features, which suggests that you weren't even "supposed" to draw maps like that. (Of course, lots of fun has been extracted from pixely terrain features, especially in Battle Races. But I highly doubt the original game design was done with this in mind.)

The ability to have a rope go through walls doesn't add any fun or meaningful challenge to the game. The only fun value in this glitch is making a spider-web mask for a roping replay, like I did for M3ntal's tool-assisted run through QP2. This is pretty obscure and does not justify keeping the rope mechanics exactly the way they are.

There is more to it than what's been said so far, though. For one thing, even if today's PCs are far more than adequate to do the no-gap rope calculations, fast-forwarding a replay would still be slower. For this reason, I would not want to simply change some constants and array sizes in the game engine. That would result in many pixels being checked multiple times, with generally more calculations being done than necessary, not to mention an ugly new appearance for the rope itself. However it'd probably be worth trying this simple approach just to see what it'd be like.

BTW, I already made a change to the roping mechanics back in v3.6.23.0. The legacy code had a roping worm get nudged one pixel up-and-to-the-left every time a rope attached in free space (and did lots of redundant trig calculations). The only noticeable result of this was that a rope fired by a worm in a very confined space (relative to the worm's collision mask) would often fail to attach. I removed the redundant trig calculations and the symmetry-breaking up-left bias.

I'm pretty sure the new collision mechanics should be implemented as such: The sector from one rope position to the next frame's position would be designated as a solid area of pixels, and each occupied pixel would be translated into an angle and a radius. The pixel with the angle closest to the current position of the rope, and largest radius, would be the one the rope would then bend around. This would result in minimum overhead when the rope is going through empty space.

Something similar would be done for a rope shot by a moving worm, searching for something to attach to; except it'd use trapezoids instead of sectors.

That leaves one remaining design choice: Keep the rope's segmented appearance, which would no longer have any meaning?
Make the rope a solid unsegmented line, making it immediately obvious the rope is different than before.Choice #2 probably makes much more sense if the rope collision mechanics change is implemented as a scheme option in which the default is the legacy behavior.

P.S. It might really make sense to implement a stop-gap solution — a scheme option that changes the rope gap (default 8) — because this would be so much simpler than the "correct" change I described above. The "correct" change would be a step towards a pseudo-continuous-frame-rate engine.

That leaves one remaining design choice: Keep the rope's segmented appearance, which would no longer have any meaning?
Make the rope a solid unsegmented line, making it immediately obvious the rope is different than before.

So basically it's a choice between this:

http://i40.tinypic.com/28ck2ur.png


and this:

http://i40.tinypic.com/rhq4go.png

I think that looks allright. Of course some antialiasing would be nice as well.

antialiasingNot until we move to full-colour :(

largest radiusWouldn't that be a breaking change? I'm thinking about firing a rope horizontally in mid-jump, along a flat object - currently, the rope will attach to the closer edge, while with that change it'll attach to the further edge...

I vote for option #2. After all, the original Rope wasn't segmented:

http://hyspace.progressiveboink.com/rope.gif

Wouldn't that be a breaking change? I'm thinking about firing a rope horizontally in mid-jump, along a flat object - currently, the rope will attach to the closer edge, while with that change it'll attach to the further edge...No, because I was talking about where the rope should snag while already attached, and you are talking about where the rope should attach while being fired.

Not until we move to full-colour :(


PX has now moved to full colour. =]


Also, a script has already been made that emulates WWP roping. (Goodness knows why, but it demonstrates that PX is the future :rolleyes:)

Um, you can already emulate WWP roping with one of the registry tweaks provided by the official updates. That was added a long time ago.

Unless you mean something else, in which case I'm very much hoping it isn't the Super Rope Wormpot option. :mad:

Um, you can already emulate WWP roping with one of the registry tweaks provided by the official updates. That was added a long time ago.

I'm sure he'll be glad to know that, after scripting it all. =D

Unless you mean something else, in which case I'm very much hoping it isn't the Super Rope Wormpot option. :mad:

That, also, has been made. xD

Um, what's "WWP roping"? Deadcode has already proved that at the default options the WWP rope behaves precisely like the W:A rope.

Maybe you mean W2 roping? The rope in W2 is substantially different.

When I say WWP roping, I mean the difference between TimerWorkaround_On and TimerWorkaround_Off, the latter of which has been the default WA behaviour since one of the beta updates. Some ex-WWP players prefer to have it On even now, I guess because it makes certain roping tricks easier for them.

But yes, other than that, the physics have been proven to be exactly the same.

Perhaps they are exactly the same in theory, but in practice roping in each game is entirely different. Maybe it's the gravity? I didn't ask what he did tbh, I just complained that roping seemed strangely off and difficult as we were playing, and he said that his script included WWP-style roping. He certainly did SOMETHING, and it sure felt like the times I've gone back to visit WWP, only to discover that I can scarcely move on the rope there (terrible frame rate is another culprit). If I remember to ask, I'll let you know what it was that he did.


EDIT: Yeah, It was the gravity he changed.

I'd say if your going to change the rope colision, keep the segmented graphic. To be honest I never realised it represented the collision and just assumed it was aesthetic. Unless of course you add it as an option in which case it would make sense to show what type of rope is being used.

When I say WWP roping, I mean the difference between TimerWorkaround_On and TimerWorkaround_Off, the latter of which has been the default WA behaviour since one of the beta updates. Some ex-WWP players prefer to have it On even now, I guess because it makes certain roping tricks easier for them.

But yes, other than that, the physics have been proven to be exactly the same.

If the TimerWorkaround_on and TimerWorkaround_off affected the rope mechanics, wouldn't that be cause for desyncronization in online games etc.?

If the TimerWorkaround_on and TimerWorkaround_off affected the rope mechanics, wouldn't that be cause for desyncronization in online games etc.?

You mean, if one player had it set and another didn't? I think it works more like a game/scheme setting, like turning on Battyrope and so on and so forth.

But if the purpose of the feature is to prevent crashes on select machine configurations then you would have either some players crashing when joining without the host using the fix or a desync depending on if it IS a scheme setting or not.

It doesn't result in a desynchronisation because it doesn't change the mechanics. The data sent over the network is indistinguishable between game clients with the workaround enabled and those using the standard behaviour. For example, the number of possible angles at which a worm can fly off the rope remains exactly the same, but with the workaround enabled, it's still more likely to happen at certain more limited selection of these angles. I don't really remember the technicalities and I probably never understood them in detail, but this is an example that should be easily reproducible in practice by a reasonably experienced roper who knows what to look for.

I remember I felt the difference most obviously when doing so called kicks. See this movie at 7:52 for a few examples of them: http://wormtube.worms2d.info/67/showcase_2