Quick post while I'm (notionally) at lunch...
Ender wrote:A few points I've noted so far - you don't allow for different weapon types for different ships among ranks. For example, an Victory class Star Destroyer has Heavy Turbolsers as its primary weapon, ion cannons as its secondary weapons, and missiles as its tertiary weapons.
That's just a GUI limitation, caused by the fact I wanted to cram the interface onto one page. The fields are interpreted correctly for split weapon types, but only the labels for the last weapon type selected
are shown (I mention this in the notes, but yeah). I'll get it working as it is properly, and if people actually start using it I'll consider split the interface into multiple tabs, fixing this and allowing arbitrary numbers of weapons.
You also do not allow for what can basically be considered an infinite amount of shots - my lasers draw upon the main reactor, so as long as I have fuel I can fire.
Leave 'ammunition carried' blank, or set it to zero, and infinite shots are assumed. I'm not modelling heat build-up or reactor fuel as (a) it didn't seem worthwhile for a single engagement and (b) canon evidence would for the figures would be more or less impossible to find. But again they would be easy to add on later if anyone wants them.
While the shot limit works for missiles and KKVs, it doesn't work for lasers and it is less helpful for particle beams (I guess you could go offtank volume and density, but depending on your range and shot density its going to vary way too much).
For particle beams, I'd just assume max power shots all the time; I'm not clear why particle volume would vary with range.
You aren't very clear there, but do you account for the different physics various weapons will operate under? 100 kt from a laser will be very different from a 100 kt nuke
Beam weapons are modelled as localised radiative heating. Kinetic weapons are modelled as localised instantaneous heating that also forces melted armour out of the way (and are not vulnerable to vapor masking). Missiles are modelled as explosions with a spherical radiation pattern with no kinetic component. A better model of missile impacts might be nice, but I don't think most television sci-fi scenarios really need it: we don't see relativistic impactors. I'd love to put in Schlock style gravy guns, but I have no clear idea of how to model them.
which is no where close to a KKV with 100 kt worth of KE behind it - heck the KKV will react different depending on its varying velocity and mass for all the possible values to equal that enery.
Right now you have to decide if your weapon damages primarily by KE or primarily by contact explosion. But I suppose a short term fix would be to make missile impacts explode then also count as a kinetic hit using their 'effective combat speed' and a mass guesstimate based on their cross-sectional area. I'll do that tonight in fact. Stuff like shaped-charge and MIRVed warheads will have to wait for a future version.
You also don't account for range, or weapon velocity. HIMS Imperator can target and hit the TCS Galactica from further then the reverse can, meaning it will take a lot more shots.
No, mainly because allowing full use of weapon ranges generally results in hopelessly one-sided fights (as would full use of FTL - there's no reason an ISD would sit there and be pounded into scrap by several thousand GCS if it had a working hyperdrive). I'm certainly accounting for accuracy
dropoff over range (that's what 'angular error probable' is for, past a
certain range your ship be able to hit anything) but I'm not modelling damage dropoff, beam blooming or missile fuel. Maybe later. In the mean time, this is for First Contact and Return of the Jedi style close-range brawls.
In keeping with this, you would need to factor in acceleration (linear and rotational),
I confess that I'm modelling ships as flying around like aircraft (constant speed smoothly changing heading). Mainly because that's what we see on screen in both of my above examples. Acceleration would be nice, but I'm on a strict complexity budget for the first version and I didn't think it'd make much real difference to the results.
sensors (both resolution and speed - FTL sensors usher in a whole new ballgame when it comes to combat).
Suffers from two problems; lack of canon evidence for exact sensor capabilities, and the tendency to make battles hopelessly one-sided if utilised to the maximum extent. This applet is really designed for close range First Contact style slugfests where sensors are not a limitation (I'm also assuming all ships have adequate fire control to individually target all their weapons at their maximum refire rate, with slew rate being the main limitation on target acquisition). Certainly I'm not going to model sensor propagation speeds, as that would dramatically increase complexity. I might put in a simple ECM/ECCM/target acquisition model in some later version, but again canon evidence for filling in the figures is going to be nearly impossible to find. Cloaking devices should be fairly simple though, I'll put those in in the second version.
I see you have combat speed, but you are thinking in Earth terms too much - yes, speed matters for the USS Truman, but for the EAS Omega acceleration and velocity are what matters (and yes, the distinction between speed and velocity is critical here).
I've written proper physics engines in the past, so I'm hardly a stranger to doing accurate zero-g physics modelling (not that most gamers want it). But again, for the universes I'm initially interested in, ships really do seem to fly around like aircraft when they get into close-range battles. Shouldn't be too hard to implement though, mostly it just needs different AI, I'll put a 'use Newtonian/B5/sane physics' checkbox in v2.
If I know the Omega is traveling a 12 km/s I can predict where it will be when my shots hit and thus target it from further away. But if it accelerates or alters its vector at all, I will have no idea where it will be beyond a vague probability box.
This part is modelled correctly. Incidentally the Destiny Star engine actually used explicit algorithmic representations of future trajectory probability cones to determine things like the object's positional update priority, gravity correction interval and trajectory intersect test (collision detection) interval.
Shield burnthrough should be a measure of intensity rather then energy.
I wasn't sure which to go for myself. For turbolaser bolts and kinetic impactors, the duration is so short that it's essentially an instantaneous lump of energy; the shield won't be able to reradiate a significant amount of energy or shift loading between emitters while the shot is in progress. But phaser bursts are long enough that power rating matters. I'm fudging this for now, assuming that beam times are 20% of the total cycle time but that KE impactors are instantaneous.
This ties into your weapons stars - either enter a disclaimer of a presumed intensity, or stick in a hell of a lot more options there.
I'll go with 'disclaimer' for now. 'More options' hopefully later.
You lack any options for point defense, you might want to include that in later versions.
Point defence is modelled, I just have the ships do an expected utility calculation to check if incoming projectiles are worth shooting at. What else do you want, the ability to dedicate or exclude certain weapons from point defence duty?
Frankly, the ability to use this for a sci-fi vs debate will be limited due to the sheer number of variables.
Logically speaking, this can't be any worse than the usual 'how many ships do you think it would take to beat x?' poll and following mass of semirigorous or nonrigorous specification, or the debates which hop from examining one special case to another without ever looking at the overall (tactical) picture. But yeah, in practice a lot of people will just see all the fields and say 'where the hell are you getting all these numbers from'.
Good point, I'll send them an email when the first version is done, though better wait until I have a 'use Newtonian mechanics' checkbox or I'll be flame grilled.
In fact, should you grow bored with this I would be interested in a copy of the code so I could do a downloadable Excel version of this.
Sadly there's no way this level of modelling will work as an Excel sheet - if it was that simple I would've done it in Javascript and avoided the annoyances of using applets. You could port it to VB, but that has the usual security issues of downloading untrusted VB code off the Internet, which applets specifically avoid.
P.S. Back when I was lurking on this board, I recall reading Stark's posts and thinking 'wow, I bet it's hard to even agree with that guy without him trying to argue with you'. But actually he seems fine, just a 'glass half-empty' kind of personality, at least his posts are all intelligent and not childishly spiteful the way a few other regulars are. If I had a problem with criticism I wouldn't have signed up to this BBS.
.
