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;

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;
     }
};

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]);
     }
};

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

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

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)

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.