Inverse of isvisble added to your conditions works great when using nonvisible layers and mouse on object clicked. Yes, it's one extra check, but it's a lot less work than trying to save the state of your game and switching to another layout.

Are you sure one would even need to save the state of a game?

Couldn't one simply use global objects (arrays, variables, etc)?

Either way, I think I'll need to scrap the idea of using layers. It would be way too messy and complicated for my editor suite.

For one, I want to set up V as a hotkey within the scene editor. While pressed down, this hotkey would remove (in terms of visiblity, not game logic) all buttons and only show the test character and the background scene (sans the blue lines seperating the walkable area from the one that is not).

I'd essentially need to split the layers at this point, which isn't that great either

Would someone know how to change the styling/colour of a single drop-down list index?

My drop-down list currently consists of the following items:

File

----

SAVE

LOAD

QUIT

Naturally, I want to make it clear that FILE isn't an option but the actual headline of that particular menu bar, hence I'd like to make it either bold or choose a different colour for it.

All I know is that I'd need to pick an instance (index 0) before assinging the CSS style to it (otherwise, it would just assign the style to the whole dropdown list), but how do I that within Construct 2?

I don't see how it would be possible.

CC is based on DX, whereas Construct 2 uses WebGL.

I haven't used CC before, but if it uses HLSL for those shaders it might be possible to port them over (either manually or by using a toolsuite such as Mojoshader).

Not to sound patronising or anything, but banning a paying customer is kind of immoral (IMHO).

Developing a proper UI with several tabs, what does everyone think would be the more elegant/functional approach?

a. Hide and unhide layers, depending on what tab the user is trying to access.

b. Adding several layouts and switching between them through the use of buttons

b) would probably make it easier to browse through the code blocks or export only the parts of the application to JSON that the user chose, but a) does come with benefits as well (such as not having to duplicate the basic layout and thus saving on a few events).

Same here.

Tested on Firefox, Chrome and IE.

Seems like it not only tries to mirror the sprite but also the pathing (it looks like it's constantly pushing to the left while, at the same time, trying to move to the right, and vice versa).

Ok. Finally figured out some basic movement.

It's still a wee bit flawed, so I'm thankful for any pointers on the math (fixing it mathematically would probably be the elegant solution)or whether I should, perhaps, add another condition dealing with area left and right of the character.

docs.google.com/file/d/0B4HbmIw0kk7FWWktWnowUVJCbkU/edit

EDIT: I could, of course, simply add a hidden sprite and calculate the animation based on angle. I'm not sure, however, if this would be a more proper approach or not. It would certainly add more overhead, which I'd prefer to avoid.

The game I want to develop with it will use pre-rendered 3D characters, so I'll definitely need more directions than those four already in place.

I strongly disagree.

HTML5 is definitely the future. It's not only much more portable than NME/Haxe will ever be*, it also evolves much faster.

It took years until NME/Haxe finally secured a half decent 3D API and that one is pretty much outdated now (the new, integrated OpenGL ES API just isn't there yet). HTML5 got there a tad faster, with WebGL to OpenGL ES wrappers and proof of concepts already floating around the net.

Lastly, I don't see the point of transferring to NME/Haxe.

If there are already multiple easy to use tools in the vain of Construct2, then why even bother? Construct 2 is pretty much known to be the most afforadable, easy to use HTML5 framework. If it made the switch to NME/Haxe, it would be "just another construction kit". They could, perhaps, avoid this by implementing most of NME 3.5.5's HTML5 capabilities. But then again, why even bother?

PS: Would you mind naming one of these "rivals" utilizing Haxe? I'm still a bit frustrated over the HTML5 incompatibilities within WebOS, so NME/Haxe might be the road I'm taking for that particular OS.

*And that's coming from someone who was a proponent of an all-native approach, despising even .Net, before eventually having to recognize the power of a more portable approach (all thanks to HTML5).

With the release of Construct2 r117 and it's grand, new pathfinding algorithm, I thought it was about time to commence work on a point and click adventure engine.

So far, so good. A few hours later, I've already written up a few white papers and am in the process of drawing up the UI (I've decided to go with a non-native look for this one. In the end, it should look quite different from standard wxwidget/QT apps).

Here's where I could need some help with, though:

1. The "menu bar" will consist of several list boxes. I'd like to mark the first entry (the one that's there whenever the program is launched) with bold. Is there any way I can do that in Construct2 (using CSS)?

2. Any suggestion on how to accuratly implement animation changes? Say, when the character walks to the back of the screen and thus isn't facing the "camera" anymore? The way it's currently implemented (compare sprite position to mouse.Y and switch animations accordingly) isn't exactly usable.

3. My goal is to have a toolkit which, in the end, won't rely on Construct2 for anything but re-packing the interpreter module. For this to fully work, I'll obviously need a scene editor that keeps track of the pathing itself (some sort of hidden polygons that seperate the walkable areas from the ones that are restricted). Any suggestion how I could generate some sort of variable polygon structure on the fly, which will then behave like some sort of solid or custom obstacle for the pathfinding behaviour?

4. Any opinions on using Javascript (via CallJS) as internal scripting language? My major fear is that a) it's too hackish b) it might lack certain features/syntax that are a standard with scripting languages like LUA or AGS Script.

Here's the .capx, for anyone who's interested:

docs.google.com/file/d/0B4HbmIw0kk7FMHh5SC03NlZJYVU/edit

Just came back here to point out you guys were correct.

When I finally replaced the standard Microsoft provided WDDM driver with an ATI one, the issue vanished immediately.

Wish I had done this earlier. Contrary to what I remembered, porting the display driver to Windows 7 x64 (AMD/ATI dropped the driver support for my laptop's GPU even before Vista SP1, unfortunately) was a breeze and took less than an hour.

—

WebGL doesn't necessarily require device support.

I was similarly frustrated until I found out that someone already wrote a wrapper (translates WebGL to OpenGL ES, basically) for my mobile OS of choice (WebOS).

Not sure how this would work with Android or iOS though, since neither builds on HTML5, but Blackberry 10 should be a breeze.

Thanks guys. Well appreciated.

The worst is yet to come, I fear.

My other ferret is going crazy right now. She isn't eating and is on a constant search for her sister.

If this goes on, I fear I'll lose her as well.