SirSpunky's Forum Posts

  • Holy crap! Construct 2's plugin system is amazing!

    I just spent 10 minutes fiddling with the default particles plugin, added 6 lines of sweet js code, and suddenly the particles follow their emitter.

    It should be easy to add it as an option to the GUI so that it can be set for each emitter.

    I'm also thinking of adding an event action to manually move all particles on screen, which would likely be a breeze as well.

    Ashley, would you consider adding this functionality to the official plugin if I make these modifications? I guess I'll start by making a custom copy of the particles plugin for my project, but then I would have to manually merge it with the official plugin when it gets updated.

  • You have to set "Force own texture" to "Yes" in the layer containing the special blend mode. I don't know why, but that's what they did in the examples.

  • Good idea! It worked almost perfect just placing all objects in a family and looping them each tick. Next to no performance loss. Thanks a lot for your help.

    System Every tick
        Local number PlayerX = 0
        Local number PlayerY = 0
        Set PlayerX to Player.X
        Set PlayerY to Player.Y
        Player: Set position to (0,0)
        Scroll to Player
        For each Objects
            Objects Set position to (Self.X-PlayerX, Self.Y-PlayerY)
    

    The only problem I have now is that this messes up particle effects. Individual particles cannot be targeted by actions, and they don't seem to follow their particle system after being released.

    Is there any way to make particles follow their emitter, so that if I move the emitter, already existing particles will be moved as well?

    My best idea at the moment is to constantly change the angle and speed of the particle system to counter the player movement, but not sure it will work.

  • Hi. Thanks for the detailed answer! I suspected it had something to do with precision.

    My use-case is more reasonable than the demo I attached above, as it was mainly an extreme example. In short, I'm trying to create a space game/simulator with massive distances in relation to scales. In practice, I won't get to the extreme distances shown in the demo, but enough to notice some minor stuttering.

    I'm thinking of ways to circumvent this limitation. Do you think it would help if I now and then move all active objects in the layout, including the player, to position 0,0? Thus, they would maintain their relative distances, but the "active zone" that includes the player and the player camera would never move too far off the center.

    Basically, what I mean is that when the player gets too far away, he's moved to position 0,0, but the world around him is moved as well.

  • I managed to fix the problems by editing rex_hash/runtime.js:

    Set value at current entry, support for "."

    1) Add at line 84 in function instanceProto._set_current_entey():

    this._current_key = key;

    2) Replacing method at line 219 to:

    Acts.prototype.SetValueInCurHashEntey = function (key_name, val)
    {
         key = key_name ? this._current_key + '.' + key_name : this._current_key;
              
         if (key != "")
         {
              var keys = key.split(".");             
              var last_key = keys.splice(keys.length-1, 1);      
              this._set_entry_byKeys(keys);
              this._current_entry[last_key] = val;
         }
    };
    

    I also needed support for this in the Entry() expression so I did a similar fix there:

    Exps.prototype.Entry = function (ret, key_name)
    {
         key = key_name ? this._current_key + '.' + key_name : this._current_key;
              
         if (key != "")
         {
              var keys = key.split(".");             
              var last_key = keys.splice(keys.length-1, 1);      
              this._set_entry_byKeys(keys);
              ret.set_any(this._current_entry[last_key]);
         }
    };

    Looping all keys

    I fixed the loop issue by commenting out the following at two places, line 158 and 174:

    if ((typeof value != "number") && (typeof value != "string"))
        continue;

    Not sure why it was there, but maybe it was a useful feature for some to only loop through numbers and strings?

    Finally, I did another change that was useful for me.

    Get item count, return 0 instead of -1 when not exists

    Changed at line 118 in function get_item_counts(), return (-1); to return 0;

    This was useful for me because I often add items by numeric index, like a unique id, and I use the item count to get a good index value. I wanted the first iteration to return 0 instead of -1, that's why I changed it. I can still use key exists if I need to test if the value exists.

  • Also, there seems to be a problem with "For each item in" when values are objects.

    I can do this:

    Set key "a" to 100

    Set key "b" to 200

    For each item in ""

    But not this:

    Set key "a.label" to 100

    Set key "b.label" to 200

    For each item in ""

    The latter does not loop any items, even though key a and b exist.

  • This is an awesome plugin! Thanks a lot. Just what I needed to start generating random worlds.

    One suggestion. It would be great if you could do:

    Set value at "position.x" to 1000 in current entry

    ...and get {"position": {"x": 1000}} instead of {"position.x": 1000}

    That way, it would work the same as:

    Set key "position.x" to 1000
  • Thanks for the plugin.

    You could replace line 120 with "newLabel.htmlFor = newRadioButton.id;" to make <label> work better. If the for-attribute is set to the <input> id you can also click on the label text to check/uncheck the radio/checkbox.

  • I updated the demo so you can use "x" to instantly set the position to very far away, bypassing the Custom Movement. Still strange distortions I'm afraid.

    It really does look like quantum mechanics...

  • Yes, same here. I first noticed it when moving at slower speeds but over large distances.

    I've tried with pixel rounding both on and off, and using scrollto behavior as well as custom "scroll to Player each tick". Haven't tried other movement types though.

    I could be missing something crucial, but just can't figure out what. It seems to be able to store and display the large numbers fine, so I can't help but believe it should be able to render them as well.

    Could it have something to do with floats? I've heard that float variable types can be unreliable in certain circumstances. Could this be one of those?

  • Link to .capx file (required!):

    dl.dropboxusercontent.com/u/2425456/large_distance_problem.capx

    Steps to reproduce:

    1. Press and hold "W" to accelerate Player very fast using a basic Custom Movement.

    Observed result:

    When approaching large distances, the sprite and/or camera starts to gradually jerk more and more.

    Chrome and Firefox also exhibits rendering issues when rotating the ship at large distances (try stop moving by pressing "b" after reaching a large distance, and then turn the ship around). For some reason, this turning glitch does not happen in IE10, although it has the same problem when moving.

    Expected result:

    The same smooth movement as seen at lower positions.

    Browsers affected:

    Chrome: yes

    Firefox: yes

    Internet Explorer: yes

    Operating system & service pack:

    Windows 8 Pro 64-bit

    Construct 2 version:

    Release 139 (64-bit)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Here's a working script:

    imgur.com/Q5pbMnY

    Remove the key conditions if you don't also want scrolling with wasd-keys.

    ScrollRate is how fast the screen scrolls in pixels each tick.

    MouseScrollArea is how large the trigger areas are at the sides.

    The advantage of this solution is that it's easy to copy-and-paste between projects and supports diagonal scrolling.