Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Starsector 0.95.1a is out! (12/10/21); Blog post: Hyperspace Topography (10/12/22)

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Thaago

Pages: [1] 2 3 ... 439
1
Suggestions / Re: Eagle and (base) Falcon remain anemic
« on: November 29, 2022, 03:29:59 PM »
Quote
Interesting.  Overall, a 33% increase in base flux dissipation (or about 21% increase in max) over the 0.95a Eagle.

It's 16.6%

It's 16.6% for the 0.95.1a Eagle, but 33% for the 0.95a Eagle.  To be fair, comparing to the previous release Eagle flux stats is a bit odd, but I was just struck by such large back to back flux stat buffs, on top of the coming 20 DP cost. It's gone from typical middle of the pack cruiser flux stats of it's original design to high tech tier flux stats.  I think it had been 525 flux/second since it's inception until the current release, but I only started around 0.7.  But being kind of in the slow but shield tanky slot like the Apogee, it's becoming clear it needs it.

From 0.95.1a patch notes:
Quote
Eagle:
Increased flux dissipation to 600 (was: 525)
Increased flux capacity to 11000 (was: 10000)

My point was the 0.95a Eagle (from the prior release) had only 525 flux dissipation (and 10,000 capacity) and we are discussing 700 flux dissipation and 11,000 capacity here, which means the 0.95a Eagle was that severely under tuned compared to other 0.95a ships like the Champion.

I think part of this is also recognizing the major buffs that missiles have gotten with the missiles skill potentially adding new ammo and +50% fire rate, all flux free. The Eagle only has 2 small missile mounts so it fell further behind in damage potential compared to Champion/Aurora/Dominator etc even though its flux got a buff.

Plus the skill system rewarding either ballistic or energy with the 'mastery' skills makes it harder for mixed firepower ships to stack bonuses, and the system expertise skill is ok but not great on the Eagle/Falcon as its just a medium/small speed increase... the updated skill system in general was not very kind to the pair!

2
"Profile" (in the top bar) --> "Look and Layout Preferences" (under modify profile on the left) --> "Current Theme" (hit the 'change' link! --> scroll down and select the dark theme.

Considering only about 1% of people are using the dark theme, its probably a bit hidden :p

3
Oh yeah, if a full implementation isn't running and verified to be outputting correct data (and to which an optimized version can be compared with to check integrity) then any optimization is a total waste! I haven't used Julia myself but I have a friend who really likes it for numerical work.

4
Suggestions / Re: Eagle and (base) Falcon remain anemic
« on: November 24, 2022, 10:59:20 AM »
I think Eagle vs Eradicator is a nice case for where the Eagle currently works, and a hint about how to fix it for general use: its juuuust fast enough to keep the eradicator in range after they initially close with each other and has the defensive stats to whether the fire, so it can control the engagement and win. As a contrast, when the Eagle is slower than its opponent it can't control when its medium energy mounts are in range and it can be reduced to 3 medium ballistics only for firepower. So I'd really like to see an Eagle speed boost: 50 base speed is too slow for a medium cruiser... with system its 75 (but the system doesn't benefit from navigation boosts so its a bit slower in practice than a 'real' 75 speed ship) which is 'ok', but then the ship effectively has no system!

On the one hand, I'm excited for IR autolance! On the other, I don't like the idea of a ship's weapon mount being pigeonholed into just a few options because the other options don't work well with the ship design.

5
@intrinsic_parity

Nice code! Very readable and clear which is always the most important thing in code when getting it working/checking it. In terms of optimizations I see a few things that should help but will reduce readability. In particular, avoiding instantiating new arrays when possible should give a large performance boost.

The first that pops out to me is that the getArmorIndexes is instantiating 2 new arrays each time it is run, but this is never used in parallel IE its never needed for 2 different sets of masks to exist at the same time. So, if an array for inner_cells and outer_cells is instantiated once externally, then passed as arguments into this function, that could be avoided... of course now the code has to keep python's referencing scheme really solidly in mind or its going to have odd bugs, and also needs to be careful about only using 'in place' operations which can be nasty if you aren't used to it because of python's opaque passing model.

For in place operations, probably the most helpful thing is that all of the +=, *=, etc operations are by default in place, so using them is 'safe'. For boolean operations using += and *= can change the data type to int by accident, but using the bitwise operators &= and |= are safe. |=True will flip elements to True, while &=False will flip elements to False. There is also numpy.copyto, which is in place and also accepts an optional mask! Seems perfect for later work if the base operations are too clunky.

It's easy enough in python to do accidental initializations that I'd want to do comparative unit tests between and final code and a equivalent but deliberately re-initializing code to make sure there is a time difference. Kind of blarf, optimization sucks!

As you pointed out armor_grid.shape doesn't change, so can be precomputed and passed as an argument, though its probably not costing very much. The bounds checking can be commented out for a "production" run or put on an if debug==True statement.

'damage_armor' is similarly a new array, but only one is ever used in the calculations at a time, so can be externalized and only modified in place instead of instantiated (again with *=, += etc functions).

'damage_hull' in armor_update doesn't need to be instantiated at all as an array as every operation on it is elementwise and its not returned. I think
Code
damage_hull_total = np.sum(np.maximum(damage_armor - armor_grid, 0) * dmg[2] / dmg[1])
Will do the truck because numpy should detect that every function is elementwise... but I'd want to test to be sure and I could be wrong there.

There are probably other small things, but this is the thing that pops out to me!

6
In terms of capturing points, I find that it depends what game "theme" I'm playing. If I'm playing a game where I am using high performance frigates (scarab/tempest/hyperion/omen/remnant ones/phase frigates in particular, there are probably a few more) then its not hard to just grab a pair of points to start the match... and then later on if the enemy is too strong, cancel those and capture the enemy's points. They will trickle ships to reinforce them at which point a few control group frigates + right click eliminate orders kills the isolated stragglers. Easy way to even up a fight if using some "wolfpack" style ships and if the rest of the fleet can successfully kite the enemy main force.

If I'm going for slow ships that can't outrun the enemy, like a low tech battle line for example, then I rush heavy metal on the control points (maybe leading with some disposable lashers/kites/etc to distract enemy frigates) and then turtle up. Use my player ship to either turn the flank (if using a mobile striker) or to break the enemy wherever I am (if going for a combat specced battleship).

7
If you are writing in Python and the actual math is done using matrices, then you should be able to get nearly all of the speed of C/Fortran by using the Numpy library to do the matrix computations. Numpy has a true array object (set size/data type, contiguous memory, etc) implemented in lower level languages and already wrapped, so you don't need to do that yourself. Depending on the actual operations being done you can even call the BLAS/LAPACK Fortran functions directly (though this is a bit of a pain as you need to wade through the obscure naming conventions of the functions from the 70's).

Also, update to Python 3.11 if you haven't yet: it offers a pretty decent performance upgrade over past versions!

[Edit] Reading the above code, because your matrix operations are element-wise, with Numpy you can do the whole operation in 3 lines with no if statements/loops: 1 line to do the whole armor grid modification, 1 line to sum up the hull damage , 1 line to reset negative armor sections to 0. All looping is handled by numpy's element-wise coding (low level language), the functions being called are Sum, Numpy.maximum (elementwise maximum of an array, IE doing it for the individual components), and arithmetic.

8
Suggestions / Re: Eagle and (base) Falcon remain anemic
« on: November 20, 2022, 01:07:19 PM »
I find Falcons are pretty good now, but I agree on Eagles.

For Falcons I find that they are fast enough to use the 600 range medium energy guns - particularly phase lances - so they have 'decent' firepower for their DP and very good mobility/defenses if kitted for closer ranged engagement. Easily kills destroyers (which it should at 14 DP vs their ~10) and can tank cruiser firepower while being fast enough to hit and retreat. For long range IE ion beams + HVDs or some other 1000 range combination, they have a very good speed + range combo (best in the game by a pretty large margin) at the cost of low DPS.

For Eagles, I don't think they can use 600 range energy weapons effectively because they are too slow compared to the cruisers that have come out recently, and they are a worse kiter than the Falcon (slower) for more DP in the long ranged role.

9
Suggestions / Re: New Player Experience SUCKS
« on: November 20, 2022, 11:27:19 AM »
I don't think bounty rewards are too low, its just that bounty hunting gets harder and requires more game mastery as the player advances through bounties. It has a "normal" difficulty curve as opposed to the inverse curve of most of the rest of the game.

The bounties available if the player has not done any yet require a single player frigate for on the order of 50k reward. Combining with other missions in the area, exploring, etc makes for a very profitable run for no investment. The 100k ones need a player fleet on the order of what they leave the tutorial system in (destroyer or two, maybe a carrier, a few kiting frigates), so again decent profit for no investment. Losing a ship in these fights is just fine: it is much less costly than buying the same ship because there is a high likelihood (or guaranteed if there is an officer or s mod) for recovery. This can make D mods, but D mods are a marginal cost much lower than the cost of the ship (no skills needed).

Later bounties at the 150k+ level get harder, but at the same time the player has detailed knowledge of the enemy fleets before going to do the mission: its reasonable to not do ones that look too hard or to refit the fleet to counter the expected enemy. These missions aren't quite as profitable as they were in past versions because it takes more skill investment to recover pristine/near pristine ships, but for a player that wants to go the industry route these bounties have "bonuses" on the order of 200k to 1 million credits depending on what ships they recover.

For bar missions, you can run/hide/dodge away from 'revenge' fleets. Its not even particularly unusual to dodge fleets that are too big for the player - isn't that the standard gameplay in any hostile system or when doing any transponder off mission/trading?

10
General Discussion / Re: What is your prefered piloted ship type?
« on: November 17, 2022, 05:21:10 PM »
I tend to pilot a destroyer for much of the early game as part of a destroyer/frigate pack and then just straight to a capital, usually one that can either move fast (Conquest, Odyssey) or move fast towards the enemy (Onslaught). Sometimes I'll fly a burn 9 light cruiser if I find one at a convenient time.

11
General Discussion / Re: How to build Doom correctly?
« on: November 17, 2022, 05:16:52 PM »
Oh yeah, pirate afflictors are interesting. Their OP reduction makes them need to lose something, but they can still support 2 AM blasters + the absolute essential hullmods, and their great system is still at full strength. I'd say on a DP point basis they are stronger, doubly so because of the 40 DP Phase Coil Tuning limit, but at the same time they are less officer efficient because on an absolute basis they are weaker ships. In that respect they combo extremely well with Support Doctrine because the non-officered DP is greatly amplified in effectiveness.

12
Mods / MOVED: [0.95.1a] LunaLib 1.0.1
« on: November 17, 2022, 05:12:13 PM »

13
I think it depends a bit on skill build and exactly what the player wants from fighters, but I've made good use of converted hangar before.

One thing that really benefits Converted Hangars when mods are involved is a "medium tier" support fighter that sit between the 0 OP (+converted hangar cost) Mining Drones and the 27 OP (+converted hangar cost) Xyphos. Wasps work pretty well to blunt the initial impact of a fighter/missile heavy enemy fleet with their mines, and good old broadswords give decent kinetic pressure and hull regen without being too slow.

I haven't really played around with it for bombers due to the speed penalty on already slow wings and the increased OP costs - I know some people like Longbows but they just seem so expensive! If I could tell the AI to always keep the Longbows in reserve, so they hang out behind my ship zapping missiles and firing sabots, that would be a lot better for converted hangar, at least in my opinion.

14
Modding / MOVED: [0.95.1a] LunaLib 1.0.1
« on: November 17, 2022, 04:31:11 PM »

15
Modding Resources / Re: [0.95.1a] LunaLib 1.0.1
« on: November 17, 2022, 04:31:02 PM »
Oh this is really interesting!

I could see someone making an addon that essentially wraps Nexelerin's various config file setting with this, as there are a large number of "scenarios" that people have come up with that rely on changing a bunch of values in the config file.

Question: could a mod maker use the enum field to have preset combinations of the different fields which are then populated? Like say the user selects "standard start" from an enum, and then that changes the user enterable field "starting ship" to "Wolf", but then the player could manually change it to something else?

I feel like I explained myself badly there, but the idea is to have preset options which can then be tweaked by the user.

[Edit] It also just ocured to me that this library makes it trivially easy to do something like game difficulty settings that can be customized either at game start or mid playthrough. Thats kind of excellent!

Pages: [1] 2 3 ... 439