When an entity server starts up, grabs the version of the models.json
file locally, and then queries the domain server for its copy of the
models.json file...iff the domain server version is newer.
There was a bug in this process in that the comparison was made between
the wrong version, specifically the 'file format version' which doesn't
change unless there was a protocol change...and not the data version,
which increments every time a change is made to a domain.
Therefore, the version of the models.json on the domain server was never
downloaded to the entity server, even when it was newer.
It would be newer if the entity server assignment was moved to a machine
with an old version of the models.json file, which was in fact the case
on distributed3 during this period of time.
Local entities are collisionless, so they shouldn't affect Safe Landing since it specifies that it only wants
to find COLLIDABLE entities. However, due to the requirement to support legacy behavior, picks for COLLIDABLE
entities *do* intersect Local entities. In order to prevent this, we have to explicitly request only intersections
with Domain or Avatar entities.
For more information about this, see this Pull Request:
https://github.com/highfidelity/hifi/pull/15282
These two things need to happen in the following order:
1. Initialize the input plugins (including the keyboard)
2. Start the scripts
That's because the scripts try to use the keyboard (e.g., in edit.js), and if it's not ready yet
then they fail, and then Interface doesn't work right (e.g., the Create button doesn't work).
In order to ensure that these things happen in the correct order, we must make sure that
resumeAfterLoginDialogActionTaken() (which starts the scripts) is called only after everything
else in the Interface constructor has finished. Usually this happens correctly, but occasionally
resumeAfterLoginDialogActionTaken() is called too soon. This commit makes sure that even in that
case, we'll postpone calling resumeAfterLoginDialogActionTaken() until the Interface constructor
has finished.
Previously, attempts to login using an email such as "my+name@example.com" didn't work because the username wasn't
URL-encoded when it was sent to the server, so on the server the '+' was changed to a space.
When Interface starts, it first calls pauseUntilLoginDetermined(), and later resumeAfterLoginDialogActionTaken().
But on rare occasions these functions are called in the reverse order, and this caused Interface to remain
in the "paused" state. Now we check for this case, and abort pauseUntilLoginDetermined() if it happens.
This has only happened to me when running Interface immediately after rebuilding it (in Release mode).
The Application constructor must setup event handlers for events emitted when the Desktop is
constructed *before* calling initializeUi(). Otherwise, sometimes these event handlers won't
be called.
When this problem happened (usually on slow machines), Interface would start but neither the
Desktop nor the Login Screen would appear.
Previously, rays *always* intersected with Local entities, regardless of whether the pick filter requested
to hit on collidable or noncollidable entities. But Local entities are always collisionless, so a pick filter
for collidable entities shouldn't intersect with Local entities.
