immortalx's Forum Posts

  • 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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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.

  • OK it seems I found something:

    Firstly, It seems that if the collision poly is set to bounding box, the first point is bottom-left and the rest are in a clockwise fashion.

    With the following code I was able to calculate the new collision poly:

    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.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)

    Now the problem is that it's not instantly updated. It's only when you perform a scale or rotation operation that it "snaps" into its proper position.

    Updated plugin and CAPX:

    https://dl.dropboxusercontent.com/u/14855413/c2/originatruntime2/sprite.rar

    https://dl.dropboxusercontent.com/u/14855413/c2/originatruntime2/hotspot1.capx

    If you try it out, first enter some new values for x,y origin and then use right click to rotate and middle click to scale.

    Please if someone can share his thoughts or can find why the poly is updated only after a rotation/scale operation I would really appreciate it.

  • R0J0hound

    I will try to figure out what those values mean. I already called update_bbox() and set_bbox_changed(), it's just the collision poly points that don't get updated and I suppose I'll have to find a way to shift them manually.

    Once more thank you for your time!

  • R0J0hound thank you very much!

    I took a look at this excellent plugin and if I understand right, the setOrigin action offsets the polygon vertices?

    What I'm aiming for is exactly how the Construct 2 editor works: When you change the origin of a sprite inside the editor, the origin stays at the current x and y and it's just the texture that "jumps" to an offset position. In the polygon plugin that doesn't seem to be the case.

    However, I found a line of code inside the plugin that seems to do what I want but i can't figure out what values to pass:

    this.collision_poly = new cr.CollisionPoly(new Array(0,0,0,0,0,0,0,0));

    It seems these are pairs of x,y values for each point in the collision poly, starting from top-left and going in a clockwise fashion? I can't understand if these are local or world coordinates.

    Thanks in advance.