Hi, I’ve been testing out the newest 1.1.0 version and I’ve run into some bugs. Just to preface this, but I am running the jre8 version of Starsector on windowed/borderless windowed mode with a bunch of other mods, so not sure if that might affect any of the results.
Thank you for the testing and provided feedback!
UI Scale Issue
UI scaling for the combat GUI matches up the visual buttons and clickable area now, but there is some issue with the scaling relative to the resolution. At the maximum scaling for each resolution (as per Starsector's default limits, 100% scaling at 1280x720, 200% scaling at 1920x1080 and 280% at 3840x2160), the combat GUI ends up positioned too far upper right. This usually results in the first weapon group being cut off from the top and everything right of Hold(Flx>50%) being cut off at the side. This varies slightly for each resolution-scaling combination, but all of them are cut off to some degree.
The positioning seems relative to the scaling-to-resolution ratio rather than the raw scaling percentage. 200% scaling at 3840x2160 is actually centered pretty well, while 200% scaling at 1920x1080 is badly offset.
I downgraded back to v1.0.0 for testing, and the visual combat GUI showed the same issue with the positioning at maximum scaling(albeit with the old visual-clickable mismatch issue)
I think this might be a bigger issue for people running on lower resolutions since the maximum scale for that is just 100% so they’d be permanently stuck with the offset combat GUI.
Haha, I guess I kind of knew that trying to implement a custom GUI with OpenGL would end up producing all kinds of weird issues, which is the reason I avoided it in earlier versions.
Thanks for the detailed description, I'll try to find a solution that works for different resolutions and scales!
Weapon Group Tag Issue
Going back to v1.1.0, I’ve also noticed some problems with the new tag system. For the PD(Flx>50%) option, it seems to trigger based on flux generated somehow. With only the PD(Flx>50%) tag turned on, it causes weapons in the applied group to stop firing at non-PD targets when shields are turned on or other weapons are fired. This occurs even for weapons in the same weapon group, pairing say HVDs and vulcans in a single weapon group and setting PD(Flx>50%) on that group causes the vulcans to briefly stop firing at ships(frigates and up) whenever the HVDs fire. Turning on the shields causes all the weapons in that group to stop firing completely (at non-PD targets, they target fighters and missiles just fine)
I think it might be caused by the trigger condition since while flux is being generated, they target and fire at fighters and missiles correctly akin to the PD tag and can even be paired with the NoFighters tag to only target missiles.
Unfortunately, the new PD and PD(Flx>50%) tags also seems to apply the modified targeting to non-PD weapons in a mixed group, the earlier HVD+Vulcan mixed weapon group test resulted in the HVDs firing at missiles as well.
I went back to 0.13.2 to test and the old PD/PD(Flx>50%) setting correctly ignored non-PD weapons in mixed groups, letting them fire at ships regardless of the PD mode applied and didn’t let them fire at missiles while still applying the respective modified PD targeting to the PD weapons in that mixed group.
On a somewhat related manner, the Combat and Campaign GUI for v1.1.0 differs on the limitations of which tags can be applied to mixed PD and Non-PD weapon groups. The campaign GUI lets you apply the PD/NoPD/PD(Flx>50%) tags to mixed weapon groups, while the combat GUI blocks those tags (can't select or de-select and greyed out) for the same weapon group. Additionally, the PD(Flx>50%) is applicable to purely non-PD weapon groups in the campaign GUI.
Again, thanks for the detailed description! I think I simply forgot to implement the logic where tags that are invalid for a weapon get removed...
Overall, I feel like these issues should be relatively easy to fix, so thanks for pointing them out!
I should have some time to work on them early next week.
Update:
As suspected, I simply forgot to remove tags that were invalid. I added that and it will be included in the next update. For the PD(Flux>X%)-tag: Te behavior you described came from the fact that the threshold was always 0%. I used the wrong regex to parse the threshold, therefore the function that was supposed to extract the threshold always returned 0... Will also be fixed in the next update.
Regarding the difference in the in-combat and campaign GUIs for mixed PD/non-PD weapons:
That was a bool-logic error on my part. I fixed the relevant line of code.
if(true != ship.weaponGroupsCopy[index]?.weaponsCopy?.any { w -> createTag(str, w )?.isValid() == true }){
it.isDisabled = true
}
the .any used to be .all. The line was supposed to read "When all tags are invalid, disable the button" but instead read "When not all tags are valid, disable the button".
Should be fixed in the next update.
Lastly, I simply forgot to add "PD(Flx>N%)" to the list of tags that require a PD weapon in the group to be available, so that was also an easy fix =)
In the combat GUI this didn't happen, because in there I can simply check the tag.isValid() method, because the weapon actually exists. In the campaign-GUI I have to use a different approach (namely, a list of tags that need a PD weapon), since the ship & weapon don't exist in the campaign layer.
So, hopefully, all the Weapon Group Tag Issues you mentioned should be fixed in the next update!