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.
Forums
