|
Post by omnipotentvoid on Apr 10, 2017 14:31:37 GMT
some weapons are not designed to do the most damage over the largest area, some weapons have diffferent goals for which they are very effective, also aside from projetile impulse, impact energy conversion ratios, and effectivity/eficiency metric, all of these stats are in game. What is listed in game are statistics. A metric would take these as inputs and output a number. As for the different goals: all weapons (not just in CoaDE) are designed to do the same thing. Essentially weapons attempt to disrupt the structure of a target to the point it becomes none functional. A weapons ability to do this depends on the properties listed in 2.3 and properties derived from them. This can never be a perfect representation of a weapons ability (since this relies on tactical situation and target as well) but it should be adequate given a limitation on certain parameters. This is what I meant when I said that there is no natural metric. In other words: given a set of weapons with certain constraints (mass, energy use, limited space) these metrics should be fairly good at determining which is best. also velocity over time is useless, there is no drag to slow shots down and Dv is sufficent for missiles/drones This metric would be usable independently of any game, even in reality. I'm doing this in CoaDE because I can easily test the weapons and have easy access to the statistics I require as inputs.
|
|
|
Post by omnipotentvoid on Apr 10, 2017 12:18:29 GMT
1. Intro (pseudo abstract): Over the past couple of years, I have played quite a few games that implement vehicle construction (most notable CoaDE, From the Depths, KSP with BDArmory and Gmod with the ACF addon). One of the major problem in these games(/mods) is figuring out how effective or efficient a specific weapon is. There is no natural metric for either of these properties, nor is there any easy metric that gives any reasonable measurement of either. My goal is to create metrics for both properties that is both reasonably easy to use (read: make a spreadsheet where variables are plugged in and an answer pops out) and reasonable accurate (read: if one weapon is better than an other as per the metric, it will perform better in that category in most situations than the other weapon). The distinction between efficiency and effectivity, in this case, is (essentially) that effectivity is per encounter/engagement and efficiency stretches multiple encounters/engagements. As an example: a coilgun that accelerates kg scale projectiles to ~75% of c at an energy efficiency of ~40%. This weapon is fairly effective: capable of destroying almost all opponents in a single hit, hard to dodge due to high projectile velocity, energy and mass efficient and near impossible to intercept. It is also extremely inefficient: the mass of the weapon means it requires immense amounts of fuel to move and retarget. It is also slow to target making it hard to switch between targets that approach from different directions. Etc. These metrics must take into account properties that can be (and traditionally are) split into three categories: - Internal Ballistics
- External Ballistics
- Terminal Ballistics
Note: Ballistics as used here refers to the properties that the projectile has in explosively propelled projectile weapons and in the case of internal ballistic also some properties of the weapon. From here on I will use these to refer to both weapon an "projectile" (this includes laser beams and missiles) properties, simply because I have become used to using these terms.
2. The Categories/Properties As discussed in the intro, the properties, these metrics must be derived from, can be split into three major categories as shown below. Properties derived from stated properties are not listed (will list them if enough people request it and the properties are subject to change): 2.1 Internal Ballistics These are the properties of the weapon an projectile as the weapon is fired/targeted/moved.
- weapon mass
- weapon dimensions
- static power use
- active power use
- energy used to fire projectile
- projectile mass
- projectile dimensions
- exit velocity
- projectile impulse
- projectile energy
- effectivity/efficiency metric of warhead(/shrapnel)
- waste heat produced
- fire rate
note: a warhead is counted as its own weapon and its efficiency/effectivity effect the metric of the weapon that uses it. The same is true for shrapnel created by explosives: the count as "weapons fired by the warhead".
2.2 External Ballistics These are the properties of the projectile and weapon that describe targeting/accuracy and flight of the projectile. - Velocity over time
- Dv
- thrust
- rotational ability
- weapon dispersion
- projectile/energy dispersion (laser, radiation(nukes) and multi projectile weapons such as shotguns/frag warheads)
2.3 Terminal Ballistics
These are the properties that determine what happens when the projectile hits (basically damage). - projectile dimensions
- distribution of energy across target
- projectile mass
- projectile energy
- projectile impulse
- projectile velocity
- impact energy conversion ratios
note: projectile mass and dimension only applies to kinetic projectiles. Laser, radiation and blast damage are based of the distribution of energy across target.
This is more or less as far as I've gotten. I have started on working out the interaction of the properties in the terminal ballistics part of the metric for effectivity and will post it as soon as I consider it presentable. I feel fairly confident in figuring out how these properties interact, but am currently at a loss as to how to express this in term of numbers. Any help is appreciated.
|
|
|
Post by omnipotentvoid on Mar 10, 2017 17:56:11 GMT
Actually, negative kelvin temperatures are a thing. Only 0K is impossible. Negative kelvin temperatures basically means that there are more particles in a higher energy quantum state than in lower ones. As such negative kelvin temperatures are hotter than any positive kelvin temperature, as heat will always flow from the -K object to the +K object. Yes, but qswitched has mentioned before that negative temperatures on reactors are a bug. I know its a bug. Adding negative kelvin temperatures would imply an ability to specifically control quantum states of particles on a large scale. That's a technology that is far more than 200 years away.
|
|
|
Post by omnipotentvoid on Mar 10, 2017 14:06:59 GMT
wait -16000K? that doesn't make sense! Nothing bugged will make any sense. Actually, negative kelvin temperatures are a thing. Only 0K is impossible. Negative kelvin temperatures basically means that there are more particles in a higher energy quantum state than in lower ones. As such negative kelvin temperatures are hotter than any positive kelvin temperature, as heat will always flow from the -K object to the +K object.
|
|
|
Post by omnipotentvoid on Mar 10, 2017 9:56:47 GMT
Even without armour, the 111mJ cap can heat a little more than a ton of ZrCu to about 1500K. Thats still way more energy gain than was possible with the old coilguns. You are correct (though the screenshot and some math would suggest about 141kg of copper, but still much more than should be affected by 0.1J). Hmm, perhaps the game is modeling it in parallel with the power input (as a constant power source)? If that is correct lets see: 50m * 2 / 1.28m/s ~= 80s to exit the barrel, correct? 80s * 100W = 8kJ of heat in 141kg of copper -> 0.15 K rise, no, that isn't right either. Yea, you definitely found something weird. It seems to have something to do with capacitor dimensions. Some width/height ratios can produce <100% efficient coilguns as well, heating them to about -16000K.
|
|
|
Post by omnipotentvoid on Mar 9, 2017 19:15:24 GMT
First of all: capacitors don't heat up, it's the barrels that heat up. This is confirmed by the fact that increasing barrel radius/armour on a railgun decreases heat jump temperature. This means capacitors are likely more broken than coilguns were before. See image below: Basically, a capacitor with a total electric energy of 111mJ is heating 217 tons of zirconium copper by 2108K. With a heat capacity of 385 J/Kg K, that should take about 176GJ, making that little cap roughly 160000000000000% efficient at heating up the railgun. It takes over 300t (at least) of zirconium copper before the railgun does not heat up at all. Secondly: here's a graph I made to show how coilguns don't accelerate as they should: In the constant acceleration curve, the acceleration the armature experiences is the same in each coil (50000 m/s^2 with 1 m long stages in this case). In the decreasing acceleration curve the first stage is identical to the first constant acceleration stage, each stage following that loses 1/3*Pa*exp(-(Stg-2)) in acceleration, where Pa the acceleration of the previous stage and Stg is the stage number. This way the second stage loses about 1/3 of its acceleration and following stages lose less and less. This is only a rough approximation, because in game adding a stage decreases the acceleration of all stages, but it roughly shows the effect that decreasing acceleration of individual stages has on velocity. To go back to my point: there is, as far as I'm aware, no reason why multiple stages should decrease the acceleration on an armature in a coilgun. If each capacitor/coil pair is on its own circuit, the magnetic field, and thus the acceleration should be the same. Going to take a guess and say the barrel (which is 1cm thick) is heated by 2000K while the barrel armor is not. If the whole barrel heats up in usage on the first shot, then you found a bug. Even without armour, the 111mJ cap can heat a little more than a ton of ZrCu to about 1500K. Thats still way more energy gain than was possible with the old coilguns.
|
|
|
Post by omnipotentvoid on Mar 2, 2017 20:37:18 GMT
First of all: capacitors don't heat up, it's the barrels that heat up. This is confirmed by the fact that increasing barrel radius/armour on a railgun decreases heat jump temperature. This means capacitors are likely more broken than coilguns were before. See image below: Basically, a capacitor with a total electric energy of 111mJ is heating 217 tons of zirconium copper by 2108K. With a heat capacity of 385 J/Kg K, that should take about 176GJ, making that little cap roughly 160000000000000% efficient at heating up the railgun. It takes over 300t (at least) of zirconium copper before the railgun does not heat up at all. Secondly: here's a graph I made to show how coilguns don't accelerate as they should: In the constant acceleration curve, the acceleration the armature experiences is the same in each coil (50000 m/s^2 with 1 m long stages in this case). In the decreasing acceleration curve the first stage is identical to the first constant acceleration stage, each stage following that loses 1/3*Pa*exp(-(Stg-2)) in acceleration, where Pa the acceleration of the previous stage and Stg is the stage number. This way the second stage loses about 1/3 of its acceleration and following stages lose less and less. This is only a rough approximation, because in game adding a stage decreases the acceleration of all stages, but it roughly shows the effect that decreasing acceleration of individual stages has on velocity. To go back to my point: there is, as far as I'm aware, no reason why multiple stages should decrease the acceleration on an armature in a coilgun. If each capacitor/coil pair is on its own circuit, the magnetic field, and thus the acceleration should be the same.
|
|
|
Post by omnipotentvoid on Mar 2, 2017 18:50:33 GMT
No you are not. Though there is little benefit seen with large numbers of stages. You can have up to 100, pointless as that is. But why is it pointless? There is no reason for acceleration to decrease across the board when adding new stages the way it does. Each capacitor-coil pair should fire independently, acting like an individual gun. Velocity gain would decrease as the projectile is already moving faster when it enters and some acceleration is lost due to increased resistance due to increased wire length (this is negligible unless the gun is very long), but acceleration should not drop as much.
|
|
|
Post by omnipotentvoid on Mar 2, 2017 17:21:08 GMT
the reason why upping the power input on a capacitor weapon has no affect on muzzle velocity is because that is how much power you are feeding the capacitor, bigger capacitor = faster shots. also voltage is how much force the electricity is pumped with I'm not talking about upping power input. I'm talking about adding capacitors and barely getting any increase in velocity. As far as I can tell, adding a stage, and thus a capacitor, to a coilgun reduces the average acceleration across the entire coil by about 1/3. There is no reason for this as far as I can tell. Adding stages does have diminishing returns, as the armature spends less time in each coil, but if each coil has its own capacitor there is no reason for over all acceleration to decrease.
|
|
|
Post by omnipotentvoid on Mar 2, 2017 15:34:45 GMT
The way capacitors work seems incredibly obscure. For a start, why does changing the voltage have so little an effect on the performance of coil/railguns? From what I can see there must be some regulatory system behind them, because normally, even slight changes to the voltage have large effects on a railgun (I can say for sure) and probably a coilgun as well. Beyond that, what kind of caps are these? I assume they're ceramic caps from the ceramics included? Without knowing how the capacitors work, designing one in game is just sliding a bunch of sliders around arbitrarily
Then, either the caps breaking from overheating throws the "Barrel shatters from thermal expansion" warning, or capacitors can put out a physics breaking amount of energy. Capacistiors obviously overheat, the game even tells you that you should check if the radiators are extended if they do, yet there are (as far as I can tell) no radiators for capacitors. Further more, coilguns don't seem to benefit much from additional stages, despite the average acceleration being the same when adding stages and thus increasing the acceleration time. This is exaggerated by the fact that each stage of the coilgun being fired in exactly the same way, despite the fact that the armature spends less time in each stage as it accelerates.
|
|
|
Post by omnipotentvoid on Feb 22, 2017 11:36:11 GMT
Personally, when I play the game, I listen to things like:
or this (if I'm feeling slightly more aggressive):
|
|
|
SIM
Feb 22, 2017 11:25:46 GMT
Post by omnipotentvoid on Feb 22, 2017 11:25:46 GMT
I was under the impression that once created EDM was metastable outside a white dwarf. I'm not actually sure what EDM would do. Probably depends what kind of EDM you have. The stuff in white dwarfs is EDM with a bunch of positive C and O ions stuck in it, which sort of makes it solid. Pure EDM would probably behave very differently. I'm pretty sure that pure EDM would just rip itself apart due to being a bunch of negatively charged particles stuck really close together. As for white dwarfs, I imagine that the electrons would just recombine with the positive ions, releasing a bunch of energy in the process. Not sure though, quantum mechanics starts dominating at these densities and EDM may sort of act like a single quantum object making it sort of stable.
|
|
|
Post by omnipotentvoid on Feb 19, 2017 9:06:24 GMT
You're confusing something with an optimized parameter given set of constraints with tactically optional. Nowhere have I argued that players shouldn't be allowed to make their own tradeoffs. What I have advocated for is reducing design to meaningful choices. The RP-1 to Methane spectrum is a meaningful tradeoff. Many, if not most, of the remaining propellants are not, because they deliver less dV and thrust for more volume and cost. So why make them an option at all? It's a noob trap. In a quest for realism, we could force people to design their own radar signals processing circuits and algorithms. But the end result wouldn't be any more realistic than if you just let people pick a radar band, aperture size, power, etc. You want to do "realistic" data links? Fine, you can go figure out a fair time and spectrum sharing scheme for multiple simultaneous distributed users, crypto algorithms to prevent eavesdropping, handshake protocols, network routing, digital massage encoding formats, etc. I'm just going to assume the narrowbeam laser data link works so I don't get stuck staring at a tree instead of seeing the whole forest. This is my point, we don't know what is "tactically optional" and what choices are meaningful in any given situation. It is tempting to say that all choices that don't lead to the optimization of what we consider are the most important characteristics are irrelevant. However we don't know what characteristics are relevant in any particular situation. As newageofpower pointed out, we may want or need to optimize for material use. Lack of manpower may also be taken into account. Depending on the situation, some weapon types may not be an option. Etc. This isn't well represented in the game, because all user designs are rather unlimited in this regard. They are all set up in such a way that technically optimizing weapons is enough to win them easily. So all most people do is technically optimize their designs. The Liberty assault cutter design challenge by Easy is a pretty good indication of how ships would be designed in reality. In any case, challenges where tactical expertise is required to win, rather than technical expertise would be extremely difficult for people used to the current meta and would probably take weeks for someone to beat on their own unless they know a lot about tactics.
|
|
|
Post by omnipotentvoid on Feb 18, 2017 19:42:50 GMT
I strongly disagree. This game is about uncovering what realistic space combat would actually be like. For that, we need as many options and detail as possible, as conventional wisdom gets overturned every update or so. Simplifying something for the sake of simplifying would do this injustice. How would you even determine how effective a sensor would be without going into detail? Just look at how varied coilguns and railguns are. Could you simulate these in the way you propose? Determining what is optimal for a given situation is one of the core principals of the game. Detection and tracking (and even communication) are too important to oversimplify or abstract away. The importance of these becomes clear when observing current military hardware and the emphasis on awareness and communication, from AWACS to Global Hawks to tiny quadcopters. Just look at current day thanks and how loaded they are with sensors and comm gear! Assumptions are already being made. It's assumed that designs with no safety factor don't suddenly fail from fatigue, it's assumed that radiator efficiency doesn't depend on how close they are to the heat source, it's assumed drone and missile guidance can't be jammed, etc. All models are wrong but some are useful. There's a lot of variety, but for any given bore size, payload, power, barrel material combination there's an optimal railgun for barrel velocity, range to hit a 1m^2 target, lowest cost, etc. Things have to be and are already being simplified in order to run real-time on a PC. In the game there may be optimal solutions, but in reality these are all suboptimal. Additionally, optimal is a relative term. I've pointed out multiple times, for instance, that the weight that is optimal for kinetic energy weapons depends on the specific tactical situation. In fact I've done tests that confirm it. This kind of non trivial situational optimum is a step of "impossible to calculate" above the standard "physics is impossible to accurately simulate". Any assumptions we make on a physical level may have extreme impact on effectiveness of systems and ships in combat that we can not predict. Of all the assumptions currently being made in the game, the one on sensory systems is the most extreme. Information is the most important thing in combat. And of all the systems implemented into the game, informational systems are the most rudimentary. This means that the ships and weapons we use may be viable, but they would likely never exist in reality. The limitations on tactics and strategy imposed by the lack of sensory equipment means that the situations currently portrayed in the game would never happen. Much of the game is focused on the science behind space combat and the majority of the expertise behind the community and (I'm making an assumption here) the developers qswitched is technical not tactical. This is important because, while technology dictates what tactics are available and to some extent the effectiveness of said tactics, tactics dictate what technology is used and how effective that technology is in combat.
|
|
|
Post by omnipotentvoid on Feb 18, 2017 12:55:01 GMT
Is the math for magnetic field generated by different rail geometry available though? If possible, it would be nice if we can change the shape of the rail for optimization to several sets of shape. It's readily available : en.wikipedia.org/wiki/Biot%E2%80%93Savart_lawlinkIt becomes extremely complex for none trivial geometry though, especially because a railgun is a dynamic system, where the geometry effectively changes as the projectile moves along the rails. The only way to implement more complex geometry is probably select a few simple geometries and derive the formula of the magnetic field based on a few simple factors like length and width at certain points using the Biot Savart law. These formulas could be integrated into the game fairly easily, deriving the formulas could be very difficult though and might require some rather tedious simulation. Does anyone know if the projectiles are assumed discs? Most rail armatures are actually pretty thick rectangles/squares with a parabolic cutout in the rear. It would seem to me that this would allow for more acceleration, since the magnetic field, and thus the force applied to the projectile, is strongest close to the rails. These shaped armatures would thus be able to accelerate much faster without shattering, cutting down on barrel length or increasing muzzle velocity. It may be more efficient as well as far as I remember. Reference image: Source: www.google.com/patents/US8132562
|
|