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.

1

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

« on: January 17, 2023, 12:44:05 AM »

I am not saying doing things in the ship-fixed frame is inherently wrong, and I understand how to do it that way, I just don't see why you wouldn't do it in a stationary frame. If you ever want to do stuff like model shots as projectiles with travel time, or consider dynamic motion of ships during combat, using a rotation frame results in stuff like non-accelerating (moving in a straight line) projectiles following a curved path in your coordinate system if your ship is rotating. And it certainly seems like it would be more complicated computationally and unintuitive to have to update the states of every other object in the simulation whenever your own ship moves, rather than just updating the state of your ship.

The way I would do it is just make the ship class have x,y coordinates and an angle/orientation (defined wrt a stationary frame). Then the vector between ships is just the difference in their position coordinates, and the direction of a weapon arc center is just the the angle between it and 'forward' on the ship plus the rotation angle of the ship (and you can get a unit vector from that easily). That's all very simple, and extends naturally to having ships moving around, or having projectiles modeled etc.

2

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

« on: January 16, 2023, 02:08:13 PM »

Isn't general relativity just about gravity and replaces newtons law of gravity? Not all of newtons laws. Like there is definitely a relativistic version of F=ma but I'm pretty sure it still requires a non-accelerating frame... I just asked my dad who taught physics and he agreed with that.

But this is all completely beside the point lmao. All I was saying is that everything in engineering is done in inertial frames because classical mechanics requires it, and no one is wasting their time with relativity unless they need it. Very few things reach a non-trivial fraction of c where relativity would be relevant.

3

Suggestions / Re: Poison gameplay loop; (by design)

« on: January 16, 2023, 11:40:02 AM »

4-5% on both damage done and damage received is a pretty large boost in terms of winning the flux war.

On a related note, I know some people who had an officer in their flagship to give CR and missile ammo, and then they would swap their character in at the start of battle and keep those bonuses without having the the skills which is a closely related cheese strat. I agree with OP that it's an annoying feature of the game.

I feel like the most effective fix would be somehow restricting officer swapping, like making it take time to gain the benefits of skills after swapping in, or making it impossible to swap officers unless you are in port or something.

I'm definitely against removing combat endurance from support doctrine though. I think it really benefits/incentivizes the use of frigates and destroyers due to the PPT bonus as well.

4

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

« on: January 16, 2023, 08:42:30 AM »

Wait, aren't all physical laws independent of frame of reference?

The only university level physics I have is a course on relativity and reading about convolutions from a mathematical physics book so I genuinely have no idea about this stuff.

Newtons laws are definitely not. I never had to learn relativity, but according to the wikipedia page (https://en.wikipedia.org/wiki/Special_relativity) it's also only true in inertial (non-accelerating) frames. Doing simple classical mechanics (F=ma) in a moving (accelerating) frame results in fictitious forces (for example coriolis forces on earth).

It's easy to see how this is true, even in our little example here. If our ship is rotating and the target is stationary and has mass (m=/=0), then in our ship-fixed frame, the target can be accelerating (a=/=0) despite there being no forces acting on the target (F=0), so clearly F =/= ma in that frame.

5

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

« on: January 15, 2023, 10:44:28 PM »

It's way more intuitive to me to work in global (inertial) coordinates. That way rotating my ship causes my weapons to point in a different direction, and the target does not move, whereas working in ship-fixed coordinates means when I rotate my ship, the target (and every other object) moves and my weapons stay stationary. It just seems silly to do things so that every time my ship rotates or moves, I have to update the position/orientation of every other object instead of just the state of my own ship and weapons. Particularly if you ever want to consider more than one ship.

But I guess being an engineer, I am just used to working in inertial (global) coordinates since that is where the relevant laws of physics are defined.

6

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

« on: January 15, 2023, 10:07:29 PM »

In the actual game, the positions of the ships are all known with respect to some global coordinate system which does not rotate or move with our ship (x,y coordinates on a grid fixed to the map). The weapon arcs are (presumably) known with respect to a coordinate system attached to your ship (angle with respect to the front of the ship or something). If you rotate your ship, the weapon arc moves with it (in the global coordinate system), but the direction to the target does not change. Or if you want to view it from your ship-fixed coordinate system, the vector to the (static) enemy moves when you rotate your ship but the weapon arc is fixed in that coordinate system.

If you are dealing with a completely static case, you could do stuff in a coordinate system attached to your own ship and just figure out what direction you want the target to be in relative to your ship at the start, but if your ship ever moves or rotates, that appears like your target moving in the ship-fixed coordinate system, and you would have to account for that, so it makes things much more difficult/complicated that just doing everything in a global coordinate system where the motions of the ships are independant.

It's also really not complicated math, so it seems like an easy thing to do that allows for more complex simulations in the future.

7

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

« on: January 15, 2023, 08:33:05 PM »

Ship weapon slots are given as midpoint and arc, so no need to worry about that. So long as you know the unit vector in the direction of the enemy ship (or alternatively range to enemy ship and vector to enemy ship to calculate it) this is usable.

Presumably the weapons arcs are known with respect to the ship, which can rotate, while the positions of things are known in the global frame of reference. So you still need to get the vectors into a common coordinate system (accounting for the firing ships rotational state) before you can take the dot product.

8

Suggestions / Re: What could be done with Safety Overrides

« on: January 15, 2023, 05:06:56 PM »

I have been campaigning for SO nerfs for a while, so I definitely agree, but I'm curious where Alex has addressed it/said it needs to change. Can someone link that discussion?

9

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

« on: January 15, 2023, 04:59:34 PM »

Also, the vector between ships is just the difference between the position vectors of the ships, and the magnitude of that difference vector is the range. So if you represent ship positions somewhere in the code (even if it is just static), that makes the calculations pretty trivial, and also sets up for considering movement in the future if we ever want to do that.

The vector pointing along the center of the weapon arc should also not be too complicated. I'm not sure how weapon arcs/mounts are defined in the simulation (or in the ship files), but if you know the angle to a vector from your coordinate system x axis, the corresponding unit vector is just [cos(angle) sin(angle)]. In general, you should be able to pre-define the weapon arc vector relative to a ship-fixed coordinate system, and then use the ship facing angle to rotate the vector into the global coordinate system (where the position vectors of the ships are defined) so that you can compute the dot product.

10

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

« on: January 15, 2023, 12:18:01 AM »

Personally I would want to be using dot products of vectors to find angles between things. For instance, the dot product between the vector pointing from our ship to the target, and the vector pointing along the center of the weapon arc is equal to the cosine of the angle between those vectors, and if that angle is greater than 1/2 the weapon arc, then the target is not in the weapon arc. The definition of arccos where the domain is limited avoids all the 'wrap around' issues.

11

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

« on: January 09, 2023, 06:12:58 PM »

I was thinking about a bit more of a sophisticated simulation code structure than just a script with all the info hard coded. Something like a simulation object that contains all of the necessary info and has a 'run simulation' method, and things like 'add_ship' and 'set_loadout' methods etc.

My only concern is that that could add some overhead if you needed to run lots of simulations.

Also, yay GitHub!

12

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

« on: January 09, 2023, 11:07:02 AM »

The big secret is that many things considered 'AI' are just big lists of rules. (The rest of the things considered 'AI' are just fancy curve fitting of data ).

The hard part is having the right rules to get the results you want. If you are happy to accept very simple rules and corresponding results, it's really not that complicated. In this case, I think some very simple rules can give 'good enough' results.

Also there should absolutely be a centralized GitHub to coordinate stuff. I've said this before, but I'm happy to contribute more code, I just don't want to be worrying about trying to coordinate my code with other peoples code in different languages, and I don't want to have to write redundant code to test things on my end and then change everything in order to fit that code into other structures.

13

General Discussion / Re: I don't like the idea of build-in hull mods debuffs

« on: January 09, 2023, 10:56:44 AM »

I've always wanted to have a stripped down executable version of the combat sim (no visuals, not time-constrained i.e. runs as fast as it can compute), where you can just input some ships/loadouts and get results (time to complete, damage dealt by each weapon, final hull/armor states etc., could have more advanced results like time series as well). That would make large scale testing a lot easier IMO. You pick a set of 'standard' ships and loadouts that you want as a baseline to balance around, and then run a bunch of sims with the new/updated ships/weapons against the baseline and see if things are over/underperforming.

Obviously it wouldn't be a 'hit button to test everything' solution. You still have to determine what the results should be if things are balanced, and you would still want to do normal testing in the sim to visually diagnose issues you find, but it seems like it would be a time-efficient first pass for balancing, and very useful for a whole host of other things as well. The current system of running the combat sim (or a fulls scale combat in-game) manually over and over seems horribly inefficient.

14

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

« on: January 04, 2023, 01:34:50 PM »

I haven't been following closely for a week or two because I've been busy with other things. Is all of this just to figure out what rotational orientation to put the ship in so that the most weapons/DPS are available?

I'm seeing stuff about random rotational states... that seems highly unnecessary.

If you want to get super detailed modeling rotational states, you can just copy the algorithm the game uses. Other than that, a fixed rotation state based on the loadout to maximize DPS or weapons points or whatever seems both relatively easy and reasonably realistic.

Also, I feel like for any ship with hardpoints (which is a large fraction of them), it's all pretty trivial anyway.

15

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.