And now to answer my own question!

If I do:

pick by sprIvoRobotnik [Platform].VectorX>0
 sprIvoRobotnik: set angle to 180
 else
  sprIvoRobotnik: set angle to 0[/code:28gf87w5]
Movement works as expected using this.

That said, I'm clearly (not) doing something else I should be, because once movement ends the sprite returns to the default angle. Ideas?

Ah.

I was remembering the answers I got in this thread, and thought (perhaps naively) that that would apply across different behaviour types.

+If Guy[Platform].VectorX is greater than 0, Set Guy.Angle to 0
|
+Else, Set Guy.Angle to 180[/code:1tdsp9ft]

Pardon the excessive noobiness here, but erm... which condition(s) would allow me to do that? I'm probably staring it in the face but have no idea which one it might be...

When running the original test through the debugger, the angle it says the sprite is when moving to the left is 0 - it isn't using the 180 degree rotation for the sprite.

Help?

This is weird. Starting from scratch. Recreated the test sprite with the same two frame animation. Auto flip doesn't work, defining angles for 0 and 180 doesn't work either. Any ideas as to what's up?

I'm aware that XML is planned to be used for exportable/separate event sheets, but (and this is a big but, I know!):

How about Python - i.e., the events themselves are in Python behind the scenes?

Also, how about being able to use Python to write extensions?

I'm aware these probably won't be considered for the 1.x releases, but in the future it might be of use.

As per - see attachment there:

I've also hit on something that looks like a bug. In the lyoGlobalObjects view, clicking on "sprIvoRobotnik" in the objects list shows the sprTestBrick's animation lists. In fact, the other sprite does as well. Clicking on the sprite in the layout window does show the correct animation list as expected, though.

Right, I've got a test sprite set for platform style movement with a single two frame animation, facing in two angles, 0 and 180. However, when I run the test, the animation isn't turning around. I suspect I've omitted something very simple, but I'm not sure what.

Interestingly enough, auto mirror doesn't flip it around either. This does lend some suspicion this might be a bug of some kind. This is, by the way, originally a Construct 0.98.3 file upgraded to .5, if that helps at all.

Suggestions?

Except they already know about two of them, judging by the "fixme"s.

Doesn't mean that I won't submit bugs though - I couldn't find Construct on Wine's application database, so it looks like nobody there either knows of it existing.

The video hardware tool doesn't work either.

David: I can't get the menu to respond. It appears but I can't click on anything. Keyboard shortcuts appear to work though. The bottom half of the layout window acts like a black hole. The context menu also does not respond to mouse clicks. Interestingly, it does respond if you use the cursor keys. However, positioning doesn't work.

It comes up with a lot of:

fixme:d3d:IWineD3DSwapChainImpl_Present Unhandled present rects (0,0)-(1142,792)/(null)[/code:2ti47djl] and [code:2ti47djl]fixme:d3d:WineD3D_ChoosePixelFormat Add OpenGL context recreation support to SetDepthStencilSurface[/code:2ti47djl] and [code:2ti47djl]err:listview:LISTVIEW_WindowProc unknown msg 1091 wp=ffffffff lp=0032c050[/code:2ti47djl] so it's apparent there are known shortcomings with this.

0.98.4 is still broken (WINE 1.1.2; 1.0.1 gives a "Call from 0x7b845450 to unimplemented function dwmapi.dll.DwmFlush, aborting" error).

I followed stainsor's advice in . On startup, it reports that "Error loading C:\Develop\Construct\Plugins\ID3.csx (126) - this plugin may not be available!" and "Error loading C:\Develop\Construct\Plugins\Registry.csx (126) - this plugin may not be available!". These two initial errors can be fixed by copying MFC42.DLL into WINE's windows/system32 directory.

Loading up a test .cap either fails when trying to run it via Construct with a "Cannot find XAudio2.csx" error, or crashes out due to what looks like problems with OpenGL's SetDepthStencilSurface function...

A small update:

Construct sort-of works with WINE 1.1.12. The File menu is non-responsive and it seems to crash loading (at least) a test CAP I made the other day (with the physical machine XP), but it got somewhere more than with the other version.

Games made with Construct appear to work though. No sound under WINE 1.0.1, but they do have sound with 1.1.2.

Gotcha. Sound version still crashes, though.