Forums » Bugs
the command doesn't do anything requiring a full restart of the VO client.
Any post to bugs needs to follow the basic rules stated in the sticky thread.
We need to know all the details of your platform, when and where you were in the game, etc.
We need to know all the details of your platform, when and where you were in the game, etc.
Can you try to enter/exit a turret instead of restarting the client?
https://www.vendetta-online.com/x/msgboard/2/38794
https://www.vendetta-online.com/x/msgboard/2/38794
while its usually the case that doing a rotation will fix it up, today for the first time i noticed something new.. shortly after Noon (may be 12:10) atlantic standard time
jumped into odia o7 and subsequently b13 where i used turrets via weapons group/mouse to take out the escorts and locate the dent.. went to m14 and repped my ship, vectored, jumped into i9 where the dent was and my turrets wouldnt fire via mouse. double checked my weapons groups, double checked i had the proper one selected, rotated my turrets.. i couldnt fire them other than entering them to fire.
once the dent was dead i jumped back toward m14 and got caught in a storm.. hit my trigger by accident and my turrets fired finally.. so weird.
jumped into odia o7 and subsequently b13 where i used turrets via weapons group/mouse to take out the escorts and locate the dent.. went to m14 and repped my ship, vectored, jumped into i9 where the dent was and my turrets wouldnt fire via mouse. double checked my weapons groups, double checked i had the proper one selected, rotated my turrets.. i couldnt fire them other than entering them to fire.
once the dent was dead i jumped back toward m14 and got caught in a storm.. hit my trigger by accident and my turrets fired finally.. so weird.
We have tried to reproduce this a few times, and haven't been able to yet. There's also nothing unusual showing up in the logs.
We aren't sure what's going on, yet. If you are able to correlate more aspects of things (for instance, has everyone been testing without plugins?) and find something specific that seems related, please let us know.
We aren't sure what's going on, yet. If you are able to correlate more aspects of things (for instance, has everyone been testing without plugins?) and find something specific that seems related, please let us know.
well therein kinda lay the problem, if im having an issue and i logout and return, that in and of itself may fix the problem. its so random. ill try running one of my clients vanilla for a few days and see what i can come up with. its definitely widespread, and with players using a multitude of code.. ie, the few tri having the problem all run my code, but the others i speak to do not run my code.. and we do not run code they run etc. regardless there may be something we all have in common. shrug. ill see what i can find
For me, the original bug was present all the time. It persisted for so long that I had to give it a name. I called it "turret activation," and I knew that whenever I undocked or docked, I had to activate the turrets before using them. It was so frustrating that I even scripted it to happen automatically. I never had to cycle the turrets; simply visiting any of them was always enough to "activate" them all.
Now, I am experiencing this new issue. Turret activation is not working when it occurs, and I do not know how to fix the situation without leaving the sector or game.
In my case, it also happened in the unrats sector. I believe it always occurred after leaving the ship and docking back. So, the behaviour was the same up to this point. However, visiting a turret did not help this time. What worked for me was jumping out of the sector with the capital ship and then jumping back. This might have been combined with "turret activation," as that has been my scripted-in default for a long time. It has already happeden to me on multiple occasions. As I am reading my original report, I see that this was always an option.
As I stated before, I was extensively and repeatedly testing the original bug without any plugins. I did not even use binds and issued all commands manually to be absolutely sure. I gave up when my reports did not lead to a solution and automated the hotfix. I checked various ships and characters, and the bug remained the same and was easy to reproduce.
The new bug occurred only a few times for me, and it always happened in the sector with unrats. However, it may be correlated with the lack of other testing.
I referred to this as a "new bug" or "new issue" in this post, but in fact, it is the same old bug; only one method of fixing it has stopped working. There are some interesting points in my original report.
https://www.vendetta-online.com/x/msgboard/2/38794
Now, I am experiencing this new issue. Turret activation is not working when it occurs, and I do not know how to fix the situation without leaving the sector or game.
In my case, it also happened in the unrats sector. I believe it always occurred after leaving the ship and docking back. So, the behaviour was the same up to this point. However, visiting a turret did not help this time. What worked for me was jumping out of the sector with the capital ship and then jumping back. This might have been combined with "turret activation," as that has been my scripted-in default for a long time. It has already happeden to me on multiple occasions. As I am reading my original report, I see that this was always an option.
As I stated before, I was extensively and repeatedly testing the original bug without any plugins. I did not even use binds and issued all commands manually to be absolutely sure. I gave up when my reports did not lead to a solution and automated the hotfix. I checked various ships and characters, and the bug remained the same and was easy to reproduce.
The new bug occurred only a few times for me, and it always happened in the sector with unrats. However, it may be correlated with the lack of other testing.
I referred to this as a "new bug" or "new issue" in this post, but in fact, it is the same old bug; only one method of fixing it has stopped working. There are some interesting points in my original report.
https://www.vendetta-online.com/x/msgboard/2/38794
The bug is still present in its new form, so even "activating" the turrets does not help sometimes.
Bractus H-4
/time
GMT is: Sat Sep 28 07:56:31 2024
Bractus H-4
/time
GMT is: Sat Sep 28 07:56:31 2024
I-4 a little while latter, the same results. I don't know if it is related, but another player could not dock with my capital ship (several tries). He managed to right after we both jumped to I-3.
/time
GMT is: Sat Sep 28 09:44:42 2024
Testing in Bractus D-10: my Trident was able to fire turrets, but another player with a Behemoth equipped with Gemini turrets was unable to do so simultaneously.
GMT is: Sat Sep 28 09:44:42 2024
Testing in Bractus D-10: my Trident was able to fire turrets, but another player with a Behemoth equipped with Gemini turrets was unable to do so simultaneously.
i personally havent been able to reproduce it without scripts but my vanilla time has been quite limited.
may be completely unrelated, but i did find it "interesting" that some players reported issues after docking and undocking.. as i noticed some versions of trade assistant got buggy/broken when docking in recent history, within the same timeframe, which lead me to inspect enter/leave station events and related functions in my own code..
oh a hunch/whim i did remove almost all code which uses enter station events as well a few other things and havent experienced any kind of problem since the posts until today.. i thought i had it fixed even though i couldnt really figure out why exactly.. (including my drifting and unable to dock with capship problem), but today out of the blue i encountered both again and it was during an unrat run coincidentally..
i had been idling in odia m14 a considerable amount of time, i undocked from the station and found i couldnt fire turrets in m14.. then i did the regular vectoring to setup for the unrat jumps a minute later, turrets returned but then immediately encountered the ship drifting problem. hehe
still very puzzling, still researching.. (it mainly confuses me because im not using new code, im using code thats worked for a long time until recently) im aware that relating an experience while using lua often produces phantom issues, which ive been guilty of at least once.. just.. offering some thoughts about what ive been pursuing since my initial comment for others who may have script bugs
may be completely unrelated, but i did find it "interesting" that some players reported issues after docking and undocking.. as i noticed some versions of trade assistant got buggy/broken when docking in recent history, within the same timeframe, which lead me to inspect enter/leave station events and related functions in my own code..
oh a hunch/whim i did remove almost all code which uses enter station events as well a few other things and havent experienced any kind of problem since the posts until today.. i thought i had it fixed even though i couldnt really figure out why exactly.. (including my drifting and unable to dock with capship problem), but today out of the blue i encountered both again and it was during an unrat run coincidentally..
i had been idling in odia m14 a considerable amount of time, i undocked from the station and found i couldnt fire turrets in m14.. then i did the regular vectoring to setup for the unrat jumps a minute later, turrets returned but then immediately encountered the ship drifting problem. hehe
still very puzzling, still researching.. (it mainly confuses me because im not using new code, im using code thats worked for a long time until recently) im aware that relating an experience while using lua often produces phantom issues, which ive been guilty of at least once.. just.. offering some thoughts about what ive been pursuing since my initial comment for others who may have script bugs
Silly question, does it print "Turret Control Online" when you use /+ActivateTurrets ?
Does the red "AT" indicator on the HUD count?
I use plugins too, of course. While a few of them I downloaded, the main one is written by me. And I have suppressed the (distracting) message there. On the other hand, the red AT symbol is on the HUD every time turrets are activated, working or not.
The buggy situations just happen to me at random times when I am playing and enjoying the game. So I usually have plugins loaded. But when I was specifically testing the bug (several times), I always had plugins disabled in the configuration and all plugin directories moved away from the path. I also issued all the mandatory commands by typing them manually to be completely sure. And I was still able to reproduce the bug with 100% reliability. I mean the original one. This recent variation is something new even to me and I was unable to test it pluginless yet.
I use plugins too, of course. While a few of them I downloaded, the main one is written by me. And I have suppressed the (distracting) message there. On the other hand, the red AT symbol is on the HUD every time turrets are activated, working or not.
The buggy situations just happen to me at random times when I am playing and enjoying the game. So I usually have plugins loaded. But when I was specifically testing the bug (several times), I always had plugins disabled in the configuration and all plugin directories moved away from the path. I also issued all the mandatory commands by typing them manually to be completely sure. And I was still able to reproduce the bug with 100% reliability. I mean the original one. This recent variation is something new even to me and I was unable to test it pluginless yet.
So, Ray has actually done a bunch of attempts to reproduce this, as well as the earlier reported issue, and has had no luck.
Is there any platform commonality to you guys? Some of you seem to be on Linux, for instance.
We could really use some kind of step-by-step reproduction case, with exact details on platform/etc, and no plugins loaded (vanilla client).
We definitely want to fix this, it sounds like a really frustrating problem, but.. whenever we allocate some time to debug, we haven't been able to get anywhere on reproducing the problem.
Is there any platform commonality to you guys? Some of you seem to be on Linux, for instance.
We could really use some kind of step-by-step reproduction case, with exact details on platform/etc, and no plugins loaded (vanilla client).
We definitely want to fix this, it sounds like a really frustrating problem, but.. whenever we allocate some time to debug, we haven't been able to get anywhere on reproducing the problem.
Yes, it has been so frustrating that I've even stopped playing a few times. Later, I managed to fix the problem with my script by entering and exiting one turret before the first activation after docking, and then I forgot about it.
1) The Original Problem
I am absolutely certain that the problem or bug exists or existed. I was experiencing a 100% reproducibility rate using a client without plugins. You could contact me anytime, and I could demonstrate the bug in real time. I somewhat expected that to happen.
2) The Recent Problem
I cannot reproduce the problem on my own, and I am not regularly playing without plugins. I tried removing the TA plugin that was mentioned, but it did not help. The issue appears occasionally. The last time it happened was when engaging unrats in Bractus on Saturday, 18th October, so it is still present (update below). I am unsure about the most recent occasion before this date. It certainly was several days ago. It only happens to me once out of many occasions, though exceptionally it may occur 2-3 times in a row, then it could be fine for several days.
New Observations:
Bractus D-8
/time
GMT is: Sun Oct 20 09:39:45 2024
My turrets failed to fire again. I disabled plugins, but the turrets still did not work. The AF indicator on the HUD was displayed with /+ActivateTurrets and removed with /-ActivateTurrets. I believe that the "Turret Control Online" messages did not appear.
I undocked and docked back, but it did not help. So, I decided to try the second fix, which involved jumping out and back. I planned a route to an adjacent sector and back. Right before jumping, I decided to check the turrets one more time. They were still not working, but there was a change. The AF indicator was not lit. Since the only change was the planned route, I removed the route on the navmap and checked again. The turrets were not working, but the AF was back. I kept the turrets active (AF lit) and went to the navmap to plan a route. When I closed the navmap, the AF was not lit. I went back to the navmap, removed the route, closed the navmap, and the AF lit up again. So, the AF indicator (while turrets were active) was present only when there was no route planned. The turrets were malfunctioning the entire time. I finally jumped out and back, and the turrets started working immediately. I enabled plugins, and the turrets continued to work. I was in a great hurry to log off, so I might have overlooked something, but I hope that the whole report, or most of it, is correct.
1) The Original Problem
I am absolutely certain that the problem or bug exists or existed. I was experiencing a 100% reproducibility rate using a client without plugins. You could contact me anytime, and I could demonstrate the bug in real time. I somewhat expected that to happen.
2) The Recent Problem
I cannot reproduce the problem on my own, and I am not regularly playing without plugins. I tried removing the TA plugin that was mentioned, but it did not help. The issue appears occasionally. The last time it happened was when engaging unrats in Bractus on Saturday, 18th October, so it is still present (update below). I am unsure about the most recent occasion before this date. It certainly was several days ago. It only happens to me once out of many occasions, though exceptionally it may occur 2-3 times in a row, then it could be fine for several days.
New Observations:
Bractus D-8
/time
GMT is: Sun Oct 20 09:39:45 2024
My turrets failed to fire again. I disabled plugins, but the turrets still did not work. The AF indicator on the HUD was displayed with /+ActivateTurrets and removed with /-ActivateTurrets. I believe that the "Turret Control Online" messages did not appear.
I undocked and docked back, but it did not help. So, I decided to try the second fix, which involved jumping out and back. I planned a route to an adjacent sector and back. Right before jumping, I decided to check the turrets one more time. They were still not working, but there was a change. The AF indicator was not lit. Since the only change was the planned route, I removed the route on the navmap and checked again. The turrets were not working, but the AF was back. I kept the turrets active (AF lit) and went to the navmap to plan a route. When I closed the navmap, the AF was not lit. I went back to the navmap, removed the route, closed the navmap, and the AF lit up again. So, the AF indicator (while turrets were active) was present only when there was no route planned. The turrets were malfunctioning the entire time. I finally jumped out and back, and the turrets started working immediately. I enabled plugins, and the turrets continued to work. I was in a great hurry to log off, so I might have overlooked something, but I hope that the whole report, or most of it, is correct.
Thanks for the additional information..
My turrets failed to fire again. I disabled plugins, but the turrets still did not work.
How are you "disabling" plugins? Do you mean you exited and re-loaded the client from scratch without plugins?
Or is this something you're doing within a single game runtime?
My turrets failed to fire again. I disabled plugins, but the turrets still did not work.
How are you "disabling" plugins? Do you mean you exited and re-loaded the client from scratch without plugins?
Or is this something you're doing within a single game runtime?
During the initial testing, I always removed the plugin directory from the path and also disabled the plugins in the client configuration.
In the situation I described in the latest update, I could not do that. Restarting the client, with or without plugins, would most likely have resolved the issue. Therefore, I simply went to the client configuration and disabled the plugins there. The plugins were disabled, the HUD returned to its default settings, and so on. Unfortunately, I couldn't do anything more. I also did not know that a client restart is required after disabling plugins. Maybe you can consider adding a note to the settings.
In the situation I described in the latest update, I could not do that. Restarting the client, with or without plugins, would most likely have resolved the issue. Therefore, I simply went to the client configuration and disabled the plugins there. The plugins were disabled, the HUD returned to its default settings, and so on. Unfortunately, I couldn't do anything more. I also did not know that a client restart is required after disabling plugins. Maybe you can consider adding a note to the settings.
disabling the plugins in the options menu will not remove plugins that are already loaded by the game; this is why a full restart would be neccessary. Even /reload won't work 100% of the time; even if the game state has changed, parts of old code might still be in the system.
The options menu 'disable plugins' sets a flag in config.ini that, when enabled, skips the default plugin loader during the game load state.
Obviously, you've figured that out now, but for future reference...
The options menu 'disable plugins' sets a flag in config.ini that, when enabled, skips the default plugin loader during the game load state.
Obviously, you've figured that out now, but for future reference...
When I disable plugins while in the game, they actually get removed. The HUD reverts to the standard layout, and my key bindings point to non-existent functions, among other changes.
I'm not disputing the possibility that the game retains some elements, but it's not obvious, and it appears as though the task has been completed. This is quite misleading.
I'm not disputing the possibility that the game retains some elements, but it's not obvious, and it appears as though the task has been completed. This is quite misleading.
I'm not disputing the possibility that the game retains some elements, but it's not obvious, and it appears as though the task has been completed. This is quite misleading.
Disabling plugins for the purposes of testing should involve running a "clean" client without plugins, from scratch (ie, from startup).
There are definitely potential issues with plugin code breaking things and residual issues being left in memory, as Luxen says, if you try loading them first and then unloading them later in the same runtime.
How the HUD looks is not a meaningful measure of the state of the Lua runtime. I wouldn't really call it "misleading", it's the client behaving as close to the goal of a total-unload as we can manage within a single runtime. But for testing purposes, it isn't sufficient.
Disabling plugins for the purposes of testing should involve running a "clean" client without plugins, from scratch (ie, from startup).
There are definitely potential issues with plugin code breaking things and residual issues being left in memory, as Luxen says, if you try loading them first and then unloading them later in the same runtime.
How the HUD looks is not a meaningful measure of the state of the Lua runtime. I wouldn't really call it "misleading", it's the client behaving as close to the goal of a total-unload as we can manage within a single runtime. But for testing purposes, it isn't sufficient.