Boost to launched drone speed

  • strict warning: Non-static method view::load() should not be called statically in /home/swa_webmaster/sfb.swa-gaming.org/modules/views/views.module on line 843.
  • strict warning: Declaration of views_plugin_display::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /home/swa_webmaster/sfb.swa-gaming.org/modules/views/plugins/views_plugin_display.inc on line 1877.
  • strict warning: Declaration of views_plugin_display_block::options_submit() should be compatible with views_plugin_display::options_submit(&$form, &$form_state) in /home/swa_webmaster/sfb.swa-gaming.org/modules/views/plugins/views_plugin_display_block.inc on line 193.
  • strict warning: Declaration of views_handler_field_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/swa_webmaster/sfb.swa-gaming.org/modules/views/handlers/views_handler_field.inc on line 641.
  • strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /home/swa_webmaster/sfb.swa-gaming.org/modules/views/handlers/views_handler_filter.inc on line 585.
  • strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in /home/swa_webmaster/sfb.swa-gaming.org/modules/views/handlers/views_handler_filter.inc on line 585.
  • strict warning: Declaration of views_handler_filter_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/swa_webmaster/sfb.swa-gaming.org/modules/views/handlers/views_handler_filter.inc on line 609.
  • strict warning: Declaration of views_plugin_style_default::options() should be compatible with views_object::options() in /home/swa_webmaster/sfb.swa-gaming.org/modules/views/plugins/views_plugin_style_default.inc on line 25.
  • strict warning: Declaration of views_plugin_row::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /home/swa_webmaster/sfb.swa-gaming.org/modules/views/plugins/views_plugin_row.inc on line 135.
  • strict warning: Declaration of views_plugin_row::options_submit() should be compatible with views_plugin::options_submit(&$form, &$form_state) in /home/swa_webmaster/sfb.swa-gaming.org/modules/views/plugins/views_plugin_row.inc on line 135.

Hi,

it just hit me that the current drone speed doesnt take into account the launching ship speed, wich would be an even more important factor in the emptiness of space. Of course drones are a 360°

So here is a proposal :

Initial speed of drones depend on the fire arc they are shoot from:
- Drones from the FA arc add the ship speed to their initial release speed .
- Drones from the R/L arc use their basic speed.
- Drones from the RA substract the ship speed to their initial release speed (min 0).

For the first 8 impulses after launch, drone movement is based on release speed (maximum of effective speed being 32(40?)).
After that initial period and each 1/4 turn after that (8th, 16th, 24th) release speed adjust to become equal to the average of the current release speed and drone speed (maximum effective speed still = 32(or 40), round fraction up).
After a full turn, release speed equal drone speed.

Let's take an example:

A Kzinti FF going speed 27 launch a speed 8 drone at an unsuspecting Klingon CA through the FA arc during impulse 1.25

From 1.25 to 1.32, the drone go at speed : 8 + 27 = 35, moving 32 (or 35 if using sabot rules).
From 2.1 to 2.8, the drone go at speed : (35 + 8) / 2 = 22.
From 2.9 to 2.16, the drone go at speed : (22 + 8) / 2 = 15.
From 2.17 to 2.24, the drone go at speed : (15 + 8) / 2 = 12.
From 2.25 the drone is back at its speed of 8.

I understand that it could add a bit of bookeeping (or even a lot of bookeeping some times if drones are launched 1 by 1). But I think it give back to teeths to early drones and drones using faction and it open up a bit of tactical play, putting more importance on the release condition of the drones (by example a 0 speed SP or Fighter release is clearly less interesting than even a speed 8 fighter drone wave, using the 360 aspect of the drone release now come at a price in initial speed, it is now possible to "lob" drones at a target to increase their range).

What are your opinions ? would you consider using such a rule on a duel ?

No edit function :( I wanted

No edit function :(

I wanted to add, that, to lower the bookeeping, the drone speed change could be pre-calculated and written directly on the combat tracker to ease things a bit.

IKerensky wrote:

>>it just hit me that the current drone speed doesnt take into account the launching ship speed, which would be an even more important factor in the emptiness of space.>>

Well, not that it is particularly important to your idea, but SFB doesn't take relativity/inertia into account in any instance; a ship can be moving 20 times the speed of light in one instant and then stop dead in space in the next. A ship can be moving 25 times the speed of light, instantly turn around and reverse direction at 25 times the speed of light with no delay or acceleration issues. (The "explanation" involves "warp bubbles" around units moving at warp speed, which, to be fair, is from the original source material).

That being said, I'd probably avoid a rule like this as it strikes me as just a little too fiddly, in that you need to calculate the speed of each drone when it is launched (which would often be different by drone), and then keep track of when they speed up, and then speed them up, which if you want to launch a bunch of drones in different directions on different impulses would become something of an accounting nightmare.

Slow drones work ok in situations where you use slow drones (i.e. early or middle years Klingon vs Kzinti fights).

I'm with Peter B.

WAY too fiddly. It'd also likely to have a significant effect on gameplay.

Well, I cant argue about the

Well, I cant argue about the fiddly part. But that is just a first draw ;)

And about having significant effect on gameplay, I think that this is welcome as new/optionnal rules are there to add some variety to the game. The more it impact on gameplay without changing too much the rules, the better.

Drone management is already quite fiddly, especially if you have different kind of drone in play. As you have to track everyone of them, but that is part of the game (notice I didn't said the fun :p).

I think you can average the effect by saying that for the first turn in flight drone speed is equal to : Drone Speed + Half the Speed of the releasing ship. It make for a lot less of bookeeping as you only have one number to write down with the drone launching time in the combat log.

Anyway, it was just an idea...

Averaging Speed

Or just using a short term speed adjustment seems like a much better plan for something like this. Something like:

When you launch a drone, for the first 8 impulses it is on the map, do the following to the speed:

-If you launch it in FA, add the ship's speed.

-If you launch in R or L arc, do not change the speed.

-If you launch it in RA, subtract the ship's speed.

So if you are moving speed 27, and you launch a speed 20 drone at someone in your FA, the drone moves speed 47 (?!?!) for the first 8 impulses (which would move on speed 32 and speed 15).

After 8 impulses, the drone returns to a normal speed.

I mean, the effect would be nuts a lot of the time, but it would be reasonably manageable and not *that* difficult to navigate. I mean, I probably wouldn't ever want to use such a rule, but I can certainly see why someone might want to mess around with one :-)

Also I forgot to notice but

Also I forgot to notice but SFB did involve rules for inertia and drag in several place.

- The turn mode, wich is dependant on speed, ergo inertia.
- The reverse wich need to decellerate and pay movement for this deceleration.
- The tumbling.
- Side Slip requirement.

Bakija, your idea is interesting and easier, it sure goes for wacky speed at higher drone speed but make for interesting tactics/choice : do I turn into my opponent, risking overload and more damage but getting faster drones than he could dodge or do I play safe and launch slower one ?

I see also that overrunning work a bit differently as your drones are slower if shot backward.

Peter

I'd like that idea if it applied to other seekers as well, especially plasma.

I agree with Peter

I further will say that incorporating some form of "inherited inertia" is not going to be at all balanced and also really does not fit with the "physics" of the universe.

IKerensky Wrote:

(You post on the Battletech BBS with a name like that?)

>>- The turn mode, wich is dependant on speed, ergo inertia.
- The reverse wich need to decellerate and pay movement for this deceleration.
- The tumbling.
- Side Slip requirement.>>

I mean, yeah, there are some, which are artifacts of SFB being based on Naval Warfare rules. Ships can't turn instantly, and need to pay "quick reverse", and occasionally tumble, but for the most part, lives up to the "the universe has no inertia" system that is based on original Star Trek "physics" (i.e. ships move FTL via projecting a "warp bubble" around the ship, which allows for a total disregard of inertia...)

I mean, yeah, the idea of being able to launch drones at speed 63 is certainly appealing, but I don't know that it is necessary :-)

What about shuttles?

If we do this to drones then we should do this for everything. This could be a problem for shuttles if you are launching them at more than twice their speed rating.

One of the things I recall

One of the things I recall wanting back in the days I was on the staff was to consider printing "variant" rules which would have a distinction from the "optional" rules in SFB. This is because although they are "optional" IMHO they are generally implied to be a true representation of the SFU. Whereas "variant" rules are to provide a fun, different perspective, but should not be considered canon. ADB may rarely make variants-so called conjectural or simulator rules/ ships. But often things get debated as if they are to be canon. Not saying that was happening here. Just pointing out that an unofficial board is the perfect place for sharing variants.

Answers

Bakija - "(You post on the Battletech BBS with a name like that?)"

I post in every forum with a name like that ;) but incidently yes, on the battletech one too.

Kreller1 - "I'd like that idea if it applied to other seekers as well, especially plasma."

BuddhaDude - "If we do this to drones then we should do this for everything. This could be a problem for shuttles if you are launching them at more than twice their speed rating."

Yeah, it's a bit of a Pandora box, in fact you can argue that Photon Torpedoes too should be affected ;) (in fact I fail to see why Photon Torpedoes are dumbed as direct fire and not very fast guided either).

I think it is not that hard to put a hard limit on the boost at a maximum of twice the object speed... or not. After all launching shuttle at Speed 32 doesnt seems like a very safe thing to do... It would really well explain why shuttle bay often open to the rear of ships and not to the front. After all if it is not safe to tractor a shuttle at speed over 15 I can see it being not safe to launch them at relative speed over 15.

I think the question is how much more movement it actually give and the impact. And the russian puppet effect : a CV speed 32 launch a speed 16 fighter that fire a speed 20 multiwarhead drone that release speed 20 submunition... A bit extreme but could produce very fast final speed.

I think that if using this variant you also have to add the defensive fire phase "ala" Federation Commander to balance things a bit. As otherwise, close range plasma and fast drone become some sort of direct fire weapon.

Perhaps this kind of detail is better left to a computerised simulation.

But as Admiral point out it make for a nice variant, rather than a house rule. Would produce a very different game where front launched plasma and drones are something to really be feared at closer range.

So what about :

"During its first turn in flight a just launched seeking weapon or shuttle, potentially got an adjustement to its speed. If launched in the FA it add half the launching speed to his movement, if lauched in the RA it remove half the lauching speed to his movement (min speed of 0). If the seeking weapon or shuttle speed is superior to that of the launcher the adjustement is only of a quarter."

Sideways

Not that I recommend this sort of complexity, but you ought to add the ship's velocity as a sideways vector to the drone's velocity when you launch it out the side. So if the ship is moving A and you launch the drone in C, it'll actually head B at the combined speed. It's ultimately the same maths as tractor dragging.

I suppose I ought to post my vector thrust variant somewhere, not that it uses this sort of rule. I'll have to clean it up a bit first.

How about duo movement

We could have the drone move at two speeds for X number of impulses where X equals the ships speed / 4. One movement would be the as normal. The second would be the same as the launching unit at time of launch.

Assume a ship moving direction A at speed 20 launches a speed 8 drone on impulse 6 in the same direction. 20 / 4 = 5 impulses. So from impulses 7-11, the drone would move forward 4 times: impulse 7, 8 and 10 for speed 20 and on impulse 8 for speed 8. The drone would then move as normal on impulse 12 (another move). The give a formovement of 5 hexes in 6 impulses.

This could work the same for sideways and rear launch too, although rearward gets a little tricky. For side launches, it sideslips in the direction of launcher movement on launch movement impulses. For rear launches, it would movebacks until it overcomes the inertia. The above example works out well: you launch a drone in direction D; on impulse 7 in moves backward in direction A, on impulse 8 the movement cancel eachother out and the drone remains, impulse 9 nothing, impulse 10 it moves backwards (toward A), impulse 11 nothing. Then on impulse 12 it moves as normal. However , the would be time when it could move backwards the forwards, then backwards all on subsiquient impulses. All I can think of is to look at the number of forwards and backwards movements in the X impulses. The first forward move would cancel out the last backwards impulse and countinue canceling until one or the other is all canceled out. If you are left with 1 backwards movement in 6 impulses, it would move backwards on the first speeds movement then remain in the same hex until the 6 impulses are over. It would then move as normal.

Not appealing...

I don't find this even vaguely appealing. It adds complexity and (IMHO) wouldn't add anything either to the fun of the game or to the tactical depth of the game.

Maybe I'm misremembering, since I haven't seen the X rules in years, but didn't X tech drones move 2 spaces per impulse?

Vector movement rules

Like a fool, I spent some time typing this up. Use with extreme caution, though it might be fun. Or very broken.

http://www.aaargh.org/SFB/Misc/vector.html

No, I haven't tested it.

Could work

How would it work after the launched unit makes a turn to a new direction?

Also perused your Thousand Wardering Tribes. I like them. I should set up a site like yours for the Dalian Sway and some other ships I thought up. I of my Hydran favorites was when I melded an Overlord into something simular to the Galatica.

It's on its own

The launched unit is an independent thing with its own acceleration and facing, so you treat it as an individual.

Yes, this gets horribly complex. Do not attempt this with a Kzinti SCS group.

Mudfoot - Did you get the

Mudfoot - Did you get the Hrydran SCS varient I tried the email you?

Yes

Yes. Couldn't reply because my ISP's SMTP server is up the spout for some odd reason. Irritating.

Nice SSD. Variant is putting it lightly...I guess it probably does make a fair Battlestar Galactica clone, though never having watched it I couldn't swear to its fidelity. What's a Landing Pad?

Landing Pads

The landing pads are a way of showing that a shuttle bay can land more than one shuttle at a time. I can't remember whose site I saw them on, but I'm pretty sure ADB killed it. I can't remember if it can do double duty as an emergency parking spot, but if it can then it shouldn't be able to be rearm, fuel, repair, etc.

Anyone else want to see my

Anyone else want to see my Hydran version of the Galatica? I'd post it here, but I don't know how.

Anyone else want to see my

Web page addresses and e-mail addresses turn into links automatically so upload it to an image site like imgur and post the link.

Yeah...

show it too us Dale!