Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[DesperatePeter]

I just released 1.7.1.

It includes the fix contributed by Genir, many thanks for that! Previously, weapons that had the string "none" (rather than e.g. null) as their tracking value were considered to have tracking. This will no longer be the case.

Additionally, it fixes the issue with PrioritizePD prioritizing flares even with IPDAI.

Lastly, while I was unable to locate the cause for the memory-leak caused by the in-combat GUI (unfortunately IntelliJ Community Edition comes without a profiler =/), I think I was able to circumvent the issue. Before, the status of the buttons was re-evaluated every frame. I now changed it so that a re-evaluation is only performed when a button was clicked. So while there might still technically be a tiny memory-leak, leaking once per button click should be much more manageable than once per frame.

My game seems to freeze and even causes my gaming laptop to suffer a critical video memory shortage (and BSOD) whenever I use the in-combat GUI. It usually happens when I flick some of the options and I happen to loiter in the interface too long. Even with this mod being the only one turned on, I tested it on a mission and I eventually received a BSOD. I happen to use JRE8, so I swapped back to JRE7 and tested it again. While it no longer crashes, a periodic lag could be noticed while the combat GUI is pulled up.

Please let me know if this fix works for you!

I admittedly didn't test everything thoroughly, so please let me know if any of the issues still persist.

[Tito]

Is it possible to add a tag "only fire at overloaded ships"?

[Genir]

What IDE are you using? I'm asking, because I was thinking about running IntelliJ autoformat on the entire code base.

Auto formatted code is not necessarily better that the current one, but having an agreed-upon format standard works well for projects developed by multiple people. And I guess IntelliJ auto format is the standard for Kotlin, since both are developed by the same company.

Autoformat touches about every file in the project. It also replaces deprecated function calls without introducing issues, how nice.

What's your opinion on that?

[DesperatePeter]

Is it possible to add a tag "only fire at overloaded ships"?

Sure, sounds easy enough!
I'll try to include it in the next release.
Though I probably won't add it to the list of tags available by default, since it's a rather niche tag.

What IDE are you using? I'm asking, because I was thinking about running IntelliJ autoformat on the entire code base.

Auto formatted code is not necessarily better that the current one, but having an agreed-upon format standard works well for projects developed by multiple people. And I guess IntelliJ auto format is the standard for Kotlin, since both are developed by the same company.

Autoformat touches about every file in the project. It also replaces deprecated function calls without introducing issues, how nice.

What's your opinion on that?

Yeah, I also use IntelliJ.

Sure, go ahead, sounds good! =)

[MrNage]

Please let me know if this fix works for you!

Tested it. The problem still persists. If it helps, what I noticed is that in-combat camera elements such as the zoom and camera pan still seem to register despite the mod GUI having the screen on pause. I guess that the game has trouble reconciling the former with the latter, especially on JRE8.

[Ithiloneth]

This is a lovely mod - thank you!

When I target a module via R-Key and open the combat-GUI, I can adjust weapon group tags for that module.
So, from my testing, everything seems to work fine.

If I go into the simulator with the main hull of a modular ship then all the modules are present in the simulation.
From there, I am able to target a given module with 'R' and set the rules.

However, once the battle ends these rules are not saved, and need to be re-applied upon starting the next battle.
The main module's rules persist across battles.

Do you think it could be possible to make the rules persist for the modules across engagements?

My testing was done with the Tahlan-scalartech faction's Gown class.

[DesperatePeter]

Tested it. The problem still persists. If it helps, what I noticed is that in-combat camera elements such as the zoom and camera pan still seem to register despite the mod GUI having the screen on pause. I guess that the game has trouble reconciling the former with the latter, especially on JRE8.

That's too bad =/
I really hoped this would fix it. Then it is almost certainly an issue with the rendering. It might be, like you suspected, the fact that I lock the camera (which only locks the actual camera, not all UI elements), it might be some fundamental problem with the rendering or I might have screwed something up with OpenGL. I'll try to have another look in the near-ish future.

This is a lovely mod - thank you!

Glad to hear that =)

If I go into the simulator with the main hull of a modular ship then all the modules are present in the simulation.
From there, I am able to target a given module with 'R' and set the rules.

However, once the battle ends these rules are not saved, and need to be re-applied upon starting the next battle.
The main module's rules persist across battles.

Do you think it could be possible to make the rules persist for the modules across engagements?

My testing was done with the Tahlan-scalartech faction's Gown class.

I feel like the problem here might be that modules, unlike regular ships, don't have a consistent fleet member ID. I'll try to have a look if there's something I can do to fix this, no promises though.
Maybe I can use some other way to store module information, such as e.g. an array of modules stored under the ID of the parent ship. Might take me a while though, as I currently lack the time & motivation to spend a lot of time on this mod. I'm sure I'll feel more motivated again in the future, e.g. when the new update drops and I start playing again xD

[Ithiloneth]

Might take me a while though, as I currently lack the time & motivation to spend a lot of time on this mod. I'm sure I'll feel more motivated again in the future, e.g. when the new update drops and I start playing again xD

Fully understandable ^^

On another note:
AvoidShields+ isn't working as I had hoped, and AvoidShields is not quite radical enough.

I want to fire a quick pulse EMP weapon when the enemy:

• Is in range.
• Has lowered shields.

Whether the ship has high or low flux is not relevant as the enemy won't have time to raise shields to react to the shot.
The term "sniping" comes to mind here.

With Avoid shields and/or Opportunist, I can get the beams to fire at ships that have high flux, are overloaded, or are venting.

• Raised shields soak the EMP - not all EMP weapons have potent shield arcing properties.
• Overloaded ships usually get destroyed before coming back online; disabling their weapons has little meaning.
• Venting ships are decent targets for my use case.

I tried setting AvoidShields+ with and without Opportunist; no luck, force AI false/true does not seem to help.
The beam will then only fire when the enemy ship can't raise shields, but at that point it's HE time and the EMP isn't as valuable.

Specific weapon setup is 2x Stitch Beamlance from Scalartech Solutions, and there are no other weapons in the group.
The two slots are close together; both weapons have been well in range during testing.

The weapon is Energy/EMP, beam, pulsed, with 4 charges (reloading).
It has no charge up worth mentioning.

Picture: Weapon Group 3 was not firing so I paused the game to check ammo; it's full. Enemy ship has had lowered shields for several seconds, and the weapon has not/isn't firing.
If I set to normal AvoidShields the weapon still would not fire.
I do not, generally, use "R" targeting it was done here to enable the hud for the image.


Update:
I think the issue is that the AI isn't acknowledging that the weapon could fire before the shields are raised.
The reason I think this is because the readme clearly states that the AvoidShields tag will consider whether  shields could be raised in time, and at that time the firing threshold is lowered by 25%.
This impliesthat if the shields could not be raised in time, they are considered to be off.

Code

# Shield thresholds: When not flanking shields and shields are on, the shield factor is simply
# equal to (1 - fluxLevel) of the target. When flanking shields, shield factor == 0.
# When shields are off but the enemy ship could raise them in time, the shield factor is equal to (1 - fluxLevel)*0.75
# When omni-shields are off, it's considered as half-flanking (subject to change)
# For frontal shields, unfold time and projectile travel time are considered to determine flanking
# For modes that want to hit shields, reducing the threshold makes them more likely to fire
# For modes that want to avoid shields, the opposite is true

Picture 2: Demonstration that I could unpause the game and fire the weapon; scoring a clean hit. The pulse faded in fractions of a second; before shields could start to absorb any of the damage done.

[Ithiloneth]

My current best solution, which is working fine as far as I can tell is to set avoid shields, with the config at 0.15.

Code

"avoidShields_threshold" : 0.15      # i.e. Attack if target flux > 85% (simplified, see above)

A proper EMP snipe mode would still be lovely to have, but the current tools are really helpful and I'm very grateful to have them.

[DesperatePeter]

Tested it. The problem still persists. If it helps, what I noticed is that in-combat camera elements such as the zoom and camera pan still seem to register despite the mod GUI having the screen on pause. I guess that the game has trouble reconciling the former with the latter, especially on JRE8.

I created a test version where all I changed was not locking the camera when the in-combat-GUI is opened: Download
Could you try if this fixes the issue? My guess is that it won't, but at the very least it will rule out one potential cause for the issue.


I also added two new tags: The requested tag that only shoots at overloaded ships and a ShieldsOff-tag, that is a simplified version of the AvoidShields tag. It will fire at things that have no shields and at ships that have their shields turned off, without considering flux levels or shield angles.

Additionally, modes for modules should now be persistent between combats. The issue was indeed that fleet member IDs for modules were not consistent between combats, so I now instead use the fleet member ID of the parent ship plus the module index.

Lastly, thanks again to Genir! He did lots of refactoring work in the background to make the code cleaner & prettier! This shouldn't really be noticeable from a user perspective, but is still very nice from a developer perspective.


Note that all these changes have not yet been released, but if you want to test them you can simply use the current in-development version: Download

[Android9k]

I just downloaded the test version and I can't get either overloaded or noshields to work. Is there anything I need to do other than add them to the taglist in settings.editme? The options appear in-game but they can't be selected with any weapon.

[DesperatePeter]

I just downloaded the test version and I can't get either overloaded or noshields to work. Is there anything I need to do other than add them to the taglist in settings.editme? The options appear in-game but they can't be selected with any weapon.

Thanks for letting me know and sorry for the late reply!
Apparently I forgot to push the updated jar and settings =/ I now pushed these changes, so hopefully it should work now (and be enabled by default, will probably change that on Release).

[MrNage]

Could you try if this fixes the issue? My guess is that it won't, but at the very least it will rule out one potential cause for the issue.

Tested it again just now, still the same as before.

[DesperatePeter]

Could you try if this fixes the issue? My guess is that it won't, but at the very least it will rule out one potential cause for the issue.

Tested it again just now, still the same as before.

Thank you for confirming!
Unfortunately, that means I'm all out of ideas =/
I'll keep it in mind and try to find a solution, but I did another review of all my code and can't identify what might be causing the issues, neither can I reproduce them =/


1.8.0 is out!
It includes the previously mentioned fixes/additions plus a little UI overhaul. I think the changes should be pretty obvious and I hope you like them =) (Note: The new advanced mode is basically what used to be the default before)

Please let me know if there are any issues!

[OperaWolf]

Had a CTD. Finished a battle, chose to pursue the leftovers. My captain didn't participate; I used fast frigates. Chose to watch it play out instead of auto-resolve. While following (F) an officer-piloted ship, I pressed (J) to see if I could check their gunnery control setup. Pressing (J) caused an immediate CTD. There was a "cannot be null" error; I can't remember which one but it seemed like it crashed due to my trying to access gunnery controls while selecting a ship but not controlling it.

I can probably easily recreate it if you need the error details.