-confirmed-

-validated-

ok .. i merge it to T894 then ..seems to be the same or closely related to each other

1. Yes
2. Yes
3. Yes

-Validated-
-Confirmed-
nothing to add

Collision is a delayed feature and expected to be not working properly right now

Most likely the effect from T894 and or T834 .. and even those 2 maybe the same.

probably a routing thing caused by the phones internet connection or restrictions applied by the ISP for said phone

-validated-
depending on rotation and orientation to the universe the avatar spawns in a wrong place after leaving the core.

Additional, I noticed something else by my turrets, the ones who disappear and appear sometime somewhere, not every one that are build in the shipyard, they are even not working with the ai module...may it help you with testing

That might be a separate issue alltogether.

optimization causing this removed from latest build

-confirmed-

Why are ships build in the shipyard then disappearing (or just the visualisation is a distance away) that doesn't fit in your theorie of entities will not dissapear until moving/turning them

This is a single straight rail that has an entity moving on it. This is unrelated to the transfer entity to another entity via rails experiment I was playing with except that I initially tried to make two parallel rails, undock one that was moving and I was attempting to have it somehow collide with another rail. Ignoring the collision thing, this is about undocking moving entities on a rail.

I have an activation block touching the rail block, I connect that activation block to a button that is away from the rail. The button is then linked to the rail to send the activation. When an entity is moving on the rail and it triggers the activation, it then triggers the button which activates the rail to undock the entity. It does not undock. I tried linking it to the rail that it is coming from and the rail it's going to. Neither worked.

I have a theory that this has to do with the rotation of the turrets when they're created at the shipyard. I need to do more testing though, but so far it seems that if a turret isn't moved in any way, the shipyard doesn't mess it up.

I just had a turret (base + barrel) displaced by about half a sector after relogging. (v 0.19519)
The base was made via "Create Docking" (unlike the barrel).

happens exactly as described in the report but also with Damage Pulse.
How to reproduce: testing different weapon systems against docked entities: Missiles and Damage Pulse will break blocks while the shields of the motherships are above 25%

Perhaps they dont need to touch? When the "Distance to re-dock" code is implemented, a much lower ranged one could be used to snap rail dockers onto rails when they are 1-2 blocks away. That is unless the code for distance stems from the entity itself, and not where the dockers are placed

-QA Testing-

Alright, but let's put it in the delayed column instead of getting rid of the issue entirely

cant see any massage (tested with microassembler here. and it produces .. which it shouldnt

Fixed in 1952

not fixed in 0.1952

I am assuming it was due to a corrupt blueprint file, as 10 days have gone by without feedback response. And I have been unable to replicate.

will have to wait a bit. flat surfaces can't produce a contact point. brute force testing close ones would be a performance hell

-Confirmed-

I can't reproduce this, are you sure that logic block isn't touching a rail block? If so, then it will try to set that rotation to the linked block, instead of undocking the entity.

-QA Testing-
Not fixed, still occurring in v0.19519. Behaviour did not change.

I fail to reproduce on ubuntu linux 12.04 using openJDK7. (both v0.19498 and v0.19519)
The issue may be bound to the specific JVM, so knowing which java is being used would help.
If logfiles from the crash could be provided it may also help determining the source.