Which window is small? The menus or the game?
The game window size is controlled by the WA resolution setting,
The menu window size is controlled by editing the wkd3d9wnd.ini file. 0 means off, 1 means on.

Troubleshooting to get the easy things out of the way:
-try different graphics renderers (set in Advanced Settings)
-try using a smaller in-game resolution than your desktop resolution (will make game run in a window), or if game is already in a window, set in-game reso to your desktop reso.
-try changing various settings in the above-mentioned ini file.
-update directx? idk.

I'm not sure whether d3d9wnd was designed for Windows XP. Why do you need d3d9wnd? Multiple monitors? If it's just to make the menus more friendly you could try wkSuperFrontend. I'm sure someone smarter will come along with better suggestions..

Quote from: CyberShadow on July 30, 2015, 05:16 AM

Quote from: CyberShadow on July 30, 2015, 05:07 AMThese are now live.

Forgot to mention that the background fix for http://wmdb.org/16374 etc. is now live too, please give it a go.

Quote from: CyberShadow on July 30, 2015, 08:11 AM

Quote from: CyberShadow on July 30, 2015, 05:36 AM
Going to look into fixing preprocessing http://wmdb.org/15338 as well as why http://wmdb.org/24528 doesn't work at all.

Done

Sorry for the slow response – was at work all day. You've been busy! After some testing, all the maps you posted load. Maps with more than 65 colors after palette reshuffling now have normal background soil, as long as they don't have automatically placed holes. This is a definite improvement. However if holes are added to maps with more than ~91 colors using the !holes command, they will have white background. I gather that the automatic holes need certain dedicated colors in the palette, requiring more colors to display properly. Here are the complete results of my tests:

Maps 16374, 15338, and 6247, all have >112 colors (after palette reshuffling) and either pre-placed holes or no holes. All of them now work great – unless automatically placed holes are added.

Map 13192 has only 65 colors and looks fine with any number of holes added. The new forced scheme border setting is working great! The map setting of Snow background also successfully overrode the new Beach default as planned.

Map 11155 (91 colors after reshuffle) does not have holes by default and looks fine with automatic holes added; only the background islands (from pressing Insert) have color problems.

Map 24528 (97 colors) has automatically placed holes by default and has white soil.

So it appears that if the palette can be reliably shrunk to <~91 colors, white soil will be a thing of the past. And if it can somehow produce maps with 65 or fewer colors reliably, there'll be no visual errors at all. It is very nice to have the color counter now. Even if the palette shrinker can't be improved, there will be no more paranoid guessing about which maps will work or not. If the palette shrinker can't be improved though, you might consider adding an explicit warning about white soil in the green map info text.

Fantastic work! Thanks again.. I hope this was at least a bit useful. 

Quote from: CyberShadow on July 30, 2015, 02:51 AM

Quote from: Hussar on July 29, 2015, 08:40 PM
what about to implement some helpful informations aabout TUS in HB games??

What information specifically?

TUS and HB are rather distinct entities, hosting doesn't have much directly in common with leagues. Though we've discussed e.g. making !map load maps from TUS as well.

Maybe you mean the Help bot in #Help?

I think he might mean adding another way to distinguish HB-hosted TUS games from open public games? The hoster can of course use the !phost (private host) command, but people are sometimes lazy and don't bother PMing everyone the password. I guess you could write "!thost roper" or !host tus roper" and the game would show up as "TUS Roper for j0e" or maybe better "League Roper for j0e".

Quote from: CybershadowCan we make a list of some sensible defaults that will apply to the great majority of maps?

I'll try. Feel free to add anything, anyone:

Roper/proper:
-Borders on
-Water drop on

Mole shopper, Shopper, Fly shopper, Fort, Holy war, Burning girders, Bazooka and grenades, Supersheeper, Darts:
-Borders off

All schemes with destructible terrain (Mole shopper, Fort, Holy war, Burning girders, Bazooka and grenades, Capture the flag, Bow and arrows, Sheep fort, 'Other'):
-Disable "Snow" background soil texture if using a png map. There's nothing technically wrong with it, but it can be hard to distinguish between the foreground and background. Snow background can be almost as annoying as the dreaded white background.

Quote from: j0e on July 29, 2015, 08:51 PM

Quote from: CyberShadow

Quote from: j0eI've pushed out a change that prints such map settings up-front when you load a map, as well as make more settings customizable for both PNG and random maps.

Is this a recent improvement?

Yes, I implemented displaying the settings yesterday. Can't do much about the color.

Wow, very quick work! I see that it now displays whether a given setting is due to enforced defaults or saved in the map. Is the water level info new too?

Really great work Cybershadow . Thanks for all the detailed replies.

Quote from: CyberShadow on July 29, 2015, 11:27 AM

OK, there's definitely something going wrong there, since when that map is loaded in W:A, it looks fine. Something to do with how HostingBuddy generates the waLV chunk. I've asked Deadcode so we're investigating.

Awesome! That explains why some of my own maps, which I've tested offline, end up with white soil when played via Hostingbuddy. I never figured out why this happened, but felt like a hypocrite for all the times I've complained about map authors not testing their maps.

Quote from: CyberShadowOne thing to note, though, HostingBuddy does not dither down the map - it simply removes unused colors. W:A expects the host to send them a map with no more than 113 colors, even if some are never used, so HB simply reshuffles and compacts the palette to accommodate W:A's requirements.

How about an error message, in red, if destructible soil is present and the palette reshuffling fails to get the map to 64 or fewer colors?

Quote from: CyberShadowIt would require protocol changes, which are always a complicated and messy affair. This is basically Internet cookies, but for W:A. If we were to go into that direction, the most beneficial course would probably be to get rid of the chat interface and integrate HB into W:A's interface, (which all is ever so non-trivial of course). For now, I think we should approach the problem from other angles.

Instead of a local blacklist, would it be possible for players to downvote or report bad maps through a HostingBuddy command?

Quote from: CyberShadowWe could also enforce map settings in the scheme configuration, e.g. enforce that maps have no borders in mole shopper games (i.e. the default overrides the map setting, but a user setting can override the default). Something like that is already done for Elite (Fruit island maps only, by default).

Enforcing water drops and borders on for roper maps would be a great idea. Likewise borders off for mole shopper maps. Not all schemes are as simple as roper and mole shopper though. For example, some capture the flag maps are played with a border, but most of them without. The 'attached scheme' function helps a lot for the weird outlying cases. Being able to easily downvote maps via Hostingbuddy would be a further improvement.

Quote from: CyberShadowI've pushed out a change that prints such map settings up-front when you load a map, as well as make more settings customizable for both PNG and random maps.

Is this a recent improvement? Having the map settings up-front is very nice. But it can be hard to notice (due to complacency) when something's wrong, because most of the maps are saved correctly. It might be easier when previewing several maps if, for example, "with borders" was written with a different color than "no borders". You'd notice without reading that 4 of the 5 maps you previewed have the same colors for all the options, but one stands out because, ah, it has a border.

All schemes should also display a warning if automatic worm placement is selected but manual placement is forced due to too many worms.  This would help for maps saved with the wrong settings like http://wmdb.org/9191 (mole shopper with no holes). Unwanted manual placement is also common in schemes played with a lot of worms such as Holy War and Bow And Arrows.

Quote from: CyberShadowhttp://wmdb.org/586 seems to be rated low, so HostingBuddy should never pick it. Does it?

No, I can't remember seeing it. I didn't realize HB chose maps based on rating. Guess this was a bad example!

The map pre-processing code should be able to fix the problem. The "bad" maps I'm talking about are:

• Maps that display the "this map does not have black at position 0, please wait" error. These maps end up loading but with ugly white background soil.  I found several examples of these. Eg: http://wmdb.org/16374


• Maps that have more than 64 colors and destructible terrain. Sometimes HB says "WMDB map requires some processing to fix (Map colour palette is too large (256) but could be reduced to 112.), please wait". Hostingbuddy should check to see if destructible terrain is enabled, and in those cases dither down to a maximum of 64 colors. Eg: http://wmdb.org/6247 In some instances, I noticed that HB does in fact dither the map down from 256 to 64 colors successfully though – eg. http://wmdb.org/23092 (even though I distinctly remember playing this one with white soil before and thus have habitually skipped it since)


• Maps that are simply uploaded with the wrong (or unconventional) settings for the scheme. For example, roper maps without "water drops", or mole shopper maps with borders or without holes automatically placed. I found many examples of these. Some pre-processing checks could possibly look for some of these things and alert the host. For example: "This roper map does not have water drops. Type !wd to enable them". I can come up with a more comprehensive list if you want. Eg: http://wmdb.org/5068 (no holes), http://wmdb.org/13173 (has a border)


• Maps which (less importantly) simply don't conform to my personal preferences. For example, I don't much care for ultra-long Rope Race maps that take hours to complete. And some maps are objectively just plain bad, eg: http://wmdb.org/586. But I can live with skipping these maps manually.

As I was searching for examples, I found two things interesting. First, I was not able to find any instances where the map being glitched was HB's fault, without displaying some kind of warning message. Assuming that not giving warnings for maps saved with the wrong/unconventional settings isn't HB's fault. Secondly, I realized there are a huge number of maps that I habitually skip every time just due to paranoia of it being glitched.

Would it be possible/feasible to store a personal blacklist locally on each user's PC? That way you don't have to tie nicknames to IPs or anything like that. And with a local blacklist, my personal preferences in maps wouldn't affect others' ability to play unglitched maps. The only downside seems to be that messing with local files would probably require users to download an update. Perhaps automatic map caching might also then be possible ?.

Anyways, thank you for the response. I'm always happy to provide feedback. Also very glad to know that the disconnects issue is a priority!

Awesome stuff as always. Thank you for your dedication, Vladimir.

Since you asked, one feature I have often wished for is a map blacklist for HB's wmdb function. This could be stored locally or more complicatedly with a shared blacklist or map rating system. IMO simple and easy would be better though.

The problem this would address is that HB seems to fetch the same poor quality or bugged Wmdb maps over and over again. Maps that have been skipped are often chosen by HB again. The problem is compounded because there is no method via the Wmdb website itself to blacklist or flag offending maps except indirectly with the "complain/suggest" dialog. The lack of a blacklist is especially an issue with my favourite scheme, mole shopper, in which white background soil is very prevalent in the commonly-fetched maps. (I say commonly-fetched because I don't think the selection is purely random ?). White background soil makes it difficult and annoying to discern what is land and what is not. Fetching a lot of maps also can be painful for users with slow internet connections or who are using expensive cellular data to play.

As an extension, if a player joins a game and the host (or HostingBuddy) is using a map that the player has in his local blacklist, it could also warn the player that the map is bad so he could ask the host to change it.


I recently made another more important suggestion in the 'Disconnects' thread, however, that got buried with spam. Just hoping for any comment on this one, if you'll forgive me for posting a non-HB suggestion :

Short version: unstable wi-fi internet connections often cause games to drop prematurely. The game does not seem to attempt to reconnect, even if the connection outage is very brief. Some kind of "keep alive" feature, in which the game would persistently and aggressively attempt to reconnect, would prevent many disappointing occasions where a very good game ends unnecessarily. This seems like a much simpler alternative to the proposed "resume from replays" suggestion that has been floating around. In my opinion this "keep games alive" feature would be the single greatest possible improvement for WA at this time.


Thanks so much for everything you've done for this game! Everyone appreciates it a lot... just not everyone can speak English or Russian to tell you that

Quote from: Tomi on July 08, 2015, 11:30 AM
everyone says that t17 is so stupid and making mistakes every time and they should ask this community about what to do, but i don't see any posts at steam about this. is there any t17 developers on this forum or why you are talking here? :O

There have been a ton of posts, but they also delete a lot of posts and ban anyone that makes them look bad.

Resuming from replays, while it would be nice, is a very ambitious goal. There are many security/validation/design issues to consider which stand in the way.

However it seems more doable to simply force the game to repeatedly, persistently reconnect if it detects a connection dropped. Currently, if the wifi drops for one second -- ie. any time someone sneezes too loud, uses the microwave, or listens to Nickleback -- the game drops, with zero chance of recovery.

In my opinion this 'keep alive' feature would be the single biggest improvement possible to the game. I've dropped from countless matches due to flaky connections.. seemingly always at the worst possible time.

How difficult would this be? Currently planned? If so, any chance of it before 4.0? Sorry to nag. I greatly appreciate everything you have done, Deadcode and Cybershadow. 

This was a bug introduced in version D3D9Wnd 0.6.6. It is very annoying. My solution was to scour the internet for the newest version I could find prior to 0.6.6....... which I ended up finding on Internet Archive's Waybackmachine on some Russian website which I had to translate and sign up for to access the download link. Now it works perfectly again on the older version. I am very sorry but I don't have access to this older version anymore to send to you ...

Quote from: XanKriegor on March 23, 2015, 06:05 AM
Is this possible to rope in all three dimensions at same time without landing like in this video?

No, it's not possible to change directions without landing. The rope is basically 2 dimensional.

Quote from: ANOE' una cagata pazzesca!

Crazy crap? I'll grant you that the roping physics do look more like Worms Reloaded than Armageddon, butcome on, this is awesome!

why is nobody talking about this??? it's pretty much the dream of every roper ever!!

Hey storminASU. Your settings look fine.

But it doesn't sound like d3d9wnd is doing anything. I'm guessing the frontend (menus) are probably still full-screen, etc. That means one of two things: either D3D9Wnd is not enabled yet in WA Advanced Settings, or it's installed in the wrong folder. Make sure this option is ticked:


If you've enabled the above option but d3d9wnd is still not working, that means it's probably installed wrong. D3d9wnd has to be extracted (unzipped) into the base Worms Armageddon folder.

For Steam users the base WA folder is something like:
C:\Program Files (x86)\Steam\steamapps\common\Worms Armageddon

and for CD Rom or pirate users something like
C:\Microprose\Worms Armageddon


After you get the module working, you can tweak various settings, like increasing the size of the frontend to make the words easier to read, etc. EnableCustomSize is the one for that.

Quote from: StorminASUI've tried to download d3d9wnd and make it work, but I can't figure it out because I'm so unfamiliar with registry options and I don't understand what frontend, etc. refer to.  TIA!!!

When editing D3D9Wnd.ini, 0=Off, and 1=On.

"FrontendSettings" refers to the menu system. Anything with the blue background and floating stars basically. Knowing this, combined with knowing the above (0=Off, 1=On) the options are reasonably self-explanatory.

"InGameSettings" controls everything in the actual game.

The "InGameSettings" are a bit difficult to understand at first. As long as you know that with D3d9wnd enabled all aspects of the game are 'windowed' by default, it makes sense. It's only when the Desktop Resolution of the player matches his or her In-Game-configured setting, that the In-Game portion runs in fullscreen.

To achieve what you want to do, you need "Stretch=0" under the InGameSettings, and then in the regular WA options, set a smaller resolution than your regular desktop resolution. For example, most computers use 1366x768 as their default resolution, so you might set WA to use 1024x768, so you can click out of the game on the sides.

Just so you know, since WA makes use of the mouse to control the game's camera, you first will need to press "Ctrl+G" to un-pin the mouse, and then click outside of the window. Alternatively, Windows+D, Windows+M, or Shift+Esc will minimize the game quickly at any time (with or without D3D9Wnd).

To minimize the windowed frontend quickly, you have to press Windows+D or M. Clicking outside the frontend window doesn't make it go away, since it's Always-on-top for some reason.

My recommendation: find some free software that will let you remap Windows+D to an easier single-button shortcut, for when your boss walks in. I know AutoHotKey can do this, but it's extremely confusing.

Getting D3D9Wnd was smart because now minimizing from the Frontend doesn't force your monitor to switch resolutions, so minimizing will be instant, instead of the usual 2-5 second lag.

Edited for clarity.

Quote from: pizzast on November 18, 2014, 04:17 AM
I think the best thing that anyone could make for worms is... something that will allow you to ReHost a game exactly where game dropped , Same positions, Same Map damage , Same weapons , health ect ect.

There is rubber worm... there is PX... there was gayshit like Silkworm  why not something that does this...

game drops are a LARGE part of worms i would say.

Couldn't agree more. Somehow I still manage to experience a dropout at least once per day. Mostly due to my dodgy internet connection. It's also the #1 suggestion on http://feedback.worms2d.info/forums/5998-worms-armageddon

Just noticed: http://www.wormsng.com (WA V.4 status tracker) has finally been updated, and is no longer stuck at ~2% progress!!

Sounds like you just have a really slow/unstable internet connection. Wifi from a far away location? Is it slow for other things?