Worms Armageddon Forum

I cannot run this game on linux. I have made sure to run in "desktop mode" and this doesn't seem to alleviate the problem.
I ran into similar problems running WINE, where previously a dll hack was required to run the game. This worked in versions of WINE previous to 1.0, but now I cannot run the game in WINE or crossover in current versions.

7.2.0 crossover-games --- I get the title movie, but when it switches to the menu I get an error

8.0.0 I hear the sound --- but I get no display whatsoever

ERRORLOG.txt, but I figured it might be too wordy for the forum

Have you installed it into a Windows 98 bottle, and applied the most recent Worms Armageddon patch?

It is installed on a 98 bottle, and I have the lastest patches installed as well.

Just FYI....Worms World Party does pretty much the same thing..ie; black screen,
you can hear the intro running, you can hear the mouse click on things in the
menu you can't see....and...(this is the confounding bit)...if you happen to
blindly click in all the right places and actually =start= the game itself,
the =game= runs very well...it just the intro/menus that are lost in the
black hole of darkness -- last time I checked with Wine (1.1.31) the same
situation was evident....(I think something is broken in d3d7 that's causing
this...a few titles running d3d7 seem broken just now)

edit: this is what I get from running the following command;

bash-3.2$ ~/cxgames/bin/wine --bottle wwp --debugmsg +d3d7 "wwp.exe"
fixme:win:EnumDisplayDevicesW ((null),0,0x2c7cd8,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x2c7dcc,0x00000000), stub!
fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 8
fixme:d3d:IWineD3DDeviceImpl_CreateSwapChain The app requests more than one back buffer, this can't be supported properly. Please configure the application to use double buffering(=1 back buffer) if possible
fixme:d3d:WineD3D_ChoosePixelFormat Add OpenGL context recreation support to SetDepthStencilSurface
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x1912f60,0x1912e60): stub
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK

Those last repeated lines are echoed constantly to console while everything is
running in the totally black screen. It would be interesting to know if you
get the same debug results with worms armageddon....

Cheers!

Sounds good, unfortunately, you cannot do this with Worms Armageddon. When you click anything from the menu, the application crashes.

I found an attachment that gets the video to work and patched WINE 1.1.31 and built from source. Unfortunately you can click through, start the game, but once you are in the actual battle, it doesn't accept keyboard or mouse input. What a tease! It seems like it's just not capturing all of the mouse events and none of the keyboard events in the new window.
http://bugs2.winehq.org/attachment.cgi?id=17739

This was an attachment to wine bug 2082:
http://bugs.winehq.org/show_bug.cgi?id=2082

I also noticed that I lose the keyboard and mouse when in the settings page, you have a dialog that appears saying "you are quitting without saving your options, are you sure?" ... hmmm, when I click "start game" from the team selection screen I get a dialog with "please wait"

Perhaps these dialogs are grabbing focus and not returning them to the parent window?

Yes, it does appear that I get the same "returning GL_BACK" error when running cx and Worms Armageddon. When I try to switch screens by blindly clicking I get the "win:LockWindowUpdate ((nil)), partial stub!" error and the app crashes

err:alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element
err:alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element
fixme:mixer:ALSA_MixerInit No master control found on M Audio Delta 44, disabling mixer
fixme:mixer:ALSA_MixerInit No master control found on USB20 Camera , disabling mixer
fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and 32 total samplers
fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers
fixme:win:EnumDisplayDevicesW ((null),0,0x33abfc,0x00000000), stub!
fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and 32 total samplers
fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers
fixme:win:EnumDisplayDevicesW ((null),0,0x33ace4,0x00000000), stub!
fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 8
fixme:d3d:IWineD3DDeviceImpl_CreateSwapChain The app requests more than one back buffer, this can't be supported properly. Please configure the application to use double buffering(=1 back buffer) if possible
fixme:d3d:WineD3D_ChoosePixelFormat Add OpenGL context recreation support to SetDepthStencilSurface
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x1b47d30,0x1b47c30): stub
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:win:LockWindowUpdate ((nil)), partial stub!

Interesting....again, just for the record (with worms world party), I went to
the Team17 website and applied the official update patch. Turns out to be a
very good way to totally nuke the bottle installation...ie; after patching,
the game doesn't even start anymore and display the 'please unload the debugger
and try again'....which usually means the CD check has failed...

~/cxgames/bin/wine --bottle wwp --debugmsg +d3d7,+seh "wwp.exe"
trace:seh:raise_exception code=c0000005 flags=0 addr=0x1000eba9 ip=1000eba9 tid=001d
trace:seh:raise_exception info[0]=00000000
trace:seh:raise_exception info[1]=ffffffff
trace:seh:raise_exception eax=0033ff2c ebx=7b8b0434 ecx=00000001 edx=00000001 esi=10000000 edi=0013b908
trace:seh:raise_exception ebp=0033f9f0 esp=0033f9cc cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010216
trace:seh:call_vectored_handlers calling handler at 0x7b83dac0 code=c0000005 flags=0
trace:seh:call_vectored_handlers handler at 0x7b83dac0 returned 0
trace:seh:call_stack_handlers calling handler at 0x10033118 code=c0000005 flags=0
trace:seh:regs_RtlUnwind code=c0000027 flags=2
trace:seh:__regs_RtlUnwind calling handler at 0x7bc67a00 code=c0000027 flags=2
trace:seh:regs_RtlUnwind handler at 0x7bc67a00 returned 1

That was with bottle_profile = win2000/winxp

If I change the bottle profile to win98, I get ;

~/cxgames/bin/wine --bottle wwp --debugmsg +d3d7,+seh "wwp.exe"
trace:seh:raise_exception code=c0000096 flags=0 addr=0x1000711a ip=1000711a tid=0018
trace:seh:raise_exception eax=0033fab0 ebx=806e0028 ecx=00000028 edx=0033fb54 esi=806e0030 edi=0033fab8
trace:seh:raise_exception ebp=0033fb80 esp=0033fa78 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010286
trace:seh:call_vectored_handlers calling handler at 0x7b850920 code=c0000096 flags=0
trace:seh:call_vectored_handlers handler at 0x7b850920 returned ffffffff
trace:seh:raise_exception code=c0000096 flags=0 addr=0x10007122 ip=10007122 tid=0018
trace:seh:raise_exception eax=0033fab0 ebx=806e0028 ecx=00000028 edx=0033fb54 esi=0033fb5c edi=806e0030
trace:seh:raise_exception ebp=0033fb80 esp=0033fa78 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010286
trace:seh:call_vectored_handlers calling handler at 0x7b850920 code=c0000096 flags=0
trace:seh:call_vectored_handlers handler at 0x7b850920 returned ffffffff
trace:seh:raise_exception code=c0000096 flags=0 addr=0x10007123 ip=10007123 tid=0018
trace:seh:raise_exception eax=0033fab0 ebx=806e0028 ecx=00000028 edx=0033fb54 esi=0033fb5c edi=806e0030
trace:seh:raise_exception ebp=0033fb80 esp=0033fa78 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010286
trace:seh:call_vectored_handlers calling handler at 0x7b850920 code=c0000096 flags=0
trace:seh:call_vectored_handlers handler at 0x7b850920 returned ffffffff
trace:seh:raise_exception code=c0000096 flags=0 addr=0x1000712e ip=1000712e tid=0018
trace:seh:raise_exception eax=0033fab0 ebx=806e0028 ecx=00000028 edx=0033fb54 esi=0033fab8 edi=806e0030
trace:seh:raise_exception ebp=0033fb80 esp=0033fa78 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010286
trace:seh:call_vectored_handlers calling handler at 0x7b850920 code=c0000096 flags=0
trace:seh:call_vectored_handlers handler at 0x7b850920 returned ffffffff
fixme:vxd:VXD_Open Unknown/unsupported VxD L"sice.vxd". Try setting Windows version to 'nt40' or 'win31'.
fixme:vxd:VXD_Open Unknown/unsupported VxD L"siwvid.vxd". Try setting Windows version to 'nt40' or 'win31'.

This just displays the black screen with 'please unload debugger and try again' message as well.

This is just background static here (they're both Team17 titles and appear to be having
similar issues, so it may be relevant)....

Thanks for the wine links...I'll go have a peak at those (especially the patch will be
of interest)......if I can get wwp to run under the same umbrella, I may be able to
comment further of the mouse issue you've highlighted...

Cheers!

..sigh....using the patch & wine-1.1.31 does not give me any menus, so
it doesn't seem to work wrt wormsworldparty....however...

I was actually (fluke ;) able to click in the blackness and get the game
itself to start -- yes, I can confirm that keyboard/mouse input doesn't
seem to get recognized (at all) in the game itself....

One thing I could think of, is using winecfg to set dll overrides for
dinput.dll and dinput8.dll....but, it might take me a while to test that
idea due to lack of menus (I'll need have another fluke, which is hard
to do). Seeing as you are getting menus with worms armageddon, it might
be easier/quicker for you to check that notion...good luck, let me know
if such overrides do anything for you...

Cheers

I have found with Worms Armageddon if when the loading screen freezes after choosing to start a game if you push command + q, and then maximize the game window as it starts to quit the game will load. I have no idea why this occurs, but it is the only way I have been able to get it to work. This is on a mac, so for linux you may have to use whatever the equivalent command is.

I added them to the library overrides... is there something else I need to do with dinput and dinput8?

Thanks

Just to be clear, people are using the new beta patch for Worms Armageddon, right? I believe it's version 3.6.29.0. I was able to install it without problems on Mac CrossOver Games. The only change I had to make was to use desktop mode.

Technically, I have 3.6.28.0. I cannot patch this version because 3.6.29.0 is for the European version of the game, and since I bought this game from TryMedia, installing the patch will totally hose the game since it will then ask me for a CD. I am required to put the game in an unusable state to run under wine? Somehow I seriously doubt that is the problem.

As I have said, with the patch I attached earlier in the thread, I get video and audio, and can get to the game, but once in the battle, I get no keyboard or mouse input.

I don't think the TryMedia version will work. Last I tried (with the demo), it simply refused to start, failing before it made any calls in the Windows API. I blamed DRM.

W:A maintenance dev here - this is the first I've heard of TryMedia selling W:A with the 3.6.28.0 update. AFAIK they stopped selling W:A some time ago. Does their DRM wrapper even run on Wine?

Not accusing anyone, but the only version which I know of that comes pre-updated to 3.6.28.0 is "W:A New Edition", a pirate compilation with a pre-cracked 3.6.28.0 executable. I've heard that it was sold on CDs as genuine in some countries, so it's not impossible that you were scammed.

AFAIK, recent (3.6.28.0 and newer) Beta updates will work on all known (genuine) CD versions.

The 3.6.29.0 patch is not a European patch, it's available for all versions except the Trymedia version. The Trymedia version is responsible for numerous problems, and Team 17 doesn't offer any updates for it. Looking at older versions, according to their old v3.6.28.0 FAQs "You can update any WA CD version straight to v3.6.28.0 WITHOUT updating to any other version first. Trymedia versions will not work with this update. If you download this update and apply it to a Trymedia version then the game will request a CD and you will have to re-install the game." It isn't possible to run this combination in Windows, so it definitely won't be in CrossOver.

No, you're absolutely right.

I couldn't actually get the TryMedia version that I paid for to work on windows XP. It's impossible. I had to get a hacked version just to run it in Windows, much less WINE. :(
This version works in Windows flawlessly, and worked perfectly on WINE version 0.9.45. Around when 1.0 was released I upgraded WINE and the game stopped working, even with the ddraw.dll patch.

If there is some reason that WINE has a nitpick over a minor version numbered update of Worms Armageddon, then I guess I'm screwed. Installing the 3.6.29.0 hoses the game and I get a seg fault in regular WINE, and a debug error of some kind in cx. I just don't understand how going to a supposedly stable 1.0 version suddenly prevents a game that was previously supported from working now.

As far as I know, 3.6.28.0 should be fine. It's more likely the incompatibility is with the hacked version.

The 1.0 release of Wine was never meant as a guarantee that there are no regressions. They creep in even with correct changes, and finding and fixing all of them would've been impossible.

This should theoretically work, and if not it is a Wine bug. However, you're not likely to get much help running illegal software.

If you're determined to get this working with recent Wine, I think you'll either have to do some debugging yourself or order a CD version and hope that works.

Fair enough. I'll buy the game, again, just to make absolutely sure that there is no discretion between the version others are running and the version I am running. I'll let you know in a few days once it gets here. I should point out though, that Don mentioned he was having similar issues with Worms World Party, another Team 17 title, so I'm still betting on a WINE bug.

Pete Lesko wrote:

I should point out though, that Don mentioned he was having
similar issues with Worms World Party, another Team 17 title, so I'm
still betting on a WINE bug.

Indeed....late last night, I put in overrides for the dinput dll's
and eventually got a match to start. Right click works (weapon select
panel), but left mouse click does nothing, keyboard does nothing, my
worms scream and die 'coz they can't fight back ;D

Worms World Party gets a garbage rating over at WineHQ...see;

http://appdb.winehq.org/objectManager.php?sClass=version&iId=3905&iTestingId=10082

Someone has allegedly got Worms Armageddon running in wine-1.1.26...see;

http://appdb.winehq.org/objectManager.php?sClass=version&iId=1744&iTestingId=42802

I've had a bit of a read of various threads over at WineHQ related to these Team17
titles, and comparing results there with results -here- using crossover-games, has
me seeing great disparity of results....enough to suggest this problem is inherit
in Wine somewhere.....

I think it's important to make the distinction that although the games and problems are similar, they aren't the same. Worms World Party has not worked for anyone as far as I'm aware, whereas Worms Armageddon works for a number of people, including myself.

The reason for that could be that W:A Beta versions don't have any copy protection, whereas older (1.0 and 3.0) versions of W:A and AFAIK all versions of WWP use a copy protection driver.

It's true; they talked about it on the Team 17 forum. The beta versions are the only versions that allow a CD image to be used instead of a CD as they removed most of the copy protection.

Cameron wrote:

I think it's important to make the distinction that although the
games and problems are similar, they aren't the same. Worms World
Party has not worked for anyone as far as I'm aware, whereas Worms
Armageddon works for a number of people, including myself.

Indeed, what you say is true...however, I have gone to lengths to identify that
my postings here are only 'background static' related to another Team17 Worms
title doing the same things...and of course, the original poster here (Pete) is
very aware of the position I'm presenting here...

It's good that you make this assertion however, so that people don't become
confused/get the wrong idea about Worms Armageddon...thanks!!

Now I have a valid copy, I have installed the Beta version of 3.6.29.0, and I can actually run the game, but I get a black screen (Yes I did set up desktop mode) and if I blindly click, I can add some default teams and start a game.

Once in the battle, I see the worms, I can use the mouse to pan the screen, but once again, just like the hacked copy I have, you cannot move, you cannot select weapons, you cannot play the game.

Pete Posted:

Now I have a valid copy, I have installed the Beta version of 3.6.29.0, and I can actually run the game, but I get a black screen (Yes I did set up desktop mode) and if I blindly click, I can add some default teams and start a game.

Once in the battle, I see the worms, I can use the mouse to pan the screen, but once again, just like the hacked copy I have, you cannot move, you cannot select weapons, you cannot play the game.

I managed to buy a copy of Worms Armageddon off ebay in .au (it
was in my mailbox this morning). This is the same software house
release as my copy of Worms World Party --both discs are labeled
as being from 'Big Bytes' software, and then licensed to/by
'Red Ant Enterprises' -- it certainly looks an 'official' release
of the game....

What you describe here is exactly what I get, with either W.A.
or W.W.P....both titles behave exactly the same, regardless of
which official patches you apply...something is broken somewhere.

Wine-1.1.32 is doing exactly the same thing btw...I'll put an
hour aside this weekend to see if I can get a useful debug trace
on this issue.....

Remember, the official support mechanism is the ticket system ;
I've just had a browse, and there is still an active ticket open
for W.W.P.....see;

http://www.codeweavers.com/support/tickets/browse/?ticket_id=618061

I'll let Andrew Balfour know that I want to be added to that ticket,
and I'll start debugging W.W.P. in that arena....

@Pete - it's probably a good idea for you to open a support ticket
on this for Worms Armageddon (or send an email to info@codeweavers.com
in the same regard) -- although it looks like exactly the same issue
at play with both titles, they should be kept as separate entries in
the support ticket system -- now that I have a copy of W.A. to check
with, I can also add to your ticket to help there...

..oh, and yes, it may be DRM and we're flogging a dead worm at the
moment, but we won't really know that until we look real hard at things...

Cheers!

BTW, if I run this with the patch I had referenced earlier through WINE 1.1.31, I get graphics and sound just fine! It's the keyboard/mouse input that is broken during battle. I will send this information to the ticket system thanks.

This totally slipped my mind earlier, but you may need to set it to run in a virtual desktop. WA does some weird things with windows and keyboard focus, and they may not work in your window manager of choice.

Esme Povirk wrote:

This totally slipped my mind earlier, but you may need to set it to
run in a virtual desktop. WA does some weird things with windows and
keyboard focus, and they may not work in your window manager of
choice.

Yes, I have already configured the graphics to use a Virtual Desktop of 800 x 600. Without that enabled, the game crashes when you attempt to click on any menu options from the first screen.

Pete Lesko wrote:

BTW, if I run this with the patch I had referenced earlier through
WINE 1.1.31, I get graphics and sound just fine! It's the
keyboard/mouse input that is broken during battle. I will send this
information to the ticket system thanks.

Good one....Andrew got back to me, and said it's probably not worth my
trouble adding to that old W.W.P. support ticket I referenced above.
He did indicate however that's he's had a look at this thread, so he's
now aware of our endeavors here for sure. Sometime over the weekend I
may create a new ticket for W.W.P. once I get some debug under my belt...

@Pete -- could you tell me your OS/videocard/videodriver specs please?
(you can view my bio for information about my situation in these regards)

Just recapping this lot;

Pete Posted;

Perhaps these dialogs are grabbing focus and not returning them to the parent window?

I got the same impression...ie; after the intro finishes the mouse pointer briefly
appears...and then disappears again once the menu loads...but the mouse focus/input
seems to be working here even though we can't see it. Of course, the frustrating
quirk about this, is if you get a game to start, you -can- see the mouse pointer
just fine....but the input then stops working (including keyboard)...weird, huh? ;)

As I use a twinview setup, I invariably have 'emulate a virtual desktop' set ON in
winecfg ; now that I've a copy of W.A. myself, I disabled virtual desktop and get
the same crash error Pete reported;

fixme:win:LockWindowUpdate ((nil)), partial stub!

Another thing here....these lines;

fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 8
fixme:d3d:IWineD3DDeviceImpl_CreateSwapChain The app requests more than one back buffer, this can't be supported properly. Please configure the application to use double buffering(=1 back buffer) if possible

I have another totally unrelated title that was complaining in similar fashion,
but iirc this stopped with wine-1.1.32, and in that case, the demo of that title
(Rollcage) then started to work (previously it would just crash on this machine)

@Pete -- it might be worth our while to try the demo of the title(s), which
should (in theory at least) remove the possibility that DRM is smiting us - if
we get exactly the same behavior with the demos it will better conclude the what
of things happening here...(and you sort of hope the demos do behave the same
way, 'coz this give the devs here something to download and look at themselves)

Cheers!

Don,

My setup:

Debian Unstable (kernel 2.6.30-2-686 #1 SMP) on an AMD Athlon(tm) 64 Processor 4000+
02:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce 8500 GT] (rev a1)
nVidia driver from the website: NVIDIA-Linux-x86-185.18.36-pkg1.run

I'll give the demo a shot, but I can't say I have much faith when my pirated version of WA also had the same keyboard/mouse input problems 😀

Pete Lesko wrote:

My setup:

Debian Unstable (kernel 2.6.30-2-686 #1 SMP) on an AMD Athlon(tm) 64
Processor 4000+
02:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce
8500 GT] (rev a1)
nVidia driver from the website: NVIDIA-Linux-x86-185.18.36-pkg1.run

I'll give the demo a shot, but I can't say I have much faith when my
pirated version of WA also had the same keyboard/mouse input
problems 😀

Thanks for that...one of my boxes here is very close to that spec. (same CPU, 8400GS
nvidia card, same nvidia drivers, 2.6.29 on a Deb 5.0 +updates)..

I share you skepticism regarding the demos....probably even more so since
I just tried the wwp_demo.exe and it won't even start ;) That'll be another
thing to look into -- I should say, lesson learnt here - I've been liasing
with one of the devs here regarding the RollCage demo, and the demo of that
title actually worked for him, but strangely didn't work at all for me....
until wine-1.1.32 came out -- the RollCage demo actually works here now
with that Wine release, but it's still not with COG-8.0 ....

So you see, that's how mobile and grey this stuff can be at times - remember,
we've still got people here who are running W.A. fine...actually...

On that point, if anyone reading this thread does have W.A. running under
COG (I'll take any version there ;), could you share your OS/platform/videocard
information with us please? Details like that may help/clarify what and
where things are running off the rails here.

Cheers!

Edit: Just a note regarding the W.A. demo I just grabbed -- typically I'll
leave my bottle_profile set at winxp, and give that a shot. If things don't
pan out as expected, then I'll try another bottle_profile. During the W.A.
demo installation, at the end it pops a box saying it's not compatible with
my OS (winxp bottle), and would I like to download a patch for XP/2000. It
was probably expecting something different to happen next..ie; IE (internet
explorer ;) - my native firefox browser ended up receiving that call, and
grabbed the following file;

http://38.108.189.227/o=64/b=kOmx0sTIWuZ18YIjRTOZcwAAAAAAAAAAAAAAAAAAAAAABUOTub1Opw+B4ai5zwRnbm9uZQAAAAAAAAAAAAAAAEFVRAAAAAAAACVwElaGaJQ=/t=1256953294/h=62a1a4728517b6f1e228ccb27213dcfb/r/release/team17/20m_d_p3050b/WA_P3050_Beta2.exe

Boy howdy...that was actually coming from the TryMedia site (perhaps the funky
URL tagging was the demo installer's doing)...but anyhow, the installer bailed
(completed sucessfully) when all this happened, so if you want to apply the
patch, you'll have to do that manually by the looks of it...still, I'll give
it a shot as is first with my bottle_profile set back to win98...more later,
this was just a heads-up sort of note...

demo version linux/COG-8.0

I came across 2 W.A. demo versions, one is from TryMedia, (this is
the version I mentioned in my previous post here)...;

WormsArmageddon.exe 144610721 bytes

The other, is the Team17 demo of W.A. (link on the Team17 page seems
broken, but I found it on fileplanet.com...;

WaDemo.exe 13931008 bytes

The Team17 demo of W.A. does exactly the same things as the full
version -- black screen, invisible mouse, blablabla. This is good
all told, as the devs have something to download and pine over. The
URL of this demo download is;

http://www.fileplanet.com/11582/10000/fileinfo/Worms-Armageddon

If there is any DRM in the demo version, it would have to do
with time limiting the gameplay for demonstration purpose (guessing
wildly here ;) Definitely wanted bottle_profile=win98 and 'emulate
a virtual desktop' set to 640x480 before it would do anything at all.

I know we're being somewhat dismissive of the TryMedia version here,
however, the results of trying that demo are worth recording I think;

Without applying the patch 'WA_P3050_Beta2.exe' and setting the
bottle_profile=win98 and 'emulate a virtual desktop' set to 640x480,
the title starts -- you get menus you can see, they work, the mouse
pointer is visible ..and works ; launch a game results in a blackscreen
dead end...(sigh)...

With the patch 'WA_P3050_Beta2.exe' applied and bottle_profile=winxp
and 'emulate a virtual desktop' set to 640x480, it actually calls ieframe
to display a start-screen (buy now or continue playing for the 19mins you
have left page) -- clicking the 'play now' does absolutely nothing - the
ieframe stays hoisted, and things sit there doing nothing, blackscreen,
another dead end ;)

In the latter case here, I happen to know devel-wine's gecko started
working better as of ..umm....wine-1.1.31....so I'll give that a shot
later out of curiosity (ieframe is part of the gecko framework)...I
found the TryMedia demo of W.A. here...;

http://www.gamershell.com/download_35824.shtml

Looks like I've an interesting weekend's task here ;-D

Cheers!

Just another tiny note here -- I just discovered the demo of W.W.P. requires
MSVCP60.dll to actually run - this dependency is satisfied by installing the
'Microsoft Virtual C++ 6.0 Redistributable' package (it's an available target
in cxinstallwizard after ticking 'show all service packs and dependencies')
Now the W.W.P. demo does exactly the same same thing as the release version,
that is, it doesn't work and has the same blackscreen issue...
Woohoo! ;-]

Edit: A bit more on this - installation of W.A. from the CD I have, actually
installs a copy of MSVCP60.dll into the game $installdir - obviously the game
executable knows to look in it's pwd for the *.dll files it needs (there are
quite a few). My hovercraft is full of eels...

Another tid-bit from the W.W.P demo using wine-1.1.32 -- this is just
for reference here. Behavior is the same wrt to the blackscreen where
the menu graphics should be. Again, streams of the following at the
same time this is happening;

fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK

I'm getting pretty good now at clicking in the dark and getting a
match going (perhaps I need counseling ;) Once that happens and the
cake loadscreen appears briefly before the game itself - the console
chatter from wine at this time goes as follows;

fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK
err:d3d_surface:IWineD3DSurfaceImpl_ModifyLocation 0x1622230: Surface does not have any up to date location
err:d3d_surface:IWineD3DSurfaceImpl_ModifyLocation 0x1622230: Surface does not have any up to date location
err:d3d_surface:IWineD3DSurfaceImpl_ModifyLocation 0x16215b8: Surface does not have any up to date location
err:d3d_surface:IWineD3DSurfaceImpl_ModifyLocation 0x16215b8: Surface does not have any up to date location
err:d3d_surface:IWineD3DSurfaceImpl_ModifyLocation 0x1620940: Surface does not have any up to date location

I'm pretty sure that trace is different from what our COG wine branch
is doing. (that's fairly unsurprizing considering how mobile wine is)

I noticed another thing -- if I do click enough times in a match/game
screen, eventually (short time) my system bell (PC speaker) starts
beeping on any mouse click..full buffer? invalid co-ords?...weird..

W.A. (Team17(demo)) is next on the rack...

W.A. demo (Team17 version) using wine-1.1.32 - pretty much identical results
to those obtained with the Team17 W.W.P. demo and wine-1.1.32 (haven't been
able to launch a game/match yet), but the menus at doing the same thing, I'm
seeing the same error trace there too, I'll guess the mouse/keyboard input
is misbehaving in the same fashion -- I'll try confirm this and note it here.

Worms Armageddon demo (TryMedia version) using wine-1.1.32 - as we now know,
this demo wants to work in one of two ways (with/without patch) depending
on what winOSversion is detected -- tried the win98 settings first ; using
wine-1.1.32 it didn't want to run at all no matter what I did (at least in
COG-8.0 I was getting menus)...so it looks like something has 'moved' there.

Changing the winOSversion to winxp, then applying their patch, doesn't
help matters any - actually, gecko was having a hard time of it too (the
Crossover HTML engine displays the page better), but in both cases, pressing
on the 'play now' button doesn't work.

So the TryMedia release is problematic as well...

Just to be nice and tidy, I've tried both my CD copies of these titles
(and the so related Team17 demos of same) on a -real- win98 box, and
everything works correctly in the worm's native domain ;)

I've mentioned in my ticket description, that I'm pretty sure this was
issue present with these Team17 Worms titles and COG-7.2.x, so it's
not a regression afaict. Hmm...I'll probably next let stable Wine (1.0.1)
have at both the Team17 demos, just to check what the situation is wrt
that stable Wine build (look for a possible regression in Wine)...

Cheers!

Just wanted to say that in my opinion the TryMedia version isn't worth a lot of attention. Since it's locked to an old version of the game and can't benefit from the new features in Beta versions, it's pretty much considered crippled in W:A's community.

There have been several changes in the game code that should improve compatibility with Wine and newer Windows versions. Unless there's the possibility of a regression, compatibility efforts should be concentrated on the latest Beta versions. Note that all WWP versions and the W:A demo all have an old codebase, with poor compatibility with newer Windows versions. It's possible that a new W:A demo will be released later, with all the compatibility fixes of the Beta versions.

Vladimir Panteleev wrote:

Just wanted to say that in my opinion the TryMedia version isn't
worth a lot of attention. Since it's locked to an old version of the
game and can't benefit from the new features in Beta versions, it's
pretty much considered crippled in W:A's community.

There have been several changes in the game code that should improve
compatibility with Wine and newer Windows versions. Unless there's
the possibility of a regression, compatibility efforts should be
concentrated on the latest Beta versions. Note that all WWP versions
and the W:A demo all have an old codebase, with poor compatibility
with newer Windows versions. It's possible that a new W:A demo will
be released later, with all the compatibility fixes of the Beta
versions.

Hi Vladimir,

Thank you for your insights here, especially wrt the TryMedia version ;
I'll be utterly dismissive in that regard henceforth (and save myself
time in testing all up ;) Typically, I only rope-in a demo version test,
if the demo demonstrates the same issues with crossover/wine as I'm seeing
when I use the release versions of same (CD) ...and then with or without
any official patches...however...

Seeing as you would like us to concentrate on the -latest- BETA, so be it!
I'll make sure any of my winedbg logs attached to my ticket, are indicative
of the usage you would like us to focus on -- I'll do some regression testing
later this afternoon in these regards...thanks muchly for the guideposts ;)

Cheers!

W.A. with latest WA_PATCH (3.6.29.0) - using stable wine-1.0.1;

We're not so happy with this vintage of wine ;

bash-3.2$ wine WA.exe
fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and 32 total samplers
fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers
fixme:win:EnumDisplayDevicesW ((null),0,0x33ae4c,0x00000000), stub!
fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 8
fixme:quartz:AsyncReader_QueryInterface No interface for {56a868b3-0ad4-11ce-b03a-0020af0ba770}!
fixme:quartz:Parser_QueryInterface No interface for {56a868b3-0ad4-11ce-b03a-0020af0ba770}!
fixme:quartz:MediaPosition_put_CurrentPosition (0x6add598)->(0.000000) stub!
err:quartz:Parser_Destroy pinref should be null, is 1, destroying anyway
fixme:win:LockWindowUpdate ((nil)), partial stub!
fixme:win:LockWindowUpdate ((nil)), partial stub!
fixme:win:LockWindowUpdate ((nil)), partial stub!
wine: Unhandled page fault on read access to 0x00000004 at address 0x44ab80 (thread 0009), starting debugger...
Unhandled exception: page fault on read access to 0x00000004 in 32-bit code (0x0044ab80).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:0044ab80 ESP:0033d530 EBP:0033d53c EFLAGS:00010202( - 00 - -RI1)
EAX:00000000 EBX:7e9eb540 ECX:00000000 EDX:00000000
ESI:00000000 EDI:00020024
Stack dump:
0x0033d530: 00000000 00000000 00000000 0033d550
0x0033d540: 0044aa16 00000000 00000000 0033d5b0
0x0033d550: 0033d5b0 00488bf7 00000000 00000000
0x0033d560: 0033e438 0033d594 00000000 ffffffff
0x0033d570: 005faa1e 005f877d 007c3080 00000004
0x0033d580: 007c3080 0033f890 0033f8e4 0033f890
Backtrace:
=>1 0x0044ab80 in wa (+0x4ab80) (0x0033d53c)
2 0x0044aa16 in wa (+0x4aa16) (0x0033d550)
3 0x00488bf7 in wa (+0x88bf7) (0x0033d5b0)
4 0x005f5148 in wa (+0x1f5148) (0x0033d5b8)
5 0x7e9c8a3a WINPROC_wrapper+0x1a() in user32 (0x0033d5e8)
6 0x7e9ca828 call_dialog_proc+0x68(hwnd=<register EDI not in topmost frame>, msg=0x110, wp=0x0, lp=0x0, result=0x33d65c, ar
g=0x5f5117) [/usr/local/wine-1.0.1/dlls/user32/winproc.c:479] in user32 (0x0033d628)
7 0x7e9cdda3 WINPROC_CallDlgProcA+0x53(func=0xffff002f, hwnd=0x20024, msg=0x110, wParam=0x0, lParam=0x0) [/usr/local/wine-1
.0.1/dlls/user32/winproc.c:2364] in user32 (0x0033d668)
8 0x7e955f77 DefDlgProcA+0x87(hwnd=<register ESI not in topmost frame>, msg=<register EDI not in topmost frame>, wParam=0x0
, lParam=0x0) [/usr/local/wine-1.0.1/dlls/user32/defdlg.c:437] in user32 (0x0033d698)
9 0x7e9c8a3a WINPROC_wrapper+0x1a() in user32 (0x0033d6c8)
10 0x7e9c90ce call_window_proc+0x6e(hwnd=<register EDI not in topmost frame>, msg=0x110, wp=0x0, lp=0x0, result=0x33d740, a
rg=0x7e955ef0) [/usr/local/wine-1.0.1/dlls/user32/winproc.c:457] in user32 (0x0033d708)
11 0x7e9cded2 CallWindowProcA+0x52(func=0x7e955ef0, hwnd=0x20024, msg=0x110, wParam=0x0, lParam=0x0) [/usr/local/wine-1.0.1
/dlls/user32/winproc.c:2286] in user32 (0x0033d748)
12 0x005ef7bb in wa (+0x1ef7bb) (0x0033d768)
13 0x005f14a3 in wa (+0x1f14a3) (0x0033d824)
14 0x005ef8da in wa (+0x1ef8da) (0x0033d844)
15 0x005f1ce1 in wa (+0x1f1ce1) (0x0033d8ac)
16 0x005f1d70 in wa (+0x1f1d70) (0x0033d8cc)
17 0x7e9c8a3a WINPROC_wrapper+0x1a() in user32 (0x0033d8fc)
18 0x7e9c90ce call_window_proc+0x6e(hwnd=<register EDI not in topmost frame>, msg=0x110, wp=0x0, lp=0x0, result=0x33e070, a
rg=0x5f1d3a) [/usr/local/wine-1.0.1/dlls/user32/winproc.c:457] in user32 (0x0033d93c)

...etc etc, we crash, we burn, innocent worms die...

-Before- applying the WA_Patch, I did get one match/game to start,
and although I could hear the game-play running, the screen/window
was all white...by the sound of it, I didn't have any keyboard/mouse
input either...

I will mention this -- with wine-1.0.1 the WA_Patch installer itself,
the progress bars in the installer GUI are all blacked-out as well ;
it might just be coincidence or a clue to something else....

At any rate, it doesn't appear to be a regression in mainstream Wine.

FWIW: the above crash happened because W:A tried to display a message box, but wasn't completely initialized (a sound sample wasn't loaded), and it tried to play a NULL sound sample. I don't see what caused the message box to be displayed, as that would be further down the stack trace. I'll add some NULL checks where appropriate.

Vladimir Panteleev wrote:

FWIW: the above crash happened because W:A tried to display a
message box, but wasn't completely initialized (a sound sample
wasn't loaded), and it tried to play a NULL sound sample. I don't
see what caused the message box to be displayed, as that would be
further down the stack trace. I'll add some NULL checks where
appropriate.

The rest of that trace - ;

19 0x7e9ce865 WINPROC_CallProcWtoA+0x815(callback=0x7e9c9060, hwnd=0x20024, msg=<register EDI not in topmost frame>, wParam
=0x0, lParam=0x0, result=0x33e070, arg=0x5f1d3a) [/usr/local/wine-1.0.1/dlls/user32/winproc.c:1267] in user32 (0x0033dfcc)
20 0x7e9cf37b WINPROC_call_window+0x15b(hwnd=<register ESI not in topmost frame>, msg=0x110, wParam=0x0, lParam=0x0, result
=0x33e070, unicode=0x1, mapping=0xa006e) [/usr/local/wine-1.0.1/dlls/user32/winproc.c:2200] in user32 (0x0033e00c)
21 0x7e99103a call_window_proc+0xca(hwnd=<register ESI not in topmost frame>, msg=0x110, wparam=0x0, lparam=0x0, unicode=0x
1, same_thread=0x1, mapping=0xa006e) [/usr/local/wine-1.0.1/dlls/user32/message.c:1610] in user32 (0x0033e07c)
22 0x7e9942ed send_message+0x20d(info=<register EDI not in topmost frame>, res_ptr=0x33e118, unicode=0x1) [/usr/local/wine-
1.0.1/dlls/user32/message.c:2434] in user32 (0x0033e0dc)
23 0x7e99475a SendMessageW+0x4a(hwnd=0x20024, msg=0x110, wparam=0x0, lparam=0x0) [/usr/local/wine-1.0.1/dlls/user32/message
.c:2557] in user32 (0x0033e11c)
24 0x7e95b69c DIALOG_CreateIndirect+0xb1c(hInst=0x400000, dlgTemplate=<is not available>, owner=0x0, dlgProc=0x5f5117, para
m=0x0, unicode=0x0, modal=0x0) [/usr/local/wine-1.0.1/dlls/user32/dialog.c:665] in user32 (0x0033e2ec)
25 0x7e95c8c6 CreateDialogIndirectParamAorW+0x36(hInst=0x400000, dlgTemplate=0x988230, owner=0x0, dlgProc=0x5f5117, param=0
x0, flags=0x2) [/usr/local/wine-1.0.1/dlls/user32/dialog.c:725] in user32 (0x0033e30c)
26 0x7e95c9f1 CreateDialogIndirectParamA+0x41(hInst=0x400000, dlgTemplate=0x988230, owner=0x0, dlgProc=0x5f5117, param=0x0)
[/usr/local/wine-1.0.1/dlls/user32/dialog.c:734] in user32 (0x0033e33c)
27 0x005f57ed in wa (+0x1f57ed) (0x0033e3b0)
28 0x00462cae in wa (+0x62cae) (0x0033e424)
29 0x004fc44b in wa (+0xfc44b) (0x0033fd5c)
30 0x004f1296 in wa (+0xf1296) (0x0033fdc4)
31 0x004f0181 in wa (+0xf0181) (0x0033fdd0)
32 0x004f6c25 in wa (+0xf6c25) (0x0033fe24)
33 0x0063877d in wa (+0x23877d) (0x0033fe2c)
34 0x0060fe2e in wa (+0x20fe2e) (0x0033fe70)
35 0x0060fed7 in wa (+0x20fed7) (0x0033fe84)
36 0x00610e7c in wa (+0x210e7c) (0x0033ff08)
37 0x7ee3e267 start_process+0xc7(arg=0x0) [/usr/local/wine-1.0.1/dlls/kernel32/process.c:904] in kernel32 (0x0033ffe8)
38 0xf7de15c7 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000)
0x0044ab80: movl 0x4(%ecx),%edx

@Vladimir -- if you want any copies of debug, or any specific debug flags, just let me know.

Thanks. It looks like it can't save the team file while exiting (the team file is stored under User\Teams\WG.WGT), however it looks like it's exiting "normally" so this would be weird if crashing is the only effect of running W:A.

I'd be hard to credit right now, but I just reinstalled W.A. three
or 4 times trying different approaches with COG-8.0 - on the last
attempt, it suddenly decided to work. By 'different approaches',
I mean probably the first approach (if one sees it), is to use the
worms armageddon target in the cxinstallwizard GUI or winecfg GUI.
Or you can choose to ignore that...or create/setup the bottle first
and then install into that - the latter here just scared me to death
and worked...it went like this ;

start cxsetup (or cxbottlemanager)=>Manage Bottles=>create a new win98 bottle named WA
highlight the WA bottlw=>Configure=>Control Panel=>winecfg
In the winecfg GUI applications tab, set Windows Version to Windows 98
In the winecfg GUI Graphics tab, turn ON 'Emlulate a virtual desktop' - set desktop size to 640x480
In the winecfg GUI Audio tab ...when you click this tab for the first time, it pops a window
saying it's picked system default or such, OK that window, now click on apply in winecfg=>ok
Now in the Add/Remove tab of cxsetup/cxbottlemanager, highlight the WA bottle, and click on 'Install software'
Assuming you've aready got your W.A. disc mounted, the cxinstaller will automatically choose /media/disk
(or /media/cdrom or such), instead, select 'other installer file' and point it at the setup.exe file on the CD
Game should install cleanly from CD - my disk prompts me if I want to install directx8 - I always decline - no not start game
copy the official latest BETA patch into the WA bottle dir...(assuming you've downloaded this file to your homedir);

bash-3.2$ cp ~/WA_update-3.6.29.0_Beta_Installer.exe "~/.cxgames/WA/drive_c/Program Files/Team17/Worms Armageddon/"

Still in cxsetup or such, highlight the WA bottle=>Configure=>Control Panel=>Run
Use the 'browse' button and point it at the WA_update-3.6.29.0_Beta_Installer.exe copied above - run it to apply the patch

Now ok/exit all that jazz, and see if W.A. works - like I say, out of the blue, it just started
to work here using the above procedure...,

@Pete -- when you get a spare moment, can you give the above a whirl, and see if it holds true for you?

Although it is seemingly now working, it is throwing biscuits and crashing after hitting
the 'Exit' game button...I'll have to recreate this a few times just to make sure I'm
not going nuts ;)

@Vladimir - I'll grab a trace from COG-8.0 wrt the crash on exit thing, just as
soon as I'm sure the above holds true (and if then other methods of installation
still do/don't work) - there wasn't, by way of coincidence, any update to the
content of the updated graphics-pack the patch installer routinely downloads,
that might explain this turn around?

Cheers!

Artist Formally Known as Dot wrote:

@Vladimir - I'll grab a trace from COG-8.0 wrt the crash on exit
thing, just as
soon as I'm sure the above holds true (and if then other methods of
installation
still do/don't work) - there wasn't, by way of coincidence, any
update to the
content of the updated graphics-pack the patch installer routinely
downloads,
that might explain this turn around?

Not really, the GFX update only installs two new files (Data\Gfx\Gfx0.dir and Gfx1.dir).

Not-directly-related:
I've been testing some tweaks in W:A to get better Wine and CxGames compatibility on Mac (the next Beta will detect Wine and offer to enable some compatibility tweaks). I checked again (I should really write down the results of my research) and I noticed that with my current configuration, 3.6.28.0 crashes after the intro sequence while 3.6.29.0 exits silently after starting (not yet sure why). Note that running the 3.6.28.0 EXE with the /nointro command-line parameter bypasses the intro and the crash that follows it. The newest alphas (non-public WIP builds) work fine, though.

Some things to note when testing different W:A versions:
AFAIK CxGames 8.0 has special compatibility options for "wa.exe". For example, with my current setup W:A 3.6.28.0 as WA.exe runs fine (aside aforementioned problem), while with the EXE renamed to something else it shows a black screen.
running W:A from the WA.exe executable runs W:A fine, while as anything else it just shows a black screen. IIRC, this is because as WA.exe it uses the GDI renderer (OSLT), otherwise it'll use the OpenGL renderer which won't work with W:A's front-end. There are several most-likely-unrelated regressions in 3.6.29.0, so .28 is still somewhat supported.

I'm going to dig through my logs and mess around some more, and see if I can get 3.6.29.0 to run (although 3.6.30.0 should be released Real Soon Now).

Vladimir Panteleev wrote:

3.6.29.0 exits silently after starting (not yet sure why)

Disregard that, it works fine. I believe it was crashing because I overwrote some files with older versions.

Regarding the crash-on-exit problem - does the directory User\Teams exist and is it writable by W:A?

Okay, thanks for that...and for the further insights wrt W.A.

I've installed and blown away a few bottles worth of worms using
the above procedure, and it seems to work as expected everytime
time. Indeed, I am aware W.A. is supported and has an install
target - what I think I may be seeing here, is that facility
getting things wrong somehow -- I'll probably dig into that aspect
of it tomorrow and try to confirm and/or dismiss that angle.

Regarding the crash on exit (Quit button) issue with COG-8.0, I've
gathered the following +seh trace -- we pick up the action, with me
having already started wa.exe and navigated into menus, and then
have clicked 'Exit' => 'Exit' => 'Quit' ..;

trace:seh:raise_exception info[0]=00000000
trace:seh:raise_exception info[1]=06e78340
trace:seh:raise_exception eax=06de0000 ebx=06e78340 ecx=00000002 edx=00000000 esi=06e78340 edi=06de0000
trace:seh:raise_exception ebp=003385c8 esp=003385c0 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010212
trace:seh:call_vectored_handlers calling handler at 0x7e718d50 code=c0000005 flags=0
trace:seh:call_vectored_handlers handler at 0x7e718d50 returned ffffffff
fixme:win:LockWindowUpdate ((nil)), partial stub!
fixme:win:LockWindowUpdate ((nil)), partial stub!
fixme:win:LockWindowUpdate ((nil)), partial stub!
trace:seh:raise_exception code=c0000005 flags=0 addr=0x617cca ip=00617cca tid=0018
trace:seh:raise_exception info[0]=00000000
trace:seh:raise_exception info[1]=01c50fc0
trace:seh:raise_exception eax=01c51000 ebx=7eb2655c ecx=00000010 edx=00000000 esi=01c50fc0 edi=01c60000
trace:seh:raise_exception ebp=0033d1fc esp=0033d1f4 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010212
trace:seh:call_vectored_handlers calling handler at 0x7e718d50 code=c0000005 flags=0
trace:seh:call_vectored_handlers handler at 0x7e718d50 returned ffffffff
trace:seh:raise_exception code=c0000005 flags=0 addr=0x44ab80 ip=0044ab80 tid=0018
trace:seh:raise_exception info[0]=00000000
trace:seh:raise_exception info[1]=00000004
trace:seh:raise_exception eax=00000000 ebx=7eb2655c ecx=00000000 edx=00000000 esi=00000000 edi=00020030
trace:seh:raise_exception ebp=0033d38c esp=0033d380 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010202
trace:seh:call_vectored_handlers calling handler at 0x7e718d50 code=c0000005 flags=0
trace:seh:call_vectored_handlers handler at 0x7e718d50 returned 0
trace:seh:call_vectored_handlers calling handler at 0x7b850920 code=c0000005 flags=0
trace:seh:call_vectored_handlers handler at 0x7b850920 returned 0
trace:seh:call_vectored_handlers calling handler at 0x7b83dac0 code=c0000005 flags=0
trace:seh:call_vectored_handlers handler at 0x7b83dac0 returned 0
trace:seh:call_stack_handlers calling handler at 0x62def8 code=c0000005 flags=0
trace:seh:call_stack_handlers handler at 0x62def8 returned 1
trace:seh:call_stack_handlers calling handler at 0x62a236 code=c0000005 flags=0
trace:seh:call_stack_handlers handler at 0x62a236 returned 1
trace:seh:call_stack_handlers calling handler at 0x62a16a code=c0000005 flags=0
trace:seh:call_stack_handlers handler at 0x62a16a returned 1
trace:seh:call_stack_handlers calling handler at 0x62a33d code=c0000005 flags=0
trace:seh:call_stack_handlers handler at 0x62a33d returned 1
trace:seh:call_stack_handlers calling handler at 0x6359d8 code=c0000005 flags=0
trace:seh:call_stack_handlers handler at 0x6359d8 returned 1
trace:seh:call_stack_handlers calling handler at 0x635c2b code=c0000005 flags=0
trace:seh:call_stack_handlers handler at 0x635c2b returned 1
trace:seh:call_stack_handlers calling handler at 0x62b478 code=c0000005 flags=0
trace:seh:call_stack_handlers handler at 0x62b478 returned 1
trace:seh:call_stack_handlers calling handler at 0x62ec3c code=c0000005 flags=0
trace:seh:call_stack_handlers handler at 0x62ec3c returned 1
trace:seh:call_stack_handlers calling handler at 0x612c80 code=c0000005 flags=0
trace:seh:call_stack_handlers handler at 0x612c80 returned 1
trace:seh:call_stack_handlers calling handler at 0x612c80 code=c0000005 flags=0
trace:seh:call_stack_handlers handler at 0x612c80 returned 1
trace:seh:call_stack_handlers calling handler at 0x7b86f120 code=c0000005 flags=0
wine: Unhandled page fault on read access to 0x00000004 at address 0x44ab80 (thread 0018), starting debugger...
trace:seh:start_debugger Starting debugger "winedbg --auto 23 124"
trace:seh:call_stack_handlers handler at 0x7b86f120 returned 1
Unhandled exception: page fault on read access to 0x00000004 in 32-bit code (0x0044ab80).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:0044ab80 ESP:0033d380 EBP:0033d38c EFLAGS:00010202( R- -- I - - - )
EAX:00000000 EBX:7eb2655c ECX:00000000 EDX:00000000
ESI:00000000 EDI:00020030
Stack dump:
0x0033d380: 00000000 00000000 00000000 0033d3a0
0x0033d390: 0044aa16 00000000 00000000 0033d400
0x0033d3a0: 0033d400 00488bf7 00000000 00000000
0x0033d3b0: 0033e438 0033d3e4 00000000 ffffffff
0x0033d3c0: 005faa1e 005f877d 007c3080 00000004
0x0033d3d0: 007c3080 0033f890 0033f8e4 0033f890
Backtrace:
=>0 0x0044ab80 in wa (+0x4ab80) (0x0033d38c)
1 0x0044aa16 in wa (+0x4aa16) (0x0033d3a0)
2 0x00488bf7 in wa (+0x88bf7) (0x0033d400)
3 0x005f5148 in wa (+0x1f5148) (0x0033d408)
4 0x7eb0181a WINPROC_wrapper+0x1a() in user32 (0x0033d438)
5 0x7eb03525 in user32 (+0xb3525) (0x0033d478)
6 0x7eb06caa in user32 (+0xb6caa) (0x0033d4c8)
7 0x7ea8d892 DefDlgProcA+0x82() in user32 (0x0033d4f8)
8 0x7eb0181a WINPROC_wrapper+0x1a() in user32 (0x0033d528)
9 0x7eb01ecb WINPROC_wrapper+0x6cb() in user32 (0x0033d568)
10 0x7eb06dda CallWindowProcA+0x5a() in user32 (0x0033d5b8)
11 0x005ef7bb in wa (+0x1ef7bb) (0x0033d5d8)
12 0x005f14a3 in wa (+0x1f14a3) (0x0033d694)
13 0x005ef8da in wa (+0x1ef8da) (0x0033d6b4)
14 0x005f1ce1 in wa (+0x1f1ce1) (0x0033d71c)
15 0x005f1d70 in wa (+0x1f1d70) (0x0033d73c)
16 0x7eb0181a WINPROC_wrapper+0x1a() in user32 (0x0033d76c)
17 0x7eb01ecb WINPROC_wrapper+0x6cb() in user32 (0x0033d7ac)
18 0x7eb04d01 in user32 (+0xb4d01) (0x0033de5c)
19 0x7eb07017 in user32 (+0xb7017) (0x0033de9c)
20 0x7eac78de in user32 (+0x778de) (0x0033defc)
21 0x7eacbd23 in user32 (+0x7bd23) (0x0033df5c)
22 0x7eacc1ca SendMessageW+0x4a() in user32 (0x0033df9c)
23 0x7ea93027 in user32 (+0x43027) (0x0033e2ec)
24 0x7ea941f4 CreateDialogIndirectParamAorW+0x34() in user32 (0x0033e30c)
25 0x7ea94322 CreateDialogIndirectParamA+0x42() in user32 (0x0033e33c)
26 0x005f57ed in wa (+0x1f57ed) (0x0033e3b0)
27 0x00462cae in wa (+0x62cae) (0x0033e424)
28 0x004fc44b in wa (+0xfc44b) (0x0033fd5c)
29 0x004f1296 in wa (+0xf1296) (0x0033fdc4)
30 0x004f0181 in wa (+0xf0181) (0x0033fdd0)
31 0x004f6c25 in wa (+0xf6c25) (0x0033fe24)
32 0x0063877d in wa (+0x23877d) (0x0033fe2c)
33 0x0060fe2e in wa (+0x20fe2e) (0x0033fe70)
34 0x0060fed7 in wa (+0x20fed7) (0x0033fe84)
35 0x00610e7c in wa (+0x210e7c) (0x0033ff08)
36 0x7b872ef8 in kernel32 (+0x52ef8) (0x0033ffe8)
37 0xf7e5ca9d wine_call_on_stack+0x1d() in libwine.so.1 (0x00000000)
0x0044ab80: movl 0x4(%ecx),%edx

Of course, it's not a show-stopper if it only does
this on exit :)

Artist Formally Known as Dot wrote:

Regarding the crash on exit (Quit button) issue with COG-8.0, I've
gathered the following +seh trace -- we pick up the action, with me

having already started wa.exe and navigated into menus, and then
have clicked 'Exit' => 'Exit' => 'Quit' ..;

Well, we already found why it's crashing (because it's trying to notify the user that it can't save file, but crashes while attempting to do that). The crash is already fixed for the next Beta, and it'll show a standard MessageBox instead. The question is, why can't it save the team file (User\Teams\WG.WGT)?

Vladimir Panteleev wrote:

Vladimir Panteleev wrote:

3.6.29.0 exits silently after starting (not yet sure
why)

Disregard that, it works fine. I believe it was crashing because I
overwrote some files with older versions.

Regarding the crash-on-exit problem - does the directory User\Teams
exist and is it writable by W:A?

Ah...negative..there is a User directory, but no Teams directory there-under.

Artist Formally Known as Dot wrote:

Ah...negative..there is a User directory, but no Teams directory
there-under.

In that case, simply creating the directory should solve the problem.

Interestingly I didn't know that there were CD editions that would install without a default team file (and thus Teams subdirectory). If this is the case, new W:A versions should create the directory if it doesn't exist. Do you mind if I ask what is the publisher of your W:A CD?

Vladimir Panteleev wrote:

Artist Formally Known as Dot wrote:

Ah...negative..there is a User directory, but no Teams
directory there-under.

In that case, simply creating the directory should solve the
problem.

Interestingly I didn't know that there were CD editions that would
install without a default team file (and thus Teams subdirectory).
If this is the case, new W:A versions should create the directory if
it doesn't exist. Do you mind if I ask what is the publisher of your
W:A CD?

Confirming that manually creating the Teams directory solves that issue...

Lost way back in this thread somewhere, I did actually record;

"This is the same software house release as my copy of Worms World Party
--both discs are labeled as being from 'Big Bytes' software, and then
licensed to/by 'Red Ant Enterprises'"...I'm in .AU btw....

I was meaning to ask you about this actually...not that one would take
wikipedia entries as gospel, but the digging around I did wrt Red Ant
Enterprises would have me conclude they never sold any of the worms
titles at all...so maybe these disks in front of me are bootlegs as well?
Certainly the beta patch seems to apply correctly - do let me know.

Cheers!

Artist Formally Known as Dot wrote:

Lost way back in this thread somewhere, I did actually record;

"This is the same software house release as my copy of Worms World
Party
--both discs are labeled as being from 'Big Bytes' software, and
then
licensed to/by 'Red Ant Enterprises'"...I'm in .AU btw....

I was meaning to ask you about this actually...not that one would
take
wikipedia entries as gospel, but the digging around I did wrt Red
Ant
Enterprises would have me conclude they never sold any of the
worms
titles at all...so maybe these disks in front of me are bootlegs as
well?
Certainly the beta patch seems to apply correctly - do let me know.

Thanks, that's very interesting... Personally, this is actually the first I've heard of about Big Bytes or Red Ant Enterprises, but I'm fairly new with the game (maintainer since only 2006). I can ask someone from Team17 on Monday.