Stock Communications System: What's the Word Now?

[Guest]

3 minutes ago, tater said:

Gotcha, that is what I assumed he meant, but it always bugs me when my high-gain is clearly pointed the wrong way, and the LOS calculation implies the ability to correct this visually (and possibly functionally in a mod).

That would require on-rails station-keeping, orientation, and RCS usage.  Or spin-stabilization.  That sort of thing.  RT2 modeled the problem fairly well with the "communications cone" but its antennas are still functionally omni-directional due to limitations/abstractions in the game.

[tater]

Yeah, I was thinking along the lines of the persistent rotation mod. That or you'd change scenes to the spacecraft in question, then it points the antenna along the LOS it is using (ISRU does something like this, right, it looks at the time interval that has passed, then catches you up?).

[RoverDude]

13 minutes ago, tater said:

So all the stock antenna models are changing? 2 of them are parabolic as it stands (by definition, directional). Or do you mean that they will function as omnidirectional even if the game parts are unambiguously directional?

Given that the game will be doing an LOS check, should;t it be possible to point an antenna along that LOS? Not saying it makes a lot of sense e for stock, but it would be pretty cool to watch a flyby with the dish actually pointing to Kerbin.

They simply function as omnidirectional, regardless of model.  It's assumed they point where they need to point to off-camera to download instructions, or do other antenna-things.  @regex noted all of the fun bits that would have to change.  Then add in things like antenna placement on your ground base, rework of all of the models to have sufficient movement (and for some this would be more than a bit of a pain), etc. 

[Guest]

15 minutes ago, tater said:

Yeah, I was thinking along the lines of the persistent rotation mod. That or you'd change scenes to the spacecraft in question, then it points the antenna along the LOS it is using (ISRU does something like this, right, it looks at the time interval that has passed, then catches you up?).

You could reorient the spacecraft on scene change or switch, sure, but that might have been more trouble than it was worth to the RT team.  Or the KSP team.

[p1t1o]

FWIW I like RT and will probably stick with it.

[AlphaAsh]

14 hours ago, Geschosskopf said:

I'm just saying that nobody will like the results any more than they have the other stock implementation of so-called 'realism" features.

I like the stock heat, re-entry and aerodynamics. I like the sound of what's coming for comms because it's RoverDude working with Squad. He has a tendency to go for hardcore realism (IMHO) , and Squad will no doubt temper that to something quickly accessible. I like that math. I'm looking forward to it.

[klesh]

I love sticking too many antennae to my probes, I am really looking forward to more options in that department.

I really wish he had some kind of sexy, animated magnetometer.  DMagic has alot of fun looking things in it for that science greeble appeal.

 

Edited June 3, 2016 by klesh
added a picture of them, since we're talking about this

[Bloody_looser]

4 hours ago, Geschosskopf said:

Um, no.

You want to impose your beliefs on others.  You don't like what other people are doing in their own games and want the game changed so they can't do that anymore.  I OTOH believe that everybody should be able to play the game however they want and don't care what others do in the privacy of their own games.  That's kinda the exact opposite of your attitude.

In the situation where the stock game lacks a feature but mods provide it, everybody gets what they want.  Those who don't want that feature don't have to use the mod, and vice versa. . But once the feature becomes stock, everybody has to use it, even those who didn't want it in the first place.  That seems rather harsh to me, which is why I oppose such things.

My belief is that it's SQUAD who defines what is stock. There're mods for pretty damn everything. And yep, they cover planned but not yet implemented features of the core game. SQUAD is really nice to us all and provides continued development. You're preaching for stopping the development right away. Or even that they should've stopped like two years ago - planes, wheels and even landing legs were once only in mods. SQUAD shouldn't have them implemented either?

[tater]

2 hours ago, regex said:

You could reorient the spacecraft on scene change or switch, sure, but that might have been more trouble than it was worth to the RT team.  Or the KSP team.

Yeah, I agree, it just seems like with the new (?) LOS code it might be easier to do---it's like a "control from here" with the antenna selected, and the pointing target being "home." 

[Guest]

4 minutes ago, tater said:

Yeah, I agree, it just seems like with the new (?) LOS code it might be easier to do---it's like a "control from here" with the antenna selected, and the pointing target being "home." 

Wouldn't be hard to do at all, if I'm recalling my maths and KSP's methods correctly (find the vector in scaled space, translate to local space on scene load, etc...) but the real issue is, what does it take to keep it reoriented?  Should it use RCS?  Battery power?  Magical reaction wheels?  Nothing?  To me the only correct answers there are RCS and spin-stabilization.

At the end of the day a re-orient feature is basically just sugar, it doesn't really add anything to gameplay and it might even end up inducing unwanted forces into the craft on scene load, krakens, things like that.  vOv

[Alshain]

2 hours ago, p1t1o said:

FWIW I like RT and will probably stick with it.

Same here, but I won't mind using those new antenna parts with RT. IMO the RT dish antennas are kinda bland.

Edited June 3, 2016 by Alshain

[Laie]

@RoverDude thanks for the heads-up.

It's probably way too late, but I'd like to point out that there's a lot more antenna designs besides stick and dish. I'm especially fond of the corkscrew, but the good old fishbone may be especially suitable for a retractable design.

[Alshain]

27 minutes ago, Laie said:

@RoverDude thanks for the heads-up.

It's probably way too late, but I'd like to point out that there's a lot more antenna designs besides stick and dish. I'm especially fond of the corkscrew, but the good old fishbone may be especially suitable for a retractable design.

You don't see those used in space travel a lot. Fishbone, or Yagi antennas, are primarily used in the High Frequency bands (including Very and Ultra).   Corkscrew antennas are typically low gain omnidirectional antennas.

Edited June 3, 2016 by Alshain

[p1t1o]

I've got a bunch of antennas in my build, damned if I can remember what mods they're from though. Yagi's, helices, masts etc. They're out there.

[Brofessional]

The only way to make RT work in the stock game would be to have some sort of mechanic to automatically "fix" or maintain satellite orbits.

You could have a new menu in mission control or the tracking station that you assign satellites to, then enter the numbers their desired orbit and if the satellite has enough fuel it will be automatically corrected to a "perfect" orbit.

 

I like RT, but right now Hyperedit is basically required to play with RT, as your satellite positions will always drift during long time-warps due to floating point errors.  Otherwise you're going to be constantly tweaking and replacing satellite constellations manually, which isn't fun.

[Alshain]

2 minutes ago, Brofessional said:

The only way to make RT work in the stock game would be to have some sort of mechanic to automatically "fix" or maintain satellite orbits.

You could have a new menu in mission control or the tracking station that you assign satellites to, then enter the numbers their desired orbit and if the satellite has enough fuel it will be automatically corrected to a "perfect" orbit.

 

I like RT, but right now Hyperedit is basically required to play with RT, as your satellite positions will always drift during long time-warps due to floating point errors.  Otherwise you're going to be constantly tweaking and replacing satellite constellations manually, which isn't fun.

Well first, that is complete nonsense.  My satellites don't drift even with decades of time warp.

 

Second the reason RT can't be stock is because with signal delay you need to have the autopilot.  You can't have one without the other.  Squad isn't likely to implement an autopilot.

[severedsolo]

1 hour ago, Brofessional said:

I like RT, but right now Hyperedit is basically required to play with RT, as your satellite positions will always drift during long time-warps due to floating point errors.  Otherwise you're going to be constantly tweaking and replacing satellite constellations manually, which isn't fun.

Sounds more like player error to me. I put satelittes in orbits with matching orbital periods (within 0.01s of each other) and they stay there.

[Laie]

4 hours ago, severedsolo said:

Sounds more like player error to me. I put satelittes in orbits with matching orbital periods (within 0.01s of each other) and they stay there.

Hmmm. I'm hard put to get it within 0.1 seconds, and over time this adds up.

[severedsolo]

3 minutes ago, Laie said:

Hmmm. I'm hard put to get it within 0.1 seconds, and over time this adds up.

RCS fine control is your friend. Having a mod that outputs orbital period to a fine precision helps too. I use MJ for my stats, (which outputs as something like 1h 2m 23.05s. If the numbers match, that's usually good enough (for 1-2 years minimum).

I'm not saying they don't drift at all (they probably do) but it's enough to not be a problem. (I must admit, I do give myself a bit of an overlap window too.)

One trick that I have found helps, is to go to timewarp as it reaches the number you want. When it goes on rails, if you then return to the space centre, it will stay there (provided you never look at that vessel again)

Edited June 4, 2016 by severedsolo

[SorryDave]

Thanks for the clarification RoverDude, I can't wait to try it out in 1.3.

[Dunbaratu]

A proposal for how to do station-keeping much better:  Requires a stock game change, probably:

Realistically, a real space program could both update the station-keeping on their comms satellites while also working on another mission, because two vessels can both be thrusting at the same time, and you have a large organization of people so *some* can be in charge of one task while *others* are in charge of other tasks.  KSP cannot do this, and is unlikely to ever be able to in the future because it would require a massive redesign from the bottom-up to change the notion of "exactly 1 and only 1 vessel is the active vessel at a time".  That is the core cause of the problem with station-keeping in RT.  Autopilot mods, regardless of whether they're the kind you make yourself or the kind that magically arrive already working in a shrink-wrap box, *cannot* fix this because it's irrelevant whether or not you have an automated station-keeping program if the stock game engine refuses to let it make course corrections on the comm satellite in the background while you focus on another vessel.  You have to switch focus to the comm satellite, away from whatever else you're doing, and then make the corrections there in one moment (rather than a proper station-keeping program that would keep corrrecting things continually, not wait for them to get out of whack and then correct them all at once in just an orbit or two).  In kOS we tried as best we could to get around this, but it's just impossible.  A kOS script *can* control a vessel that isn't the active one, but only when it's close enough to be inside the same "physics bubble" as the active one, so it's really only useful for things like docking, not station-keeping your Kerbin comms network while you are orbiting Duna.

Knowing how much of a pain it would be to change the entire design of the stock game to allow multiple active vessels far apart from each other (especially since coordinate numbers on ships fully populated into the physics engine have to be kept small (close by) to avoid the Kraken, which is the entire reason for the physics bubble in the first place) I propose this:

Lock to other object (vessel or body) if close enough to a sync'ed orbit with it:

Allow an option to toggle "station-keep" on a satellite when it gets within a certain very very small tolerance window of the perfect orbit you want.  To "station-keep", you lock the vessel's position to always be relative to another vessel or another body, provided it is already very close to being locked to it already:

• To lock a vessel to a body requires: You are in geosyncronous equatorial orbit with it.  (If you want to get super sophisticated with the time-parameterized equation, you could also allow orbits where the movement is on a predictable cycle, like an inclined geosync orbit that's not equatorial but you know the vessel will describe a north-south cycle shape over the same part of the surface "forever").
• To lock a vessel to another vessel requires: You are in a matching orbit with the other vessel, and have all the same orbital parameters (Ap, Pe, Longitude of the ascending node, inclination) with the exception of one parameter only - your current True Anomaly (or you could express it as a difference only in your current ETA to Periapsis - i.e. WHEN you are in your orbit as opposed to WHERE.  Either way it comes out to meaning the same requirement- your orbit is the same shape and orientation as the other vessel's, just at a different point in time around the orbit.)

Of course, both of these would have to be within a narrow tolerance range  You can't get them *exact*.  Deciding exactly how narrow the tolerances should be would be a gameplay balance question more so than a software question.

Once the "station-keep" locking mode is turned on, all it does is change how on-rails calculations for that vessel will behave.  Where normally when going on-rails you build some time-parameterized formulas where you can plug in the time to get the position and velocity out, here instead you'd remember what the other master object you're slaved to is, and then spit out the position based on a time parameterized equation FROM the other object's position.

If locked to a body, you build a time-parameterized equation that spits out your altitude, latitude, and longitude above that body at a given universal time T, and your position gets locked to the position THAT formula would give you.  If you only allow equatorial geosync locking, then this is trivially easy and they're just constants.  If you allow some cyclical geosync locking, liked inclined orbits, you may have to make it a bit more complex and have it spit out where you are in the lat/long/alt cyclical motion.

If locked to another vessel, all you do is remember a handle to the master vessel and a time offset of how far behind/ahead that vessel in its orbit you are.  (i.e. this vessel is always wherever THAT one would have been 624 seconds ago.)  Then your position is using the same exact time-parameterized formula as the master vessel is, just plugging in a different time.

This way you could put up a network of 4 satellites in which 3 of them are locked to the position of the master one, so they don't drift out of sync over time.

If you want a bit of realism for it you can make it cost a certain small trickle of RCS fuel or electric charge over time to keep the situation like this - small enough that a satellite can station-keep for maybe 15-20 years or so before it has to be replaced.  You could also make this a feature that the earlier probe cores don't know how to do yet.

 

[Nathair]

3 hours ago, Laie said:

Hmmm. I'm hard put to get it within 0.1 seconds, and over time this adds up.

If you're really having trouble you could always cheat. Get your sats up and as close as you can and then edit your persistence file so that the orbit SMA value is the same for each of the satellites in the formation. That should lock them in step.

[Laie]

@Nathair @severedsolo

I'm fully aware of how to use RCS and fine controls. Still, 1/10th of a second is as good as it gets for a GEO satellite, and that requires a lot of back-and forth until I strike it just right. What I do instead is I just use hyperedit:rendezvous with a lead time that corresponds to 1/3rd orbit (or whatever, according to need). Much more convenient than hacking the savegame.

Now, 0.1s in GEO is good for a long time. One could argue that I shouldn't play with RT if I'm unwilling to look after my satellites every decade or two... but that's another topic for another day.

[Violent Jeb]

11 hours ago, severedsolo said:

Sounds more like player error to me. I put satelittes in orbits with matching orbital periods (within 0.01s of each other) and they stay there.

with the orbital decay bug? don't think so. Not in my save at least. It was tedious before 1.1 and i don't see it as possible now, unless you get the craft to the right period, and immediately put it on permanent rails. Either way I have orders of magnitude more fun with Scansat than I ever did with RT. But thats just me.

[RoverDude]

Comparing SCANSat to RT is like comparing apples to tractors