Print

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

[Nicke535]

What does the 8/6/5/4% in ship_data.csv mean?

It is an old "memory note" of sorts: it has no in-game effects, but refers to the standard proportions of flux dissipation vs. capacity for the ship classes: 8% of capacity as dissipation for frigates, 6% for destroyers etc.

Values in the column are (in vanilla, at least) generally the capacity a ship "would have" if it was balanced exactly against this benchmark, without being adjusted up or down slightly for the different individual hulls.

[Alex]

@Morrokain: hmm, interesting. Fixed a few places where DO_NOT_CONSERVE was not being respected - that helps a lot. My test case was a Falcon (P) with 2x linked turret and 2x linked hardpoint Typhoons, no expanded missile racks - vs a stock Hammerhead. With the fixes - and the temporary addition of DO_NOT_CONSERVE to Typhoons - it's pretty happy to nuke it.

It doesn't care whether the firing ship is a phase ship, though, so that's odd. It also shouldn't be any more likely to fire torpedoes when the enemy hull gets lower; if anything it might be less likely to. In a few places there's a random element so it's just more likely you'll see it fire as the battle goes on; possibly that's what's being observed here?

[Dwarden]

@alex

i took 'quick' look at some Xenoargh's scrips to notice interesting bit in his ShipPhysics.java

Code

public static ExecutorService shipPhysicsCommonExecutor = Executors.newFixedThreadPool(4);

fast glimpse at starsector core reveals it seems the default value is 2, plus it seems hard-coded
so he double the amount of threads used for his new AI physics

i was wondering if it would be possible to change the amount of threads in similar way for default
as it might be handy nowadays when we can finally use 8-32 cores CPUs

yet i'm not sure if it's changeable value
then it's half-question (if someone can mod it) or half-suggestion (so it's configurable option into future)

thanks in advance for your time (to answer/consider this)

[Alex]

The game's main loop is single-threaded, so I'm not sure what you mean.

I don't think xenoargh's stuff is thread-safe; I wouldn't go down the road of trying to emulate it - it's just asking for obscure, hard-to-debug issues, and the API is generally not thread safe, so it'd be... let's say "difficult" to try to work around.

[Morrokain]

@Alex
Great glad to help! (regarding DO_NOT_CONSERVE).

Regarding Phase ships:

I don't think so as far as the random element is concerned. I feel this way because the behavior is consistent and noticeably different, but I don't think it's a missile specific thing linked to DO_NOT_CONSERVE either.

It may be mod related so I need to do some tests on Vanilla, but I'm pretty sure its linked the the phase AI's threat evaluation in that it doesn't feel like it has the time or possibly flux to fire many weapon groups that aren't on autofire and ends up not firing them at all for some reason. It occasionally fires a group, but prefers (against equal strength opponents as a reminder, not when it feels stronger) to remain in phase as much as possible- presumably because it values not taking damage above dealing damage. That's the only thing I can think of right now because a player can cycle through 3 weapon groups like that before the phase cooldown is done (considering one is flux free and the other is maybe 10% when the AI only has 10% of their max currently in use.) and still phase away after the burst has done serious damage to the enemy.

(So, essentially the behavior I'm seeing affects all strike weapons including energy and ballistic and seems specifically tied to how phase AI handles the STRIKE tag)

[Dwarden]

thanks @alex, hopefully in 'distant' future there will be more 'safe' threading possible
especially with the mainstream hardware progress toward multicore counts

[Ed]

Do anyone know how to make a visual effect that resembles something like a soundwave? (yes, i know no sound in void, yada yada), i want for a system that increases in combat radar range, i did try the Graphics lib wave, but i can only make it look like my ship is being pulled into a blackhole instead.

[Morrokain]

It also shouldn't be any more likely to fire torpedoes when the enemy hull gets lower; if anything it might be less likely to.

Oops didn't catch this, I meant it fires it more often when the player ship under AI control's hull gets lower, not the enemy ship. Sorry I was definitely being unclear there.

[Alex]

@Alex
Great glad to help! (regarding DO_NOT_CONSERVE).

Yeah, thank you for that! That's some mighty impressive investigative work

Regarding Phase ships:

I don't think so as far as the random element is concerned. I feel this way because the behavior is consistent and noticeably different, but I don't think it's a missile specific thing linked to DO_NOT_CONSERVE either.

It may be mod related so I need to do some tests on Vanilla, but I'm pretty sure its linked the the phase AI's threat evaluation in that it doesn't feel like it has the time or possibly flux to fire many weapon groups that aren't on autofire and ends up not firing them at all for some reason. It occasionally fires a group, but prefers (against equal strength opponents as a reminder, not when it feels stronger) to remain in phase as much as possible- presumably because it values not taking damage above dealing damage. That's the only thing I can think of right now because a player can cycle through 3 weapon groups like that before the phase cooldown is done (considering one is flux free and the other is maybe 10% when the AI only has 10% of their max currently in use.) and still phase away after the burst has done serious damage to the enemy.

(So, essentially the behavior I'm seeing affects all strike weapons including energy and ballistic and seems specifically tied to how phase AI handles the STRIKE tag)

Ah, hmm. Right - I think it's probably that; the AI isn't aware enough of high-level concept to know stuff like "I should burst everything possible now while phase cloak is on cooldown". And it's not super fast as far as switching between weapon groups - and it likes to be careful aiming dumbfire missiles and torpedoes - so that wouldn't play nice with having a 2-second window.

Phase ships *do* get more aggressive as their peak time runs down, btw; basically they estimate how much damage they're likely to take if they unphase (dps of the various weapons that can be brought to bear, combined with their armor, dps damage types, phase cooldown duration), and the threshold for how much they're willing to take goes up as peak time (and then CR) goes down. So it's not to do with their weapons, but with how willing they are to unphase given the firepower they'll face when they do.

Hmm. There are definitely some issues with how willing phase ships are to engage/how well they do it when they come out of phase. Hopefully I'll get a chance to look at it at some point.

thanks @alex, hopefully in 'distant' future there will be more 'safe' threading possible
especially with the mainstream hardware progress toward multicore counts

Honestly, probably not I don't see trying to make the codebase thread-safe (complicated, time-consuming, error-prone, etc), and it feels like optimizing for a high core count is not optimizing for the right case, anyway - it seems like you'd want your optimizations to help on the low end, not on the high end.

[Morrokain]

Yeah, thank you for that! That's some mighty impressive investigative work

 

...how much damage they're likely to take if they unphase (dps of the various weapons that can be brought to bear, combined with their armor, dps damage types, phase cooldown duration), ... So it's not to do with their weapons, but with how willing they are to unphase given the firepower they'll face when they do.

Ah ok, you know what, I recently lowered phase ship armor slightly and I began noticing it more at that time. From that description this may be part of it too then:

Strike weapons have high alpha strike and very low sustained dps (tooltip wise) in my mod compared to assault weapons, so if the phase AI is considering dps and not burst dps then it may "undervalue" those weapons from a "should I engage now?" standpoint. Do you remember if it includes burst dps in this calculation?

[goduranus]

Ah, hmm. Right - I think it's probably that; the AI isn't aware enough of high-level concept to know stuff like "I should burst everything possible now while phase cloak is on cooldown". And it's not super fast as far as switching between weapon groups - and it likes to be careful aiming dumbfire missiles and torpedoes - so that wouldn't play nice with having a 2-second window.

Aha I loaded them with Atropos torpedoes and the AI suddenly does much much better with them.

[Alex]

Strike weapons have high alpha strike and very low sustained dps (tooltip wise) in my mod compared to assault weapons, so if the phase AI is considering dps and not burst dps then it may "undervalue" those weapons from a "should I engage now?" standpoint. Do you remember if it includes burst dps in this calculation?

To be clear, it's looking at *enemy* ship dps, and, yeah, iirc it considers burst. It's not looking at its own dps.

[Morrokain]

^ I see and good to know. Well then that's probably not doing anything to affect the behavior. Yeah, must be multiple strike groups contributing to at least a part of it. I'll rebalance around a single strike weapon group and see if that improves overall combat performance.

Aha I loaded them with Atropos torpedoes and the AI suddenly does much much better with them.

Agreed. The tracking and related GUIDED_POOR tag seem to help make phase ships more comfortable launching torps. It's probably the dumbfire consideration Alex was talking about not finding what it needs for acceptable trajectory within the two second phase cooldown window before rephasing overrides weapon firing.

[Dwarden]

thanks @alex, hopefully in 'distant' future there will be more 'safe' threading possible
especially with the mainstream hardware progress toward multicore counts

Honestly, probably not I don't see trying to make the codebase thread-safe (complicated, time-consuming, error-prone, etc),
and it feels like optimizing for a high core count is not optimizing for the right case,
anyway - it seems like you'd want your optimizations to help on the low end, not on the high end.

actually i talk all the ends, 4 to 8 cores is now low-end ...
mainstream is 12 to 16 and highend is 16 to 64

anyway i get the complexity of rewriting singlethreaded stuff into multithreaded
but if there are portions which could be, then go for it, better to use some of that than none

hardware-wise single-threaded performance will not grow as fast anymore (some % inbetween generations)
and there is no change indicated anywhere on horizont, while core count will keep some steady increases tho

all those complex battles with tons of various crafts or complex economy wise etc. it all screams for threading

[Ed]

What getDParentHull() in ShipHullSpecAPI does? I see it being used in some mods when getting the hull id