zenox98 & Ashley thanks guys!

Problem Description

Using the NWjs plugin, the "Show folder dialog" action triggers the "Show open dialog"

Attach a Capx

https://dl.dropboxusercontent.com/u/14855413/c2/nwjsfolder.capx

Description of Capx

A single button that is supposed to open the "Show folder dialog"

Steps to Reproduce Bug

Click the button to show the folder select dialog

Observed Result

The open file dialog opens

Expected Result

I expect to have the "Show folder dialog" shown instead of "Open file dialog"

Affected Browsers

NW.js

Operating System and Service Pack

Windows 10 64bit

Construct 2 Version ID

R218 with NWjs 0.13.0 alpha 6

EDIT: Following Ashley's advice, I tried with NW.js alpha 7. Result is still the same

I was definitely sure there was going to be a holiday sale so this morning I purchased mine

What a wonderful example, thank you very very much R0J0!

R0J0hound you're right. It won't update unless a rotation or scaling is performed, so I will use your solution as a workaround!

Ashley thank you very much for taking the time to reply! I perfectly understand that changing the origin at runtime can break many things. The thing is that I'm doing an application, not a game, and I only really need the collision box to register mouse clicks and for the drag & drop behaviour. It's a simplistic keyframe animation app in which changing the origin is a needed feature. I currently handle this with invisible sprites to perform rotations and do linear interpolations between keyframes.

But I have just added a feature to assign parent-child relationships to sprites (to make it easier to animate) and i get very strange values in the interpolated frames. I suspect that is because of the "fake" origin points I'm using and that's why I'm seeking a way to implement "proper" origin points.

Thanks again for your help man! Although I know he's extremely busy I will tag Ashley and maybe he can shed some light when he has time!

BTW in common_prelude I see tons of stuff about points cache and I'm thinking It might have to do something with updating the poly.

I'm kinda late to the party but better late than never

I'm John, 41 years old with wife and 2 children. I got my first computer, a ZX Spectrum +2 sometime in 1986-87 and was instantly hooked to playing games, learning the BASIC language and briefly some Z80 assembly. Those were really the best days in computing and I can still remember the fights we had with Amstrad and Commodore owners! Later on I acquired an Amiga 500 and a bit later an Amiga 1200 and discovered the amazing AMOS BASIC. I refused to let those Amigas go, even after the dull grey boxes (that we used to call PC compatibles) started gaining ground. But I had to move on and eventually entered the distorted world of Windows 95... There I discovered click and create and the games factory and was amazed with what you could do with a couple of mouse clicks! And here I'm now using Construct 2 which I believe will be the future model of how games and applications are created and it's really the most polished and easiest game engine today!

In all those years, I never took it seriously to create a full game or really learn a programming language, but I guess it's never too late!

Up until recently, my main hobby was building hand-crafted electric guitars, but I kinda abandoned it because it started to become an expensive hobby.

Ruskul your thoughts are very useful to me and thanks for taking the time to respond!

I tried to change the angle to self.angle right after changing the origin, but construct is smart enough to NOT trigger an update to the collision box! It does exactly as you said, no unnecessary calculations without a reason because the engine understands there wasn't a real change in angle.

I also took a look at commonace.js but I couldn't find how the collision poly is moved after rotate/scale. All those actions just call this.set_bbox_changed();

I reported this a couple of days ago: https://www.scirra.com/forum/possible-minor-forum-bug_t164480

It was somebody else's post that showed as the last post of that section, but when you clicked on it it didn't exist.

Now mock ups like these from Animmaniac make me drool! Even the color scheme is perfect!

Ruskul , sure man and thanks in advance!

edittime:

AddNumberParam("HotspotX", "Set the sprite's HotspotX", "1");
AddAction(12, 0, "Set HotspotX", "Size & Position", "Set hotspotX to <i>{0}</i>", "Set the sprite's HotspotX", "SetHotspotX");

AddNumberParam("HotspotY", "Set the sprite's HotspotY", "1");
AddAction(13, 0, "Set HotspotY", "Size & Position", "Set hotspotY to <i>{0}</i>", "Set the sprite's HotspotY", "SetHotspotY");

[/code:w2hpv2km]

runtime:
[code:w2hpv2km]    Acts.prototype.SetHotspotX = function (hx)
    {
        this.hotspotX=hx/this.width;
        this.type.animations[0].frames[0].poly_pts[0]= -hx/this.width
        this.type.animations[0].frames[0].poly_pts[2]= -hx/this.width
        this.type.animations[0].frames[0].poly_pts[4]= 1-(hx/this.width)
        this.type.animations[0].frames[0].poly_pts[6]= 1-(hx/this.width)
        this.set_bbox_changed();
        log("points = "+this.type.animations[0].frames[0].poly_pts );
        
    };

    Acts.prototype.SetHotspotY = function (hy)
    {
        this.hotspotY=hy/this.height;
        this.type.animations[0].frames[0].poly_pts[1]= 1-(hy/this.height)
        this.type.animations[0].frames[0].poly_pts[3]= -hy/this.height
        this.type.animations[0].frames[0].poly_pts[5]= -hy/this.height
        this.type.animations[0].frames[0].poly_pts[7]= 1-(hy/this.height)
        this.set_bbox_changed();
        log("points = "+this.type.animations[0].frames[0].poly_pts );
        
	};[/code:w2hpv2km]

The current system is almost perfect but the ideas proposed in this thread are certainly interesting.

What I'd like to see improved in the event editor is things like:

Having the ability to pick a specific instance in conditions, just like how Sprite(IID).property works. I know you can do that with Compare two values, but it would be more convenient to do the picking and condition in one step. Maybe an optional text field in every condition to pick an instance, or if left blank doesn't do any picking.

The same thing as above could be added to actions. I'm sure there are several cases where one wants to test a state of an instance of an object and then do an action on another instance of an object. There are of course ways to do this currently, but IMHO that would help reduce the lines of code.

Some slight improvements in copying pasting events and most important of all (in my opinion) when you delete an object in the layout, do not remove the code that references that object! Something like how an "Else(not valid here)" that turns red and gets disabled would be better I believe. The same thing could apply when you delete variables and families.