StarDestroyer.Net BBS

Not sure if this should go here or in Testing.

I spent this evening whipping up a little program to support a versus thread I plan to start, but it's sufficiently generic that it should be useful for other sci-fi versus arguments too. It's an applet that simulates a simple fleet engagement; one or more defenders clustered in the centre, with a loose shell of attackers flying around trying to take them out. I was thinking of the borg cube versus Fed fleet battle from First Contact when I visualised it, but starfighters versus most cap ships or the Executor-class versus Borg cubes battle in Wong's fanfic fit the bill. The whole project was actually inspired by the scene in 'Conquest' where the defeated Fed commander says 'we've worked out some strategies for use if we engage (the Imperials) with equal numbers' - I felt compelled to work out exactly what flavour of crack that Feddie was smoking.

Anyway, you can take a look here, but the main code's not done so it's just the GUI and field descriptions (there are a little over 100 ship definition fields ATM). If it doesn't load you probably need to turn on Java and/or update your plugin. I'd appreciate it if people could;
* Check my basic assumptions are reasonable.
* Suggest any easy realism/feature improvements, before I finalise some of the more complex stuff.
* Suggest values for the initial ship templates; particularly the Galaxy Class and ISD, and to a lesser extent the Executor, Sovereign, X-Wing and tactical cube.

Stuff I've already though of adding;
* Wall of battle style fleet engagements - probably needs more AI than I have time to put in given the limited time available for to this project.
* Fancy GUI - waste of (limited) time. I'll put the source code up if anyone else wants to do it.
* Tractor beams - not sure how to model these (and the necessary controlling AI).
* Mines - no canon evidence for tactical use in any of the major franchises.
* Warp strafing - ditto but moreso.
* Weapon damage dropoff with range - relatively useful, but I'd have to make the interface tabbed and generally more complicated.
* Shuttles and parasite fighters - ditto.
* Complex shield modelling (particularly interaction with various weapon types) - generally the canon evidence isn't there to do this with a useful accuracy.
* Semi-accurate armour spalling - plus generally treating KE separately from other energy and a load of other minor damage modelling stuff - maybe I'll eventually have time to do it, otherwise anyone who cares can download the source and add it.

I should have time to finish it within the next week.

P.S. I'd like to use the numbers from the main site for the GCS template, but I'm dubious about things like;

The TM states that 2.4TJ is sufficient to vaporize one cubic metre of tritanium which is used in starship hulls, so if phasers were equivalent to 30,000 TW of EM radiation they would vaporize 12,500 cubic metres of Federation tritanium starship armor every second! This obviously doesn't happen- phasers appear to destroy less than 5 cubic metres of starship armor per second of continuous impact, so they seem to be tactically equivalent to 1-10 TW lasers.

For one thing it references the TNG tech manual, which people here seem to react violently to (can't say I blame you considering some of the fuckups in there but if so the 2.4TJ figure is worthless). Secondly 'used in Starship hulls' doesn't directly imply 'all Fed hulls are solid tritanium' I'm considering modelling the GCS hull as a layer of uranium (i.e. 'duranium') over a layer of titanium. Both ST and SW hulls should probably have a higher than typical level of thermal conductivity, but I'm not sure exactly how much (definitely not superconducting, judging by the damage patterns).

You're building a starship combat simulator and trying to rationalise real units at the same time?

Good luck. I'm not even going to go into whatever fictional world you'll invent stats from - simply deciding to use '2.4TJ' instead of some abstract unit you've created eight thousand thousand times more work.

Stark wrote:You're building a starship combat simulator and trying to rationalise real units at the same time?

Real units aren't a problem to simulate - the main reason games avoid them is that they make balancing gameplay harder and confuse players if you have to put stats in the help or manual. Back when I was working on an advanced physics engine for Destiny Star's MMORPG framework, we used real units and physical modelling as much as possible: game mechanics overrode that where necessary. This applet is using very simple approximations of the physical processes, fairly stupid AI and has zero 'gameplay' concerns.

I'm not even going to go into whatever fictional world you'll invent stats from - simply deciding to use '2.4TJ' instead of some abstract unit you've created eight thousand thousand times more work.

I don't know why you think this. It's actually less work - I can get the equations from memory or basics physics texts, and I can get the figures from sources like ICS, the Trek TM or any of the 15,339 different threads on sci-fi forums arguing about how to derive performance figures from canon. The main problem is deciding which of the later to go with for an interesting/relevant result.

Except real units mean you have a much higher standard to live up to. If you want to waste your time, be my guest. Picking holes in Klingon Academy mechanics will be a lot more fun when they use 'real' units.

You already admit you're cherry-picking values that are 'interesting', so why bother? You're inspired by a fanfic involving horribly underpowered Imperial ships! If you're just going to use the 'interesting' units - right after dismissing 'ease of game balance' - are you going to ignore accepted or better-supported values? Will you accept 2.4TJ from the TM and ignore the 64MT torpedoes from the same source?

In any case, I look forward to seeing your modelling of various largely unknown phenomena in such a complex way.

Stark wrote:Except real units mean you have a much higher standard to live up to. If you want to waste your time, be my guest.

Sci-fi versus arguments are inherently a waste of time. The main motive here is to save time on the more involved versus arguments; instead of watching people argue about basic physics and tactics, get the maths wrong, state and restate their assumptions etc they will be able to skip all that and go straight to the serious part - arguing about what constitutes canon and how to interpret it

Picking holes in Klingon Academy mechanics will be a lot more fun when they use 'real' units.

If you want an actual game with realistic physics, try something like this, but the people who go for that generally want reasonably realistic spacecraft as well.

If you're just going to use the 'interesting' units - right after dismissing 'ease of game balance' - are you going to ignore accepted or better-supported values? Will you accept 2.4TJ from the TM and ignore the 64MT torpedoes from the same source?

It's trivial to make ship multiple profiles. I was thinking of doing a 'strict canon/harsh GCS', a 'tech manual/generous GCS' and then playing around with the numbers a bit to see if I could approximate the 'Conquest' situation. One thing I'd like to drive home is just how stupidly biased you have to make the numbers to give the Federation any chance at all. A lot of the features aren't working yet (particularly a non-fudged target acquire time), but currently you have to have over 100 GCS turning up every minute to prevent a roughly canon ISD from blowing them away nearly as fast as they appear. It'd be fun to run the Slave-1 versus GCS scenario from the 'SW vs ST in 5 minutes' page, if someone does a profile for Slave-1.

Starglider wrote:Sci-fi versus arguments are inherently a waste of time. The main motive here is to save time on the more involved versus arguments; instead of watching people argue about basic physics and tactics, get the maths wrong, state and restate their assumptions etc they will be able to skip all that and go straight to the serious part - arguing about what constitutes canon and how to interpret it

I just don't see how this would be useful in a debate at all. It requires a massive amount of unknown data to work (ie filling in all the fields) and the results are hardly going to be canon in any way. So how does it have anything to do with versus arguments?

Starglider wrote:If you want an actual game with realistic physics, try something like this, but the people who go for that generally want reasonably realistic spacecraft as well.

If you think I meant 'realistic physics' when I mentioned KA mechanics, you've missed the point. KA mechanics were basically fictional, non-canon silliness made up for the game. How are yours any different?

And when it comes to realistic space combat, I actually prefer miniatures to some low-quality computer game. They're usually more 'realistic', as well.

Starglider wrote:It's trivial to make ship multiple profiles. I was thinking of doing a 'strict canon/harsh GCS', a 'tech manual/generous GCS' and then playing around with the numbers a bit to see if I could approximate the 'Conquest' situation. One thing I'd like to drive home is just how stupidly biased you have to make the numbers to give the Federation any chance at all. A lot of the features aren't working yet (particularly a non-fudged target acquire time), but currently you have to have over 100 GCS turning up every minute to prevent a roughly canon ISD from blowing them away nearly as fast as they appear. It'd be fun to run the Slave-1 versus GCS scenario from the 'SW vs ST in 5 minutes' page, if someone does a profile for Slave-1.

Given the massive disparity, there's no contest anyway. Trying to illustrate that with a piece of software that requries hundreds of fields of debatable data is not going to make much headway in any kind of debate (people either already agree or are not going to be convinced by some software you made).

That said, I don't want to discourage you... just prepare you for the possible reception you'll get, even if by some alchemy you managed to find solid support for every piece of data and mechanical assumption built into it. Should be fun to use, either way.

Just go ahead and ignore stark - he never does anythig but bitch and moan anyways.

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. And a GCS has phasers as its primary weapons, and torpedos as its secondary weapons. The problem now is that when I try to select the different armerments it will shift units.

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. 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)

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 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.

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. In keeping with this, you would need to factor in acceleration (linear and rotational), and sensors (both resolution and speed - FTL sensors usher in a whole new ballgame when it comes to combat). 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). 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.

Shield burnthrough should be a measure of intensity rather then energy. 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.

You lack any options for point defense, you might want to include that in later versions.

Frankly, the ability to use this for a sci-fi vs debate will be limited due to the sheer number of variables. That said, I can see this being of IMMENSE value to anyone who is trying to write a battle, simulate reality, or extrapolate the "ripple effect" of an idea. The folks at Atomic Rocket and rec.arts.sf.science will likely find it interesting, and I look forward to its completion. 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.

Good work man.

Bitch and moan = say basically what you just said, eh? Built in assumptions, difficulty getting in-universe data, worthlessness in the vs debate... we even ended on the same 'looking forward to it' note.

Stark wrote:Bitch and moan = say basically what you just said, eh?

You provided ZERO constructive suggestions, instead opting to complain about the pointlessness of this do to disparity and complaining about sources, where as I pointed out things that needed to be added and the reasons why. If you think that is at all the same then you must also think that the person claiming evolution is flawed because it contradicts the bible is doing the same as the scientist who disagrees with an evolutionary pattern because he has different radiocarbon dates for a set of fossils.

So saying 'it's going to be hard work' and 'how are you using sources' and 'I don't think this will be useful at all in a vs debate' isn't constructive? You're more constructive, bully for you, but all you've got to say about my input is 'lol bitch lol stark moans', which is to my mind a hilarious bit of hypocrisy. I enjoyed the similes, though. Oh wait, I'm looking forward to seeing what he does with it, I'm clearly a terrible person for pointing out pitfalls in a way you don't like!

Stark wrote:So saying 'it's going to be hard work' and 'how are you using sources' and 'I don't think this will be useful at all in a vs debate' isn't constructive?

In what way shape or form does any of that help him improve it? That's right, it doesn't. Therefore it was not constructive.

You're more constructive, bully for you, but all you've got to say about my input is 'lol bitch lol stark moans', which is to my mind a hilarious bit of hypocrisy.

Seeing as what we did was different, you need to learn what hypocrisy is. I pointed out additons that needed to be made. You bitched about sources being cited for a blank template.

I enjoyed the similes, though. Oh wait, I'm looking forward to seeing what he does with it, I'm clearly a terrible person for pointing out pitfalls in a way you don't like!

Do you recognise the irony of complaining about my correctly pointing out that you constantly complain?

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'.

The folks at Atomic Rocket and rec.arts.sf.science will likely find it interesting, and I look forward to its completion.

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.

P.P.S. Does anyone have any good ideas for how to model ion cannons?

Starglider wrote:P.P.S. Does anyone have any good ideas for how to model ion cannons?

I'm assuming ion beams also affect the shields. Say one beam deducts X percent of the shields and electrical/electronic equipment directly under the targeted area.

If the ion cannon's target is the shield generators, they operate at X percent reduced strength for Y minutes. If the target is the sensors, the sensor range is reduced to X kilometers for Y minutes. If the target is another weapons emplacement, the damage a energy launch weapon (lasers, phasers, and rail guns) is reduced by X amount while rate of fire for the weapon (including photon torpedo launchers) is reduced by Z, for Y minutes.

This is assuming the targeted equipment isn't completely disabled by the ion beam. This is dependent upon the relative strength of the ion cannon emplacement and its target. For example, if the Executor's ion cannons target a B-Wing fighter, the Executor's weapons are likely powerful enough to disable the B-Wing's electrical/electronic equipment for the duration of the battle, while if the B-Wing's ion cannons targeted the Executor, the Executor would only suffer from localized disruption for a few minutes.

So say a figure in joules for ion beam strength plus some sort of arbitrary figure you can input for how much disruption 1J or something will cause.

The other thing it's probably worth doing is putting the notes for each entry into the main program - say click on a little "?" to bring up the notes in that text box along the bottom. It wouldn't be fancy but it'd save people from flicking back and forth if they're not sure what to put into a box.

Oh yes, and examples - Mike's "STvSW in 5 mins" or something might work...

Off to G&C, given the content.

Sidewinder wrote:I'm assuming ion beams also affect the shields. Say one beam deducts X percent of the shields and electrical/electronic equipment directly under the targeted area.

If the ion cannon's target is the shield generators, they operate at X percent reduced strength for Y minutes. If the target is the sensors, the sensor range is reduced to X kilometers for Y minutes. If the target is another weapons emplacement, the damage a energy launch weapon (lasers, phasers, and rail guns) is reduced by X amount while rate of fire for the weapon (including photon torpedo launchers) is reduced by Z, for Y minutes.

I like the detail, but guesstimating and entering all the parameters could get tedious and I'd need a new GUI. Maybe in V2. How about a simplified version for V1;

Ion cannons have identical stats to beam weapons, but have a 'disruption multiplier' instead of a 'shield multiplier'. Hits to shields are handled normally. Hits to ship systems build up 'ion charge' equivalent to the ion cannon's raw damage multiplied by the disruption multiplier. Ion charge lowers fire rate, slew rate and targetting accuracy proportionally up to a charge equivalent to the damage required to destroy the system, which completely disables the system until the charge dissipates. Double this amount of charge burns out and destroys the system (until repaired by damage control, if present). Hull hits lower combat speed and manueverability in the same fashion.

That would be fairly easy to implement and AFAIK consistent with the effects of ion cannons in SW, but I'm not sure how fast the 'ion charge' should bleed off. Based on TESB (the hit on Luke's airspeeder) there should also be an option to give turbolasers a minor ionisation effect, but again that can go in V2.

As I've mentioned, sensors and ECM suffer from the problem of being almost impossible to quantify based on canon evidence, but I may put them in in a later version for non-versus purposes. I can model raw radiative power output of radar-equivalents and simple white noise jammers fairly easily (also simple passive stealth), but more complex stuff would probably have to be quantified in abstract terms, and I'd like to stay as physically grounded as possible.

Teleros wrote:The other thing it's probably worth doing is putting the notes for each entry into the main program - say click on a little "?" to bring up the notes in that text box along the bottom. It wouldn't be fancy but it'd save people from flicking back and forth if they're not sure what to put into a box.

I'll put that on the feature list for later implementation.

SDN user 'fusion' has supplied me with some templates to add to my basic SDN GCS and ISD, I'll go get template import/export working now so you can see. Thanks for the suggestions.

Jesus.

*Hires Starglider to do the programming for a space combat sim*

You do need to put in some "stock" ships, like the E-D, ISD, etc in a drop down menu with all the data entered tho.

I think he just said he was doing something like that lol .

Ok, 'disabling' weapons are now implemented as described above, except that on reaching twice the charge required to disable instead of the system simply failing, further disabling fire does real damage at its rated energy. I think that better matches what we see on screen; continuing to pound a disabled ship with ion cannon fire won't suddenly cause it to blow up, but it will start taking limited physical damage. I've arbitrarily set the charge bleedoff to 0.2% per second for now - a ship that's taken just enough ion hits to totally imobilise it will recover in a little over 8 minutes (16 minutes if it's overcharged to the maximum). If anyone has a better figure for how long the ISD hit by the KDY-150 in TESB was knocked out for, let me know.

The 'stock' ships are what the 'ship profile' choice box is for, but I'd better get the 'import from/export to text file' working properly for people who want to create (and reuse) their own.

Didn't get as much done as I hoped last night mainly due to reading 'The Shield of Faith' (book on the history of ABMs and SDI, which just turned up) instead. I've uploaded the new version of the shell to the web page though. Right click for a popup menu with 'use Newtonian physics', 'deterministic/pseudorandom simulation' and import/export options (import is incomplete, export seems to work ok though you may have to fiddle with your popup blocker if the window doesn't appear). Disabling weapons and basic profile sanity checking should work. I changed 'energy delivered' to 'projectile mass' for projectile weapons, since explosive unguided shells seem to be relatively rare in sci-fi (they're just not worth it in most space combat) and it avoids dubious assumptions about impactor composition and the tedium of doing a manual base KE calculation (formerly scaled for relative velocity by the engine, which was an ass-backwards way of doing it). A later interface should support explosive shells properly.

P.S. Firefox seems to be obsessive about caching applet files even if you hit shift-reload, restarting forces an update though.
P.P.S Still using fixed rotation rates even with Newtonian physics for now - will eventually do angular acceleration and momentum, but I expect that will have a minimal impact on the results of this specific scenario (which is set up for 'wallowing capship slugfest' not 'space superiority dogfight' or 'relativistic/FTL combat').

Starglider wrote:Ok, 'disabling' weapons are now implemented as described above, except that on reaching twice the charge required to disable instead of the system simply failing, further disabling fire does real damage at its rated energy. I think that better matches what we see on screen; continuing to pound a disabled ship with ion cannon fire won't suddenly cause it to blow up, but it will start taking limited physical damage. I've arbitrarily set the charge bleedoff to 0.2% per second for now - a ship that's taken just enough ion hits to totally imobilise it will recover in a little over 8 minutes (16 minutes if it's overcharged to the maximum). If anyone has a better figure for how long the ISD hit by the KDY-150 in TESB was knocked out for, let me know.

The 'stock' ships are what the 'ship profile' choice box is for, but I'd better get the 'import from/export to text file' working properly for people who want to create (and reuse) their own.

Unfortunately I don't have the book on me, but in one of the Thrawn trilogy books, the second I believe, you have an ISD under attack from 3 of the Katana dreadnaughts. Their ion cannons are just enough to keep the ISD disabled, but not enough to overwhelm it. It was implied that if any of the three was unable to put up full salvos for whatever reason, the ISD would proceed to curb stomp them. I'm not sure, but I'm having a vague recollection of something similar happening to a Golan defense satellite in the Thrawn books too. Maybe a member with the books can give you some more info to help with the modeling of ion cannons.

Haven't done any more work on this today (I'm half-way through 'The Shield of Faith' though...), so I thought I'd put up my default Galaxy-class and ISD profiles for people to rip apart. I'm using the most generous available (sane) canon estimates for the GCS, even the TM in a few places where it was unavoidable (though not for torpedo yield). I'm using mostly primary canon lower limits and conservative estimates for the ISD - EU-derived figures could easily be 100 times higher. Of course it still appears to take most of Starfleet to take down one ISD.

Two major questions I don't know the answer to: 'how long does it take SW capship shielding to recover after total shielding failure' (I'm using a really low TESB estimate right now, which forces up the shield capacity estimate due to ROTJ requirements) and 'how much damage does a self-destructing ISD do' (haven't seen that happen in the EU, that I know of).

Right now I have 'destroyed' SW ships at zero extra yield, but actually considering how the Executor-DS impact looked it should probably be nonzero.

Two major questions I don't know the answer to: 'how long does it take SW capship shielding to recover after total shielding failure' (I'm using a really low TESB estimate right now, which forces up the shield capacity estimate due to ROTJ requirements) and 'how much damage does a self-destructing ISD do' (haven't seen that happen in the EU, that I know of).

The first one is a hard question, I can only give you an example: when an Excutor was hyperspace rammed by three star destroyers on accident (which where turn into powder literally), it took over 12 hours to fix it. A reason why it took so long was because it was not in combat mode and the sheilds where not fully up and the generators took some damage also that shows the insane power of the sheilds of the ship. Of course there is the other end of the spectrum

For self destuction, use the sheild amount as it is the overloading of the reactor.

Star wars ship also have higher sheild refresh rate as they can fire at each other for weeks (evident by the Seige of Coursant). Or they have insane sheild capacities. Your choice


ISD do not ram, not even as a last ditch option because sheilds can take so much damage (because it is the empire if it was a rebel controling it, then it might use it as a last ditch option).

PS:The ISD even by Canon figures can derive 1E25 power figures

Did a little more work on this today. Ship profile loading from URLs and text import is working correctly now. Targeting is still essentially broken though, so it's still not usable. Currently I'm modelling capship armour as a grid of 1024 thermally superconductive plates, perfectly insulated from each other. I suppose thermal conductivity is another thing that should be in the next version, but in the mean time I'll need another semi-reasonable interim assumption - maybe I could just assume that all armour has the thermal conductivity of iron.

I must confess, after reading the Stewart@SDI threads (hilarious BTW) I can't blame people for being highly skeptical of anything that sounds remotely like 'my 1337 program that solves the ST versus SW debate !!11!1!'