I thought that at first too vesuvio, but that 50 damage is all from the nade. The red worm didn't hit the side of the tube on his fall, therefore no fall damage. That drop could have been 10000 pixels and he'd still only get 50 dmg. It's a bit counter-intuitive but that's how it works.

That was awesome Deadcode - I watched it probably 50 times. Great presentation. Even with your various tools that must take a while to get right!

Genia-1993 has been banned from TUS for abuse of English language.

StepS said himself that wkKeyRemap is against TUS rules. https://www.tus-wa.com/forums/announcements/wa-v3-7-0-0-released-18662/60/?wap2

Quote from: StepSwe can't release it until it meets TUS's platinum standards
and we could not find a way to block a press.
so say thanks to TUS rules, and primarily Maciej

wkKeyRemap was not updated because StepS couldn't find a way to block the second space bar. When he found a way, he released RemapKeys. Using wkKeyRemap is cheating.

Furthermore, having a 3-key lock doesn't affect tap speed. With arrows held down, space either works or it doesn't.

If while holding one space bar, you can press a second spacebar and it fires, you're cheating. End of story.

Your whole argument (that simple = hard ahk) boils down to your assertion that "one press is nothing". Well that is bullshit. If you "remapped" every key to a spacebar with your scripts, you could mash every key at once and have god-like taps.

In my opinion, having more than one spacebar is lame to begin with. Finger roll is supposed to be with one space.

PS. What kind of dumbass buys 7 fake keyboards?

Nice videos dcrew. I TAS'd humRR1 once.. probably my favorite .bit RR map (which I made). Made it to the end and back in under 30 seconds. Lost the replay, and the single step program though haha. Your replay is better anyway. That bigrr one with invisible walls is crazy.

Could eliminate some screenlag by removing PX/Rubberworm, if they're installed. Or just install a fresh copy to another folder and have 2 installations.

Other than that, lowering your in-game resolution usually helps quite a bit. Or get a better video card.

Quote from: StepS on January 28, 2016, 06:14 PM
I can confirm that he's alive and willing to release his source (under certain conditions, such as finding everything needed for it to work...). Last time I contacted him was in April 2015. He has been very busy with his studies in the recent years. It's not certain but he might show up more often starting this year.

That is fantastic news and very unexpected. I had no idea he was in contact with anyone, much less willing to discuss source code. What is he studying?

Quote from: Komito on January 22, 2016, 09:21 PM
Street`Worckout disappears...

2-3 months later we'll meet Breakfast`in`bed or something.

This made me laugh.

PX source code needs to be released already. And then integrated (or at least made compatible) with the current official version. With 2 versions of the game to maintain and fill with players, PX will never reach critical mass. It will die a pathetic tragic death as its users slowly bleed off and start playing Call of Duty 10 or whatever.

Entuser has been unresponsive to all attempts to contact him. I'd want to know that he's alive and willing to release his source before I donated to him. I can't understand why he'd want his brilliant creation to be such a waste of potential. Are any of his old friends still around that could reach out to him?

Entuser's forum account on http://worms.org.ua has an email address and ICQ handle. Must be registered member to view them. Can someone (a friend?) message him? If not I will register later.

Anyone know what this is? It's about 25000 lines of PX-related code . http://www.pastebin.ca/2825624

edit: ZexorZ says it's the PX scheme source code, not everything

Not to make a bad tone. I'm not trying to pressure anyone to do anything they don't want to do.

Quote from: Komito on January 10, 2016, 06:55 PM
That is a spectacular idea joe! It does indeed sound easy enough to implement.

Only problem being, it sounds like it's exclusive to HostingBuddy, at the moment, I only use HostingBuddy when I want new Big RR maps cuz WMDB is the worst place to find Big RR maps, you look for Big RR and get all these stupid tower race and tight rr maps that go on forever... Anyway...

The best thing imo to happen for HostingBuddy, would be what you suggested with the addition of actually being able to edit the scheme/map as you would normally if you were hosting, that, is the holy grail of hosting imo...

Glad you think it's a good idea!

The following post is officially a mess. Way too many edits. Read at your own peril. TL;DR below.

My suggestion isn't necessarily HB exclusive. It would use a new wormkit module to get the map and settings and verify IP addresses. The wormkit module could be used with or without HB. The purpose of using HB would be convenience, not to keep privileged access to game settings or mechanics out of the hands of the user to prevent abuse. HB wouldn't need to be given any secret special powers. All HB was going to do in my proposal was host the game and load the custom wormkit module. The wk module would assign specific weapons to teams, set hard to set settings like remaining round time, and standardize the scheme --- eg remove superweapon crate probability values. Which is precisely why it shouldn't require a WA update. HB would just be a way to automate things, to host conveniently in a standardized way, and to alert the players if the host changed anything. No reason (that I can see) why that automation can't be done by just a wormkit module.

The main thing i was unclear about in my first post: From WA's perspective any resumed game would be a completely new game, not fast forwarded or anything. Nothing abnormal in the settings except team weapons. (edit: also individually defined worms health values and status .. a little more tricky maybe). In theory it doesn't have to be any more complicated to resume games with the "Hostingbuddy suggestion" method than to resume by hosting normally or by using Wormnat2, depending how the wk module is automated.  Sorry if this is a bit incoherent and repetitive.

It would actually be less complicated without HB for two reasons. First, because you take wmdb out of the equation for hosting and redownloading maps in their aborted state.  Second, because HB can't currently load custom wormkit modules like Rubberworm, PX, or the theoretical wkResume module.

But wait, how would the wk module recreate flame particles from a petrol bomb? Maybe you couldn't resume when flames are on the map. That would be acceptable in most cases, compared to the alternative of not being able to resume at all, ever. If you started complicating things by altering game logic by adding petrol-teleports and wind manipulation or something, that would create an opportunity for hackers/cheaters. And be a lot harder to make. In theory maybe only Hostingbuddy could have the 'full version' module which allows weird game logic fixes, and the wk module distributed for compatibility to all the players wouldn't include any of the code that could be hacked and abused. This would make it HB exclusive and would go against a lot of things I said in paragraph 1. But this is getting way too complicated, and would be better to just not allow resuming at points where flames were present. If wormkit can't set the flames, which I'm assuming it can't. 

Another problem related to the petrol issue. Weapon crates aren't determined until collected, unless Crate Spy has been used. If flames are on the map, and then someone gets a really nice crate before the game disconnects and before the flames disappear, they won't be able to keep that weapon. The game will roll back to before the flames. After resuming the game, the crate will fall again, but probably be different. Same idea for favourable wind, which I'm pretty sure is basically random too, influenced by worm location.


Given that, the rest of this post is slightly off-topic. I got a bit carried away here.
____
Original response to Komito:

I agree, being able to natively edit stuff while using HB would be nice. If not just for how widely used it is - a lot of people would notice the benefits.

An alternative method to editing HB settings more conveniently ---- I wonder if anyone would want to create a pre-game lobby screen and map editor for one of the existing Snooper programs. All the options (game, weapon etc) could fit on one screen. Any changes could be automatically communicated to Hostingbuddy with the text commands. Map changes could be uploaded to wmdb and loaded by HB automatically. Finer details and color maps could be edited with the new map editor, with a box tool to move stuff around, copy/paste, zoom, etc. Random maps of any size could be generated with wkMapGen. Finer scheme changes would be possible and make SchemeEddy unnecessary. And it could all be skinned to look similar to the original frontend, like Wheat Snooper (which is open source). A lot of the work might just be patching together various programs wormers have already made. It'd be one step closer to ditching the obsolete frontend altogether.

Actually I think Komito's suggestion to be able to edit normally in the frontend while using HB is probably better than the snooper one. Either would be good. Snooper would give a bit more versatility, at the big cost of accessibility. All the noobs trying to host with HB would still be lost and confused. Unless the snooper was officially packaged with WA, which I don't see happening. 

Either way fixing the disconnects issue should be the top priority IMO. Since frontend HB integration would mean more work for CS/DC and possibly delay the true hosting holy grail of 4.0. And since normal style hosting/editing (and resuming, in theory, with an additional wk module) can already be achieved with WormNat2.

____
TL;DR: My idea should still work with or without HB. With some limitations. It would probably not be feasible be able to resume the game when petrol flames were on the map. Unless wormkit can be used to somehow precisely place each flamelet on the map when the game starts. Bad for schemes like Hysteria or Burning Girders. If a weapon crate was collected while flames were present and the disconnect occurs before the flames are gone, the crate will not be kept when the game is resumed. The game will roll back to before the flames, and the crates will be different when they next fall (unless a team had crate spy). Not sure if a Wormkit module can set individual worm health and status on game start --- can PX do this? If Wormkit can't do all that alone, then a WA update would be needed for my idea to work.

Quote from: Triad on December 27, 2015, 01:40 PM
Not from replay, but from dropped game. Otherwise some cheater would continue from replay until they have some nice result. Basically when someone drops, there should be an option for pause the game and wait. When dropped guy joins wormnet, wormnet should give a notification like: "The game you have disconnected from is still on, do you want to rejoin?"

I agree that implementing some way of preventing or continuing after disconnects is easily the most important thing that can be done to improve WA.

I like your rejoining idea, Triad. Seems elegant and simple enough. However (and just guessing since i'm not a programmer) something tells me it's very hard to code to allow a player to join a game in progress (even if paused). Especially without using the disconnected player's replay file -- we can't even play back replays at a given point in time without fast forwarding. And, whether you do or don't use his replay file, it still won't work for cases where he disconnected because of desynchronization. The desynched player has a different account of events. He could only rejoin if he and/or the host could rewind online gamestates/replays, which as you said would open the doors to cheaters. The single-step tool Deadcode used for his famous Pi Mission Impossible II roperace replay worked using the same principle.

I think forcing more reconnection attempts before the player actually drops would be an adequate substitute for rejoining in the way you proposed. Right now it doesn't seem like many reconnection attempts are made. If a player's wi-fi drops for a split second he will disconnect instantly. If a player lags for more than a few seconds he is usually 'doomed'. The game should attempt to re-establish connections more aggressively before a player drops. This would probably require an actual WA update to change.


However, disconnects from desynchronization are also a big part of the disconnection problem. Neither of our suggestions so far would allow resuming games in which a player desynched. 

The following solution SHOULD work for both dropped and desynched games, be relatively easy to code, convenient for players, negate cheater risk, and not require a WA update. It would also make my above suggestion of more aggressive reconnecting behaviour much less important. TBH I'm a bit proud of this idea .


Here goes:

If you want to continue a dropped game, you send Hostingbuddy your replay via a short text command. For example "!desynch j0e" or "!resume j0e" (to resume just before j0e desynched/lagged out). Hostingbuddy automatically extracts map in the state it was in and rehosts game. Hostingbuddy uses a hypothetical custom wormkit module to give players the weapons they had. And to mimic SD timer, who gets first turn, water level, etc. (The current scheme format is not flexible enough to allow individual team weapons yet). And Hostingbuddy disables all unnecessary wormkit modules and/or standardizes the scheme to avoid a second desynch. Hostingbuddy only lets players with the same IP address as the original players join (to help avoid nickname change/player switching). HB gets lots of data on dropped games, as a side benefit.

If HB already gets the replay for games it hosts (which I somehow doubt) the extraction/rehost could be even more seamless using the !again command.

In layman theory, the Hostingbuddy method maybe could be implemented without updating the game.

QuoteNot from replay, but from dropped game. Otherwise some cheater would continue from replay until they have some nice result.

Letting Hostingbuddy handle resuming games avoids the cheater risk you mentioned (quoted). No additional rewinding powers in game to hack/abuse. And it's maybe easier for developers to implement if a patch doesn't have to be approved by Team17. Hostingbuddy has also received some great updates recently, so there's momentum in that direction.

Just interested in the topic/discussion and thinking out loud here, mostly. Like gabriel said, I'm extremely grateful for the state the game is in already.

Quote from: TheWalrus on January 10, 2016, 06:25 PM
I'm one of those people that thinks j0e's worms page was, in fact, the ultimate site.

Thank you! That was a hella long time ago. But TUS is easily better in every way. Except TUS doesn't have pages and pages full of geeky 12 year old child outpourings     .. unless you go on the forums lol.

Quote from: thewalrusdeadwood

Same thing happened on my old laptop. Every 5 minutes or so the whole thing would freeze for half a second. Even if I was just browsing the web. There was a sound associated with it which may have been a fan. You could try a cooling pad. I tried punching a hole in the screen but it didn't help.

Try making a separate installation of WA for Project X if you haven't already. PX and high resolution don't mix on old PCs.

edit: er wait I guess if youre using D3d9wnd you can't be using PX.  I dunno then.