Author Topic: Ship out of control (5 seconds after beaming/transporting) Bug  (Read 1064 times)

Offline Tethys

  • -=USF=- Co-Leader
  • Posts: 256
  • Cookies: 89
Ship out of control (5 seconds after beaming/transporting) Bug
« on: September 06, 2018, 07:03:22 PM »
This bug can be fixed by forcing Felix to activate "Stop" under the Orders menu (has its own window, upper left corner). This will require some scripting. I am currently trying to use imports inside Transporter.py to activate the "OrderStop" within the TacticalMenuHandlers py. I think this has something to do with ForceTacticalVisible, as it forces the Tactical window visibility 5 seconds after beam sequence, whereafter Felix decides to take control of the ship, overriding the players input.

Manually, this can be worked around simply by clicking "Stop" before or within 5 seconds after beam sequence is complete.

Offline Defiant

  • Posts: 398
  • Cookies: 1105
    • BC: Kobayashi Maru
Re: Ship out of control (5 seconds after beaming/transporting) Bug
« Reply #1 on: September 07, 2018, 01:27:55 AM »
Can you please be a bit more verbose? e.g. Why you want it changed and when exactly it does happen? The Transport.py usually switches to the Bridge, not tactical view

Offline Tethys

  • -=USF=- Co-Leader
  • Posts: 256
  • Cookies: 89
Re: Ship out of control (5 seconds after beaming/transporting) Bug
« Reply #2 on: September 12, 2018, 07:50:20 PM »
Basically, whenever I transport to a new ship, Felix decides he's the boss and joy rides around, no matter where I steer or how fast I want to go. The only thing that will make him stop is to actually click on 'Stop' in his menu. It's just.. I don't know.. annoying to turn left and watch the ship go right, up, down, or any other direction than left really. I can probably alter it so that when you click Transport, it automatically calls the function responsible for Felix's stop command, but it would take me a few weeks as I have many projects going at once.

Offline Defiant

  • Posts: 398
  • Cookies: 1105
    • BC: Kobayashi Maru
Re: Ship out of control (5 seconds after beaming/transporting) Bug
« Reply #3 on: September 13, 2018, 12:54:46 AM »
This is probably not felix, but the default ship AI still running (felix is a different ai script). According to transport.py the stop command is send.

Also I just tested that by creating a new battle with an enemy Warbird and a friendly Akira and could not reproduce it.

Offline Tethys

  • -=USF=- Co-Leader
  • Posts: 256
  • Cookies: 89
Re: Ship out of control (5 seconds after beaming/transporting) Bug
« Reply #4 on: September 13, 2018, 10:16:27 AM »
Then perhaps it is due to my own tinkering. I have noticed that altering some things has unintended side effects in other places you'd think are unrelated. My test was done on a LAN game.

My test had 1 friendly ship and myself, no enemies in the set. I transported from my Defiant to the Akira, after about 5 seconds the Akira that I am controlling starts doing erratic maneuvers, unless I click Stop on Felix Order menu. I don't know how I broke it, but I know I can fix it if I get some time.

Offline Defiant

  • Posts: 398
  • Cookies: 1105
    • BC: Kobayashi Maru
Re: Ship out of control (5 seconds after beaming/transporting) Bug
« Reply #5 on: September 13, 2018, 11:44:49 AM »
The MP behavior can be totally different to the SP one. The transporter.py has extra code to handle the multiplayer AI. Can you please try to reproduce it on vanilla KM?

Offline Tethys

  • -=USF=- Co-Leader
  • Posts: 256
  • Cookies: 89
Re: Ship out of control (5 seconds after beaming/transporting) Bug
« Reply #6 on: September 13, 2018, 06:45:28 PM »
Kobayashi Maru (KM) - Version 2011.10

The bug is present. Video coming. Uploaded to Facebook group Star Trek Bridge Commander.

https://www.facebook.com/claudio.z.cocchiaro/videos/1997564226962681/

https://www.facebook.com/claudio.z.cocchiaro/videos/1997566543629116/

Offline Defiant

  • Posts: 398
  • Cookies: 1105
    • BC: Kobayashi Maru
Re: Ship out of control (5 seconds after beaming/transporting) Bug
« Reply #7 on: September 14, 2018, 12:49:26 AM »
Seems like a facebook account is required to view the videos, I don't have one.


Offline Defiant

  • Posts: 398
  • Cookies: 1105
    • BC: Kobayashi Maru
Re: Ship out of control (5 seconds after beaming/transporting) Bug
« Reply #9 on: September 15, 2018, 02:38:50 AM »
That works.

Are you multiplayer client or host? Just tried to reproduce it as host, and my transport target stopped automatically.

Offline Tethys

  • -=USF=- Co-Leader
  • Posts: 256
  • Cookies: 89
Re: Ship out of control (5 seconds after beaming/transporting) Bug
« Reply #10 on: September 15, 2018, 09:14:54 AM »
Also host. This should be on a vanilla KM 2011.10 unmolested as far as I know. I will check my other KM versions, I have about 7 or 8 installs.

Offline Defiant

  • Posts: 398
  • Cookies: 1105
    • BC: Kobayashi Maru
Re: Ship out of control (5 seconds after beaming/transporting) Bug
« Reply #11 on: September 16, 2018, 04:36:54 AM »
Here is the video from me trying to reproduce the problem:

https://vimeo.com/290112320

Offline Tethys

  • -=USF=- Co-Leader
  • Posts: 256
  • Cookies: 89
Re: Ship out of control (5 seconds after beaming/transporting) Bug
« Reply #12 on: September 17, 2018, 09:28:49 PM »
I had all mutators except GC enabled on the KM 2011 vanilla test. My KM dev test I had all mutators enabled.

Perhaps a mutator or setting is responsible? I have altered my keyboard keybinds via settings, unmodded. I do not believe that it is any bug in the code on my end. I am puzzled as to why you cannot reproduce this bug. I will perform the test exactly as you did, since I used my keybind to do the transport (alt+t on mine). Perhaps alt or t may be affecting Felix in some way. I will report back soon.

Edit 1: Some good news. It is in fact the keybind. Alt+t seems to be the culprit. I clicked Transport button and verified it 3x that Felix did not take over the helm. I will do some more tests and try to find a more suitable keybind.

Thank you for the help Defiant. This particular issue has been bugging me for years. Perhaps one day I will look for the files responsible for toggling the Felix autopilot (something tells me its to do with the t, but more testing is required) and try to fix it. Perhaps there is a feature the developers wanted to add that they could not finish, and had to remove, but didnt get all of it out. At least now we know what's the issue here. If you have time, I recommend testing out the alt+t keybind for the Transporter and use the keybind to try to reproduce the issue. I'll bet you get the bug then.  :thumbsup:

Edit 2: It appears that ANY keybind, whether used with ALT+anykey or just anykey, causes Felix to take control of the ship, overriding user input with regard to piloting. One possible solution would be to trick the game into thinking a keystroke is equivalent to a mouse click on the button. I will do some analysis but not exactly sure what I'd be looking for at this time. First I want to try to fix the missionmenu pys for the multiplayer game modes, as some of the GUI is missing on the right and bottom of the Ships and Bridge selection menus, and when null space is clicked the screen goes black.

Offline Defiant

  • Posts: 398
  • Cookies: 1105
    • BC: Kobayashi Maru
Re: Ship out of control (5 seconds after beaming/transporting) Bug
« Reply #13 on: September 18, 2018, 01:01:38 AM »
Please check if something is in the console when this issue occurs. You need to exit the mp game to enter the console again.

Also it might be duplicate keybind, we need to check that the keybindings are not responsible. Sometimes bc does not show all currently used. So try with KeyboardBinding.py/KeyboardBinding.pyc removed.

Offline Tethys

  • -=USF=- Co-Leader
  • Posts: 256
  • Cookies: 89
Re: Ship out of control (5 seconds after beaming/transporting) Bug
« Reply #14 on: September 19, 2018, 08:08:25 PM »
I tried with the files removed and I had to assign a keybind, so I chose the \ button, which was also bound to team chat. Same issue, Felix flies away. I could not access the console at this time.