alright, now it crashes when i win. it just says the same as before, but i cant find the logs

Do you mean winning as in conquering a single base or as in occupying the whole map?

The winning (or losing) by having all the areas occupied under one of the nations is currently a little bit unfinished situation, I wouldn't be surprised to find issues around there, but I'm working on it

Nevertheless, you can find the log under rwr-subfolder, there should be a file rwr_game.log.

Yeah, the same happens to me. Conquering the last standing goodies base (Airport in this game) crashes the game. Can't post the logs yet, I'm not posting from the same computer RwR is installed on.

Just spotted a division by zero bug when all bases became occupied by one nation, fixed it for the next release.

Same happened to me, twice in fact.
I picked the part of the log which looked like it was relevant, though if you need all of it, tell me, i have it all copied in another file

13:08:26: D3D9 device: 0x[00179080] lost. Releasing D3D9 texture: Ogre/ShadowTexture0
13:08:26: Released D3D9 texture: Ogre/ShadowTexture0
13:08:26: D3D9 Device 0x[00179080] entered lost state
13:08:27: !!! Direct3D Device successfully restored.
13:08:27: D3D9 device: 0x[00179080] was reset
13:08:28: Texture: menusystem_control_selected_background.png: Loading 1 faces(PF_A8R8G8B8,32x32x1) with hardware generated mipmaps from Image. Internal format is PF_A8R8G8B8,32x32x1.
13:08:32: Texture: grenade_crate_side.png: Loading 1 faces(PF_A8R8G8B8,256x256x1) with hardware generated mipmaps from Image. Internal format is PF_A8R8G8B8,256x256x1.
13:08:32: Texture: grenade_crate_top.png: Loading 1 faces(PF_A8R8G8B8,256x256x1) with hardware generated mipmaps from Image. Internal format is PF_A8R8G8B8,256x256x1.
13:08:35: Texture: mapview_baddies.png: Loading 1 faces(PF_A8R8G8B8,32x32x1) with hardware generated mipmaps from Image. Internal format is PF_A8R8G8B8,32x32x1.
13:08:35: Texture: mapview_battle.png: Loading 1 faces(PF_A8R8G8B8,32x32x1) with hardware generated mipmaps from Image. Internal format is PF_A8R8G8B8,32x32x1.
13:10:01: Texture: crosshair_good.png: Loading 1 faces(PF_A8R8G8B8,32x32x1) with hardware generated mipmaps from Image. Internal format is PF_A8R8G8B8,32x32x1.
13:21:04: Texture: sandbag.png: Loading 1 faces(PF_A8R8G8B8,64x64x1) with 0 generated mipmaps from Image. Internal format is PF_A8R8G8B8,64x64x1.
13:21:04: Texture: sandbagtop.png: Loading 1 faces(PF_A8R8G8B8,64x32x1) with 0 generated mipmaps from Image. Internal format is PF_A8R8G8B8,64x32x1.

_________________
Look behind you. What I'm not there? I see... then look forward. Still not there? ...On the sides? Up and down? ...Where the heck am I? ... Oh wait! Yeah! I'm the one that's trying to find me ._. That's rather silly isn't it?

Assuming the division by zero bug is something that used to happen in 0.2 as well, logs won't help much there. It's an implementation flaw and there's no check for the case to print something usable in the log. The crash should happen every time you win or lose and the commander AIs gets updated (it gets updated every 5 seconds or so), so, if there are cases that you don't see the crash, then I'm worried

Unless there are more bugs around there, it's fixed in 0.3. I tested the win situation multiple times with the fix and couldn't get crashes to show up. I didn't play the whole "match" from start to victory, so there's still a theoretical possibility that there's still something else, instead I artificially created the near-win situation to simulate playing the whole "match" and fought my way to the end, and it worked each time.

On a side note, I also improved the final battle so that in case of the last base, you need to clear the base and its surrounding blocks completely until the base gets declared to be occupied by your nation, so you won't get the victory signal too soon anymore in 0.3.

ok here what happend when i tried to load an autosave

generated mipmaps from Image. Internal format is PF_A8R8G8B8,32x32x1.
15:07:32: : CHECK: virtualize character failed
15:07:32: : aabb=AxisAlignedBox(min=Vector3(227.556, -10000, 568.889), max=Vector3(284.444, 10000, 625.778)) vcposition=Vector3(284.463, 0, 585.454) block=5237208 vc=273787320
15:07:40: DefaultWorkQueue('Root') shutting down on thread 00721348.
15:07:40: DefaultWorkQueue('Root')::WorkerFunc - thread 00730EC0 stopped.
15:07:40: DefaultWorkQueue('Root')::WorkerFunc - thread 00730EF0 stopped.
15:07:42: *-*-* OGRE Shutdown
15:07:42: Unregistering ResourceManager for type Compositor
15:07:42: Unregistering ResourceManager for type Font
15:07:42: Unregistering ResourceManager for type Skeleton
15:07:42: Unregistering ResourceManager for type Mesh
15:07:42: Unregistering ResourceManager for type HighLevelGpuProgram
15:07:42: Uninstalling plugin: ParticleFX
15:07:42: Plugin successfully uninstalled
15:07:42: Unloading library Plugin_ParticleFX
15:07:42: Uninstalling plugin: Octree & Terrain Scene Manager
15:07:42: Plugin successfully uninstalled
15:07:42: Unloading library Plugin_OctreeSceneManager
15:07:42: Uninstalling plugin: Cg Program Manager
15:07:42: Plugin successfully uninstalled
15:07:42: Unloading library Plugin_CgProgramManager
15:07:42: Uninstalling plugin: D3D9 RenderSystem
15:07:42: D3D9 : Shutting down cleanly.
15:07:42: Unregistering ResourceManager for type Texture
15:07:42: Unregistering ResourceManager for type GpuProgram
15:07:42: D3D9 : Direct3D9 Rendering Subsystem destroyed.
15:07:42: Plugin successfully uninstalled
15:07:42: Unloading library RenderSystem_Direct3D9
15:07:42: Unregistering ResourceManager for type Material

This is different from the winning crash I'm sure.

Can you reproduce it every time by loading the same save game? If so, please send the savegame file to me at pasi.kainiemi@modulaatio.com if you still have it, that would be really helpful.

now i reloaded and its ok

Continuing the off topic about the virtualize character crash, actually, I found something that fits your case with loading the game and getting this crash, and especially if it doesn't happen every time loading the same game. The game reset, that happens before loading the saved game, can actually trigger the virtualize crash if the ongoing game has the situation that a soldier would need to be virtualized on the very next frame.

I'm pretty confident that it's this case. The issue should be visible only when loading or starting a new game, and only if you happen to input the start signal on such frame that matches the aforementioned situation, so it's pretty hard to reproduce. I've got this case handled for the next release now, keeping my fingers crossed that it's the last of it.