Page MenuHomeSchine - Phabricator

Starmade | Rail detection with rotators and set rotation broken
Confirmed task for development, HighPublic

Description

  • I submitted this bug a week ago and all traces of it apart from a mail notif are gone so reposting -

I haven't been able to find this bug anywhere in here.

Activation modules adjacent to a customised rail rotator will no longer trigger when an entity moves over it.
By customised I mean having designated activation modules for 45 degree turns etc.

Detection still works with basic 90 degree rotators.

Earlier builds had them detect the same way as rails. I guess the new wireless detection is conflicting with it.

Details

Commits
Restricted Diffusion Commit
Task Type
Bug
Testing Results
Affected Gamemode(s)
Single and Multi
Reproducible
Yes
Last tested (version)
0.199.485
Category
Control Block System: Rails/Docking
First occurrence (version)
0.199.253
Hardware/Software/System
OS-Specific
No
Hardware-Specific
No
Video Card Vendor
uncertain
User/Reporter/Contact
Username on Registry
Caumen
Username/Profile on Steam
Caumen
Steps to reproduce

testsetup is something like this
line of activators c-v connected to rotator to setup rotation angle
single block c-v connected to detect movement onto rotator


Tester information (Internal use only)

If something moves on a rail block, it sets any nearby signal to true.
If it moves away (or undocks), it sets any nearby signal to false.

This change made the rotator block an exception to that rule. It sets any nearby signal to true after it's done with the rotation cycle. That doesn't work well since after the rotation cycle it also tries to move it away to the next block.

What it should do:

  1. Send a true signal to nearby blocks when a rail entity moves on the rotator at the start of every rotation (even if the rotation is 0 degrees/disabled)
  2. Send a false signal to nearby blocks when a rail entity moves away from the rotator to another rail, this would happen at the end of a rotation cycle (unless it's 0 degrees again)

Even with this fix, 2. doesn't work at all. It doesn't get set to false either by moving it away, or by undocking.

Serverconfig (server.cfg)
<replace this line with the file content>
Clientconfig (settings.cfg)
<replace this line with the file content>

Event Timeline

SmilingDemon shifted this object from the S1 Public space to the S3 Starmade space.Dec 16 2016, 4:17 PM
SmilingDemon changed the visibility from "Custom Policy" to "Public (No Login Required)".
SmilingDemon changed the edit policy from "Task Author" to "Starmade (Project)".
SmilingDemon triaged this task as Normal priority.

-Feedback-
We had a database rollback on the pharicator last weekend .. probably the report was a victim of that.

You are talking about this ?



button next to rotator gets triggered when the docker moves on the rotator and if the button is next to the rotator it will be triggered on the end of the rotation too.

(the move onto triggering causes a problem however which has to be removed for sure )

caumencaumen added a comment.EditedDec 17 2016, 3:09 AM

It seems to be more of a problem if you move the entity away from the rotator afterward, I've made a few gfy's

  • Link No modules added to the rotator and it stops on rotator.
  • Link Modules added to the rotator and stops on rotator (like you also noticed, it does not trigger until after it has rotated and is at a full stop.
  • Link No modules added to rotator and does not stop on rotator. This is how it used to work even with modules added to the rotator.
  • Link 2 Modules added and one off, it triggers the off module on the side meant to stay off and no longer triggers the module beside the rotator. It also goes a full 90 degrees rather than the 45 degress specified.
  • Link 2 Modules added and both on, same as above.

I've found that the amount of modules added to the rotator doesn't change the behavior as long as there is 1 or more activation modules connected to it on the side.

SmilingDemon edited Tester information (Internal use only). (Show Details)Dec 17 2016, 2:58 PM
SmilingDemon renamed this task from Rail detection no longer works on rail rotators with custom rotation to Rail detection with rotators and set rotation broken.
SmilingDemon changed the task status from Open to In Queue (Game).
SmilingDemon raised the priority of this task from Normal to High.
Restricted Application edited projects, added Game Development; removed Issue Navigation. · View Herald TranscriptDec 17 2016, 3:02 PM
Restricted Application added a subscriber: AndyP. · View Herald Transcript
AndyP changed the task status from In Queue (Game) to In Queue.Mar 10 2017, 5:04 PM
Restricted Application added a project: CBS: Rails. · View Herald TranscriptMar 10 2017, 5:04 PM
AndyP moved this task from Backlog / Unclassed to Alpha on the CBS: Rails board.Mar 11 2017, 9:22 PM
schema added a commit: Restricted Diffusion Commit.Mar 14 2017, 11:44 PM
schema changed the task status from In Queue to Resolved by committing Restricted Diffusion Commit.
Restricted Application added a project: Quality Assurance. · View Herald TranscriptMar 14 2017, 11:44 PM
lancake claimed this task.

-QA Testing-

I don't think this change should be the intended behavior.

If something moves on a rail block, it sets any nearby signal to true.
If it moves away (or undocks), it sets any nearby signal to false.

This change made the rotator block an exception to that rule. It sets any nearby signal to true after it's done with the rotation cycle. That doesn't work well since after the rotation cycle it also tries to move it away to the next block.

What it should do:

  1. Send a true signal to nearby blocks when a rail entity moves on the rotator at the start of every rotation (even if the rotation is 0 degrees/disabled)
  2. Send a false signal to nearby blocks when a rail entity moves away from the rotator to another rail, this would happen at the end of a rotation cycle (unless it's 0 degrees again)

Even with this fix, 2. doesn't work at all. It doesn't get set to false either by moving it away, or by undocking.

lancake edited Tester information (Internal use only). (Show Details)Mar 20 2017, 3:38 PM
lancake changed Last tested (version) from 0.199.253 to 0.199.485.
lancake set First occurrence (version) to 0.199.253.
lancake changed the task status from Resolved to In Queue.
Restricted Application removed a project: Quality Assurance. · View Herald TranscriptMar 20 2017, 3:39 PM