[r163] Container not used in Set Position to Object

0 favourites
  • 3 posts
From the Asset Store
Hand-painted tiles, objects, animated objects, and background to build a colorful Mayan civilization environment.
  • Problem Description

    The container isn't checked when using the Set position to object action.

    The problem is expected because in acts.SetPosToObject in commonace.js, no container is ever checked.

    Also the problem needs a specific situation to really be noticeable.

    Because in most cases the SOL filtering and the auto pairing (by IID) kind of mask the issue.

    Here is my fix proposition:

    			acts.SetPosToObject = function (obj, imgpt)
    			{
                    var inst;
    				
                    if(this.is_contained && obj.is_contained) {
                        for(var i = 0; i < this.siblings.length; i++){
                            var sibling = this.siblings[i];
                            if (sibling.type === obj) {
                                inst = sibling;
                                break;
                            }
                        }
                    } else {
                        inst = obj.getPairedInstance(this);
                    }
    
    				if (!inst)
    					return;
    [/code:2banhj7z]
    
    [url=https://app.box.com/s/e4bei0aoj8neqkbxabp3]setPositionToObject%26container.capx[/url]
        
    [b]Description of Capx[/b]
    When you click on the bluegray square its boolean "clicked" is set to true
    If "clicked" is true for any bluegray square, the associated orange square should be positionned to the corresponding bluegray square
    
    [b]Steps to Reproduce Bug[/b]
    [ul]
        [li] click on the bluegray squares in any order[/li][/ul]
        
    [b]Observed Result[/b]
    Various unexpected positionning
        
    [b]Expected Result[/b]
    Each orange square should go to its corresponding bluegray square because of the container pairing
        
    [b]Affected Browsers[/b]
    [ul]
        [li] Chrome: (YES)
        [/li][li] FireFox: (YES)
        [/li][li] Internet Explorer: (YES)[/li][/ul]
        
    [b]Operating System and Service Pack[/b]
    Win7  SP1
        
    [b]Construct 2 Version ID[/b]
    r163
  • Closing as won't fix. It's true the getPairedInstance() call does not match up the correct instances in this case. However it's to do with the fact the action takes an object parameter instead of relying on the normal event engine pairing. If you use either the ordinary 'Set position' and pass Sprite.X, Sprite.Y, the pairing works; alternatively just add 'For each Sprite' above the clicked condition. We won't add that workaround code because it would need to be applied to any action using an object parameter, and applying it to just one action would introduce an inconsistency in the engine.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Ashley

    Oh ok, got it, I'd actually never noticed that object parameters weren't "container-aware" (:

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)