14:45 < jpab> you know, as much as it's "realistic" to have hyperspace requirements depend on total ship mass, it's really annoying when you think you can jump somewhere and then you buy fuel for the jump and suddenly it's out of range
14:47 < JohnJ> yep.
14:48 < JohnJ> I'd prefer it if you just "charged" your hyperdrive rather than buying fuel in tons.
14:49 < jpab> would you still have fuel for whatever charges the drive? or are you thinking solar power or something?
14:50 < JohnJ> well, you could either buy disposable recharge units or recharge with a "fuel scoop".
14:50 < JohnJ> It's essentially the same except without the business of manually buying fuel in tons.
14:51 < jpab> what are your thoughts about in-system travel?
14:51 < robn> yeah that
14:51  >>> JohnJ advocates it occasionally :-)
14:52 < jpab> have you read Brianetta's notes on propellant?
14:52 < JohnJ> oh, that
14:52 < JohnJ> I don't think it adds much unless you're playing orbiter.
14:55 < JohnJ> It's a bit marginal compared to the implementation effort.
14:55 < JohnJ> My real concern is that without in-system FTL there's never any way of joining a battle.
14:56 < JohnJ> And that *would* be a major change :-)
14:56 < jpab> that's a tough one
14:57 < robn> the frontier heads will hate it
14:57 < robn> me, I love changes :)
14:57 < jpab> personally I have no problem with in-system FTL (actually I'd quite like FTL to be a continuous thing rather than completely separate hyperspace & in-system), but I know a lot of people are very strongly against
14:58 < Ae_> hey, it's hard to do design a chokepoint-less system as would be the case without FTL
14:58 < Ae_> there might be choke points near stations, wrecks, mining bases etc. but most of those will be undefended
14:58 < Ae_> defended i mean
14:58 < robn> of course, in-system FTL means we don't need the timeaccel. and without that we have no convenient mechanism to point to when someone asks for multiplayer ;)
14:59  >>> Ziusudra laughs
14:59 < jpab> well, there's still the mechanism of "it's damn hard and we don't have the time, experience or interest to do it" :P
14:59 < jpab> maybe some of us have the interest, I don't know
14:59 < robn> or phrased another way, "patches welcome"
14:59 < robn> I don't really
14:59 < robn> I'm kinda over the "network programmer" part of my career
15:00  >>> JohnJ has written a fair bit of multiplayer code :-)
15:00 < Ae_> maybe the ftl system would take a small amount of time, so there's still justification for time accel?
15:00 < JohnJ> Well, you can justify time accel by making in-system FTL strictly optional.
15:00 < robn> and these days there aren't enough games that focus on a good single player experience. it'd be nice to be try
15:00 < JohnJ> Like with a charge limitation on the FTL.
15:00 < JohnJ> So you can get to the battle with FTL, but you may need to fly back.
15:01 < robn> that works.
15:01 < Ae_> or just point out ftl is out of scope giving the reasons in a faq:)
15:01 < robn> do you see it being just a very short hyperspace jump, where functionally we just change your position and fast-forward the clock a bit?
15:01 < Ae_> yep,one way jump
15:01 < jpab> hyperspace arrival location is now deterministic (+ a jitter value of a few km) based on direction of source system from target system, btw. I'm not sure if that makes a big enough difference to interception to be relevant to this discussion. Probably interception is only possible right at the hyperspace arrival point...
15:02 < robn> or is it some sort of realspace thing where another guy could watch you zip past?
15:02 < robn> I suppose it could just be an instant velocity jump
15:02 < Ae_> and crash into something?
15:02 < robn> no accel required
15:03 < jpab> the "Park shift", in Orson Scott Card terms
15:03 < jpab> although that was a shift to light-speed, not to FTL
15:03 < JohnJ> well, you want in-system FTL to be faster than the average battle :-)
15:03 < JohnJ> Otherwise you lose the main purpose.
15:03 < robn> yeah, so it needs to be near-instant
15:03 < JohnJ> So 1x or 10x max.
15:04 < robn> bsg style wink-in-wink-out
15:04  >>> robn always thinks of hyperspace things in terms of special effects :P
15:04 < jpab> jump rather than warp
15:04  >>> JohnJ cackles
15:04 < robn> maybe part of the cost then could also be based on the distance
15:04 < JohnJ> I always liked the idea of having to twitch-control your way through a tunnel for maximum hyperspace speed :-)
15:04 < JohnJ> But Brianetta would probably hate that.
15:05 < robn> the jump itself is instant, but the further you want to go, the long it takes for the drive to power up / the computer to plot the course
15:05 < robn> JohnJ: loading side-game
15:05 < robn> I want to play tetris in hyperspace
15:05 < JohnJ> Is this too 8-bit :-)
15:05 < Ae_> the other issue is why the target of a battle would not have a charged jump ready, or maybe there can be some charge draining thing
15:05 < jpab> yep, there are three known ways of implementing FTL: jumps, where you disappear in one place and appear in another; warps where you travel at FTL speeds in real-space; and wormholes/hyperspace, where a giant tunnel in space opens up connecting two points and you fly through it
15:06 < robn> "known"
15:06 < robn> yeah
15:06 < jpab> known to sfx crews :-)
15:08 < jpab> so, we could have jumps, where cost and outside-world elapsed time are related to jump distance and proximity to mass, plus newtonian flight and time acceleration
15:08 < robn> yeah
15:08 < JohnJ> Should make AI choices hellishly complex :-)
15:09 < robn> it solves some of our stickier problems
15:09 < robn> battle/intercept being the bigest
15:09 < robn> biggest
15:09 < robn> it'd be a good excuse to bring in the fuel mass change, though its not a prereq
15:10 < jpab> maybe velocity should be retained across a jump? (is that tricky to get the frame-relative velocity "right" for that? or meaningless?)
15:10 < JohnJ> largely meaningless
15:10 < jpab> yeah, ok
15:10 < JohnJ> You'd want to match velocity to the target at the exit point anyway.
15:11 < Ae_> it's nice for the intercptor, but what of the interceptee, he can just ftl away?
15:11 < JohnJ> you'd need jump downtime anyway.
15:11 < jpab> *might* be possible to limit that problem with very careful choice of the jump cost function
15:11 < robn> Ae_: sure, or he can just run normally. he might need to hang around a bit to while he calculates the jump and/or warms up the drive
15:11 < Ae_> maybe jumps destinations are perturbed so ships can't jum away
15:11 < JohnJ> Otherwise someone who jumped into a system with a spare charge would be untouchable.
15:12 < robn> there's also the question of accuracy. maybe you can only determine your exit position to within some margin of error
15:12 < robn> so you can say "jump to that guy" and end up emerging a few thousand km away, or right on top of him
15:13 < robn> so there's risk involved either way
15:13 < robn> (of dying or losing your quarry)
15:13 < robn> and then, maybe, upgraded scanners / positioning things to make that more accurate
15:13 < robn> there's some flexibility here
15:13 < JohnJ> There's a lot of options :-)
15:13 < jpab> margin of error yes, though I'm not sure I'd want it to behave like that
15:14 < Ae_> yeah,maybe it might help to draw up a list of gameplay scenarios/gameplay types and then see if it's possible to bend things to malke them possible
15:14 < robn> jpab: there's probably some bullshit story we can devise to make it so you can jump into range of a guy while still allowing him time to react
15:14 < jpab> exit velocity has to be considered I think
15:15 < robn> oh, and I guess really big ships can't jump too close to a large mass or something
15:15 < robn> so we can still have our convoys :)
15:15 < JohnJ> well, you'd still have convoys doing joint jumps anyway.
15:16 < jpab> I would say proximity to mass (on both ends ideally) should be a significant factor in jump cost
15:16 < robn> yeah, but you don't want them just to jump straight to the target planet.
15:16 < robn> you want them to do what they do now - jump somewhere far out and then have to fly in normally
15:16 < robn> meanwhile, the pirates can spot you and jump in
15:16 < robn> jpab: agreed
15:16 < JohnJ> can't jump too close to a planet because the terran takes too long to load :-)
15:16 < robn> exactly!
15:17 < Ae_> larger mass ships should just have very expensive ftl, so there's a serious cost/weight benefit to not having good ftl capabilities
15:17 < JohnJ> yeah, that's an option.
15:17 < JohnJ> So they'd just do the bare minimum on a cost/benefit.
15:17 < robn> I prefer "physical" limitations to monetary ones
15:17 < robn> but yeah, its an option :)
15:17 < jpab> not if this is for system-to-system jumps as well as in-system (which I was thinking it would be)
15:19 < JohnJ> I suppose really big hyperdrives could be strictly one-shot for technological reasons.
15:19 < Ae_> well, if upon arriving and engaging a target, you want things to be newtonian for a while..disabling jumps from an area might help
15:19 < Ae_> while still allowing arrivals
15:20 < jpab> still not sure what to do about exit velocity -- not much good jumping to within a couple of km of your quarry if you're at velocity (relative to your target) when you appear
15:20 < JohnJ> just match target velocity, or thereabouts.
15:21 < jpab> seems kinda cheating :-/
15:21 < JohnJ> FTL is cheating :-)
15:21 < robn> heh
15:21 < JohnJ> you'd have to do something similar when hyperspacing to a planet.
15:21 < robn> the same magic that lets you find your quarry also lets you determine his velocity
15:21 < JohnJ> otherwise it'd take you almost as long to catch the damn thing afterwards as to fly there without FTL :-)
15:21 < Ae_> maybe ftl requires a 'lock' on a ship for accuracy
15:22 < JohnJ> with accuracy improving the longer you wait, so you get to pick your tradeoff.
15:22 < jpab> determine, yes, but should you really just be able to pick and choose your exit velocity (not that the player can, but the hand-waved technology apparently can if it matches target velocity for you)?
15:22 < jpab> actually, that's quite nice...
15:22 < JohnJ> jpab: It's kinda essential, really.
15:24 < JohnJ> If you actually want to retain the property of entering a battle while it's in progress.
15:24 < JohnJ> Matching velocity manually is going to take far too long in most cases.
15:24 < jpab> yeah, I'm just trying to think of a good alternative -- something that gives a useable behaviour but still feels like it's not just giving you a free pass for gameplay reasons
15:24 < jpab> I do have one idea, but I don't like it much
15:25 < jpab> but the accuracy vs. velocity trade-off has a lot of potential I think
15:25 < jpab> I'm thinking that should be combined with jump distance
15:27 < JohnJ> you don't want to make it so that everyone hangs around at sun-relative zero velocity just to get reasonable intercepts :-)
15:27 < jpab> agreed
15:27 < jpab> whatever the maths of the model, it has to work for both in-system target chasing/interceptions, and system-to-system jumps
15:27 < jpab> (well, doesn't *have to*, but I'd much prefer that it does)
15:28 < JohnJ> relative system velocities? :-)
15:28 < jpab> heh, well, there's that too
15:28 < JohnJ> I suppose that'd mean that jumps between certain systems would be more accurate.
15:29 < jpab> if accuracy is angular + distance error, then I guess it'll have to be much higher for a system-to-system jump than an in-system jump
15:30 < jpab> and for the distance component, would that error be a factor or an absolute offset?
15:30 < _robn> So you may want to land further out so the error doesn't land you inside a planet?
15:31 < _robn> Probably a factor
15:31 < _robn> Some multiplier
15:31 < JohnJ> you wouldn't necessarily want to give people the choice there.
15:31 < JohnJ> Too much save/reload nonsense :-)
15:36 < Ae_> to get rid of reloads, might be just a constant error distance then relative to a locked target..but the point within the circle or ellipse is pickable
15:36 < Ae_> and the target has some time to react
15:37 < jpab> incidentally, the idea I had before re: exit velocity was to say that a jump gives acceleration in the direction of the jump vector, with speed related to jump distance, which requires some fairly circuitous hopping around to match velocities with things (that hopping would be handled by the jump computer and probably error accumulates from hop to hop until you stop for long enough to get a proper location fix)
15:37 < jpab> but as I said I don't like that much
15:38 < jpab> I *might* like it, but it's kinda complicated and difficult to see the implications
15:39 < jpab> not to mention probably tricky to implement
15:39 < Ae_> is the exit velocity current velocity plus jump velocity? otherwise a short second jump might get a close to zero velocity
15:39 < jpab> I said acceleration
15:40 < Ae_> oh
15:40 < jpab> so yes, additive
15:41 < jpab> actually thinking about it that probably works out to be similar to some kind of super-thruster or thruster + weird time effects
15:41 < jpab> which is sort of what we have right now :P
15:42 < Ae_> a lot depends on the distance/time equation of the jump
15:42 < jpab> right
15:42 < jpab> hadn't thought of it explicitly, but in retrospect it's obvious that for intercepts to work, in-system jumps have to be close to instantaneous
15:43 < Ae_> there needs to be some way of stopping half the police in the system jumping
15:43 < jpab> maybe they're just really apathetic ;-)
15:44 < Ae_> :)
15:44 < _robn> Jump hammer
15:44 < _robn> Jammer even
15:44 < JohnJ> Well, depending on the system, "half the police" may not be very many :-)
15:44 < _robn> But hammer could be cool :)
15:44 < JohnJ> It's fair enough to get mugged by 30 vipers if you try attacking a trader in Sol.
15:45 < jpab> Jump hammer. Jammer. neat.