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

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.

16

Suggestions / Re: Give the pulse laser a bonus vs shields

« on: January 04, 2023, 01:13:48 PM »

I personally would vote for reduced flux cost to make PL both more efficient and easier to fit flux budget-wise. Matching IR pulse laser at .8 efficiency (300 DPS, 240 flux/sec), or matching auto pulse laser efficiency at .75 efficiency (300 DPS, 225 flux/sec) seem like some obvious candidate values to me. Those three guns already have range and damage/shot differentiating them for mount size and they are all trying to fill the energy slot shield damage role so I feel like it makes sense.

I'm unconvinced that the heavy blaster's dps actually mitigates its poor efficiency when it comes to anti-shield. The factors that make that true are niche: when I'm actually fielding the weapon I find it to be a poor shield breaker because the ships mounting it flux themselves out before breaking the shield unless they have very high flux stats (SO ships use it well for example).

Its a great weapon, but not very good vs shields.

It is, when player piloted.

You slowly build up shield flux on target (possible in multiple passes, venting close to enemy - AI almost never  counter-vents), then time it so that you have full flux capacity to dump when enemy is about to overload. This is what a HB Wolf has to do vs Enforcer, for example. Though in a better scenario, you build up flux mostly with other weapons, and use HB only for flux regen overflow, like 2 Railgun + 2 HB Medusa.

On the other hand there is nothing you could smartly exploit about Pulse Laser - it's lackluster through and through.

IMO that's not really exploiting the the actual weapon, but rather just a property of those specific ships. I would say wolf/medusa (under player control) can exploit their mobility systems to mitigate flux war inferiority by venting safely on demand, so they can choose the higher damage output weapon and not worry about the flux stats too much (under player control). But you can just as easily use teleport+venting shenanigans with pulse laser to overcome flux inferiority too, it's just less often necessary because you have better efficiency to begin with. Maybe you could argue HBs lower rate of fire makes it a bit more bursty, but I don't think that's a huge factor.

17

General Discussion / Re: Optimizing the Conquest: a Mathematical Model of Space Combat

« on: December 20, 2022, 08:13:13 AM »

It was never valid to model a ship as a tangential line. I always assumed that was just a simplifying assumption to easily make sure things work while we were developing code. Ships have weird geometry that results in corners and stuff, so regardless of what assumptions you have about the firing vessel, you're going to have to deal with non-trivial armor grids at some point.

18

General Discussion / Re: Current thoughts on Eradicator(P)?

« on: December 19, 2022, 08:14:51 AM »

I don't think pirate eradicator was bad, but normal eradicator was very good which overshadowed it. I do think the amount of armor that both ships have is underrated.

19

General Discussion / Re: Optimizing the Conquest: a Mathematical Model of Space Combat

« on: December 16, 2022, 10:27:40 PM »

A factor of 2 in compute time should not be a big deal IMO.

Also, you can definitely get a good idea of balance with a small set of tests. The only time you need to do really exhaustive searches IMO, is if you are trying to find the 'optimal' builds completely numerically (without any prior knowledge or intuition). If you start with some idea of some builds with existing (balanced) weapons, that are good, then you really only need to compare your new stuff to the existing stuff to see if it is an outlier. Basically, a smart testing methodology should preclude the need for exhaustive searches.

Also, it really shouldn't be an issue to have multiple ships firing at once.

If the simulation time step is the same as the game so that shots always happen exactly at simulation time steps, then for normal weapons (no burst/charge up/charge down) it's just some straightforward modular arithmetic to check if a weapon is firing or not at any time step, given the time of the first shot. If you know in advance when weapons with start/stop firing, you can do all the checks in advance, but there is also a good argument for supporting some dynamic decision making for when to fire or not, since that is how the game actually works.

For burst/charge up/charge down weapons, what I would do is precompute the firing profile of a single burst with reference to the start of the burst, then do modular arithmetic to determine when the burst starts and execute the pre computed burst sequence at those times.

20

General Discussion / Re: Optimizing the Conquest: a Mathematical Model of Space Combat

« on: December 16, 2022, 12:53:55 PM »

IMO, return fire is a necessity if you want to consider shields/shield damage, and also if you want to evaluate loadouts as a whole. Raw damage output is not really that useful without the context of the rest of the loadout, ship and enemy. For instance, the Mjolnir and Gauss look great in your earlier results, because you don't consider flux at all. Both are very flux expensive and somewhat inefficient. IMO, those weapons are frequently unusable on smaller ships because of the flux cost, so I would say they are not top choices for the average ship.

To test a weapon, what I would want to do is something like:
Choose some set of ships and loadouts that you consider to be balanced, and test them against some 'reasonable' enemies to determine a baseline, then modify the loadouts to incorporate your new weapon, and see how the results compare. Just shooting a target dummy doesn't tell you enough to a balance a weapon IMO.

In a perfect world, I would want a mod which basically takes some input files to determine the ships and loadouts, and then runs the in-game combat simulator with no graphics and returns combat results (damage values, times, etc.). I view what we are doing as building towards something like that, but maybe it would be easier to just do that IDK. I don't have enough experience with JAVA to consider attempting that without investing way more time than I have.

Also, return fire is very trivial to add? It's all the same code as your own ships, so any bugs would also appear in your own ship. And as I mentioned earlier, the computational cost is really not that significant. I think your original code was just really slow/poorly optimized giving you a false impression of how expensive the computations are .

21

General Discussion / Re: Optimizing the Conquest: a Mathematical Model of Space Combat

« on: December 16, 2022, 08:39:34 AM »

FWIW, rotation state also changes the locations of armor cells, and changes which cells are visible, and the AI rotates the ship with this in mind as well. It's definitely pretty complicated. I think range is much simpler to handle.

If we are picking a fixed angle, we should just check which weapons can fire forward in the selected orientation and use those, rather than assuming all weapons can fire.

22

General Discussion / Re: Optimizing the Conquest: a Mathematical Model of Space Combat

« on: December 15, 2022, 09:23:19 PM »

Dealing with weapon arcs also requires dealing with the rotational state of the ships, which once again might require some rudimentary AI.

Also, when I say rudimentary AI, I mean some basic conditional rules, not like a whole complicated attempt to imitate the game. It could be as simple as 'fly forward if xyz flux conditions met, else fly backward' for range. I guess there's nothing wrong with also being able to handle fixed range, but IMO it's a pretty integral part of combat.

Rotations seem harder to deal with. I guess you could again choose a specific rotational state, but it seems quite complicated to make that user friendly.

23

General Discussion / Re: Optimizing the Conquest: a Mathematical Model of Space Combat

« on: December 15, 2022, 01:56:09 PM »

Thanks, interesting stuff! This is an area where I have relatively little to contribute unfortunately. But now that we basically have / are very close to having the code in Python, but with limitations in performance (see Liral's post - hence hunting for optimizations), do you have ideas about how to improve the strategy for testing, say, ship variants against each other, or a very large number of weapons versus a set of ships in order to rank them by some attribute?

I have ideas about ways of running numerical optimization on loadouts using some sort of combat model, but I think we are still quite far from having a simulation that is actually useful for that purpose.

In terms of performance, I think the issues are a little overstated. On my laptop (2019 Intel MacBook Pro, 2.3 GHz I9), my MATLAB code (which is not super optimized) takes about ~7 seconds to run the armor damage calculations 1000000 times (without any parallelization). My laptop has relatively unimpressive clock speed and 8 cores, so I would expect 3-6x reduction in time with parallelization based on personal experience. I would expect comparable performance (or better with good optimization) in python.

Based on my experience, most combat simulations take a few hundred shots for a kill, so that 1000000 armor damage calculations probably corresponds to 1-2 thousand combat simulations. I think that speed should be sufficient to run optimization code in a reasonable amount of time (several minutes). Obviously any improvements would be great though. Brute force searching all possible combinations of weapons/loadouts for a ship is still probably out of the question though just due to the combinatorics of how many possible ways there are to create a loadout. Obviously this is all very ‘back of the napkin’ approximations.

Here is my assessment of where we are and what we still need to do:

Current state (feel free to add anything I am missing):
in python:
- armor damage calculations (given hit strength and armor grid)
- expected armor damage (given shot distribution, hit strength and armor grid)
- some shot distribution calculations (given range, armor grid dimensions)
in R:
- more complex weapon mechanics (beams, charge up/charge down, burst weapons)
- some rudimentary AI for shield management
- a basic simulation

The remaining non-translated R code is mostly part of the broader simulation rather than the damage calculations. We still need to build out all the simulation code in python that calls the damage calculations.

In order to do numerical optimization, what we need is a function which takes all of the parameters to be optimized (loadout, hopefully including all weapons, hullmods, caps/vents), as well as the simulation parameters (ships, skills, opponent loadout etc.) and runs the simulation to return the value of the metric that we are trying to improve for that specific case. We will also likely need to write some constraint functions, but we can worry about that later.

What I think we need to do:
- translate remaining R code for weapon mechanics and stuff to python
    - this might require to some reformulation depending on how the simulation is implemented in python
- create a simulation structure in python
    - need to handle flux dynamics, including soft/hard flux from both firing weapons and shield damage
    - need to figure out time steps to handle all the different types of weapons (beams, burst weapons etc.)
    - IMO we need to handle variable range as well (will talk about this later)
- create a programatic system for getting appropriate weapons and ship data
    - I know Liral was trying to do this for weapons stats from the CSV file already
    - ship stats should be similar (parsing a CSV file), unless we try to handle actual ship geometry for the armor grid, and need to pull that data (which is not in a file format I am familiar with)
- choose a metric to optimize and create a function that utilizes the simulation to calculate that metric
- wrap this in the optimization code (probably from a generic optimization package, I can handle this)

Handling range is something I’ve been think about. Obviously, the big issue is that the shot distribution depends on range, and we don’t want to be recalculating that constantly, but I have some ideas when we get there. We would also need some rudimentary AI to manage range for each ship.

Also, I think we are definitely getting to the point where a GitHub would be very helpful for collaboration. I think the method of copy/pasting code from the forum will get very inefficient very fast. I am happy to write some code.

24

General Discussion / Re: Optimizing the Conquest: a Mathematical Model of Space Combat

« on: December 15, 2022, 10:50:31 AM »

We have been working with an armor grid that is essentially just a line of hittable cells with padding, but real ships aren't like that. They have corners and weird geometry which would ruin all this symmetry. We definitely don't want to bake in that really basic armor grid model and preclude actual ship models.

In terms of performance, matrix multiplication is an implicit inner loop over the elements of the matrix, so I don't think you are reducing the theoretical number of calculations by re-formulating in that way, just hiding them in a different operation. However, in python, it could very well be faster to do it that way because the linear algebra library is likely implemented very efficiently in a lower level language, while a high level loop in python is not. It's hard to say what will be best just looking at equations on paper.

There's lots of other fine details to speed in programming. For instance, memory is not free. It takes time to allocate and access memory, and sometimes, longer than to just do some extra calculations. Eliminating or pre-allocating temporary/intermediate variables is often a big performance booster.

Another non-intuitive one is that when dealing with multi-dimensional arrays, iterating over columns vs rows can result in different performance. This is because the data is actually stored in linear memory, so elements adjacent in the array are not necessarily adjacent in memory https://en.wikipedia.org/wiki/Row-_and_column-major_order. It's even more fun when you find out it is language dependent which way the data is stored. I'm pretty sure our arrays are going to be small enough for it to not make a huge difference though.

In my opinion, the best way to optimize code is to first write code that does what you want, then profile it to see what parts/functions/lines etc. are taking the most time, then find ways to improve those things.

25

Suggestions / Re: Eagle and (base) Falcon remain anemic

« on: December 12, 2022, 02:31:33 PM »

I don't mind asymmetrical game design. Let pathers have their own version that isn't available on other ships, or isn't available without ill-advised modifications.

I don't think removing it from cruisers really solves all the problems. My issue is that it just trivializes a lot of combat and loadout deisgn. Removing it from cruisers restricts that to more early/mid game, but it doesn't make the gameplay with SO any more interesting or enjoyable IMO.

The fact that you ignore it for balance discussions indicates that it is a major balance issue.

26

Suggestions / Re: Eagle and (base) Falcon remain anemic

« on: December 12, 2022, 09:57:34 AM »

I think you could just as easily point to cruiser SO (or SO in general) being the problem there

Amen. I hope more poeple catch on how broken and dumb of a hullmod it is, so it eventually gets either reworked or removed. It's not healthy for a discussion that someone goes "just put SO xD, it solves all problems". No it doesn't. And this goes for more ships than just Eagle.

I've campaigned repeatedly for SO to be nerfed/fixed/reworked lol, so you're preaching to choir with me.

I've gotten to the point where I just refuse to use it because it makes the game boring.

27

General Discussion / Re: The problem with the Radiant

« on: December 09, 2022, 06:32:42 AM »

I'm pretty sure I've suggested this before, but I've always felt like there should be a 'be careful' order you can give to ships that are overextending, or that you can see are going to be in danger soon. Like an inverse of search and destroy, making the AI behavior less agressive. Something a bit less extreme than 'avoid', but in the same vein (maybe lowering the flux thresholds for backing off, and changing behavior in terms of what range bands the ship is trying to get into).  I feel like that could help when fighting radiants too. I sometime have to toggle avoid repeatedly to keep ships safe until I can maneuver my fleet for a proper engagement with a radiant.

I don't want the radiant massively changed or nerfed though. I find it to be an interesting challenge to fight it.

28

Suggestions / Re: Weapon flux/sec gauge improvements

« on: December 09, 2022, 06:26:59 AM »

I feel like what you really care about is actually the total flux generated by a burst. Burst flux only matters as much as it fills your capacity.

29

Suggestions / Re: Eagle and (base) Falcon remain anemic

« on: December 09, 2022, 06:24:16 AM »

You could always just make the large ballistic a hardpoint. I like the idea of having a large mount on the eagle though.

30

General Discussion / Re: Optimizing the Conquest: a Mathematical Model of Space Combat

« on: December 08, 2022, 10:11:33 PM »

A couple thoughts on the structure of the code:

Instead of having target class, call it a 'ship' class, and potentially allow it to have info about weapons and flux as well as defenses. I think a very important aspect of a good simulation is that it should be symmetric (i.e. simulating both the friendly and enemy ships shooting and getting shot). The shield dynamics cannot be effectively simulated without considering both ships firing and getting hit.

Also, personally, I would not have a separate 'expected damage' class. I would wrap that all up as methods in the armor grid class.

Like hector said, the shot class also is not capable of handling beams. You also need a hull damage value for the shot, which is really a base damage value.

You also need to deal with hull damage somewhere. I might do it as methods in the ship class, but I think you will need to add some stuff to the armor class to deal with overkill damage to armor (when incoming damage exceeds remaining armor in a certain cell the overkill gets dealt to hull) and residual armor. Idk what the easiest way to handle it is.