Antennae revealed on Squadcast

[Errol]

What about signal delay. I know that you are not a fan of signal delay, Rover, and that you are a fan of abstracting things for ease of gameplay reasons. But with the new SAS features in 1.0, would it not make sense to simply add the ability to fire engines for a specified about of time when a manoeuvre node is reached?

[AndyMt]

I actually like the form factor and the model side of the antennas. Just as some others I don't like the dark grey colour. Personally they seem just too dark, you won't see much of them while in space... Have a little shiny effect on the inside of the dish and make both sides lighter - the stick part as well. I'm fine with the orange/brown and red elements.

We need some colour on the parts, otherwise our spaceships would just be shades of grey ...

[Just Jim]

I like it

Edited September 14, 2015 by Just Jim

[RoverDude]

@Errol, no signal delay.

[cantab]

My thought is that signal delay makes KSP, at least the probe side of it, a completely different game. It ceases to be about flying spacecraft and turns into a game about programming a robot.

[klesh]

I guess thats a "no" to the antenna extension bug being fixed?

[Guest]

Spaceship parts are built in a cleanroom.

I agree with this completely. I brought up the lack of consistent art style elsewhere, (hello single orange tank in a sea of white, black, and grey) but it should be restated. Half the parts in this game are clean, crisp, white, and black. The other half are orange, grey, rusty, and held together with rivets. Personally, I think each part manufacturer should have their own consistent color scheme.

For example, Rockomax parts would look like rusty 55 gallon drums held together with rivets. Why? Because Rockomax cares more about size and power than aesthetics. While you're at it, why not make ALL Rockomax tanks orange? (Hello texture sharing and memory savings!)

Meanwhile, the Kerbodyne parts seem to offer a good example of consistency, the small tank is white with black stripes, the medium tank is solid white, and the large tank looks like they took the small and medium tanks and welded them together.

Yes all parts quality should be improved and brought to a consistent level, and all parts texture efficiency should be improve as well, but by no means should they all be given "the same glossy paint job" so to speak.

Well, when people are building rockets these days, they tend to buy 500,000 gallons of "Industrial White" paint and use that on all their rockets, instead of buying 15 different shades of grey, black, orange, and white. I'm not saying the game needs to do that, but more consistency would be nice.

I consider the artwork of the rockets 2nd priority. Let them first get rid of the bugs, optimize the game and finalize features, then make a good pass over the art work. I also am no fan of these grey-ish mush-like textures. While I appreciate those parts were "found lying by the side of the road", I think a bit more "rocket-ish" look would be nice indeed (same quality such as the SPP parts for instance).

Yes, absolutely. I might complain a bit about art style, but by all means get the game engine out of the way first, then worry about retexturing it.

It's not a realistic game, it's a simplified and more cartoonish version of real space flight, and the art fits that idea just fine, if you like it or not.

Of course a lot of the parts are from old versions of the game and don't look that great, but Squad is a small developer and replacing modells takes time.

As for a more realistic style, there are mods, there always have been mods, and there always will be mods for people who want to customize KPS to their liking. That's a total non-issue.

If the game is simplified and cartoonish, then the art style should be simple and cartoonish. The fact is, we're stuck with a curious mixture of colors and styles that are not all one thing, or all the other.

There's no need to replace part models, just redraw the textures. One person with some "mad photoshop skills" could probably retexture the whole game in a couple weeks, maybe less.

The answer to problems or issues present in the base game is to fix the base game, not 'get a mod'. I want to support the developer, offer constructive criticism, and encourage them to make the best product possible, not throw my hands up in frustration and go mod the game. Once you go 'grab a mod' you're no longer invested in the base product, because you can rely on a modder to 'fix' everything.

It's the same with people who go out and play Realism Overhauled, and other total conversion mods. You're not playing 'Kerbal Space Program' anymore, you're playing the mod loosely based on 'That Game You Bought'.

No offense intended.

- - - Updated - - -

And as far as the new antenna goes, I like it.

[NecroBones]

Needs more white.

It needs more cowbell.

[KSK]

Either is acceptable.

Maybe that depends on country and industry. As far as I know, in the UK, antennae are for insects but antennas are what you find in your mobile phone.

Source - my partner, who used to design them (in various contexts) for a living.

[The_Rocketeer]

As far as I know, in the UK, antennae are for insects but antennas are what you find in your mobile phone.

Who says Kerbs aren't evolved from insects?

Also, if you've got a satellite dish on a broomstick in your cellphone I think you've bought a Krapple by mistake.

[Superfluous J]

Actually, there are specific plans in place to address probe control while occluded (subject to QA/Experimentals feedback, etc.)

I may have just had one of your babies.

[cfds]

Well, my only hope for the new antenna behaviour is that it does not interfere with Remotetech. The proposed model sounds like too much for people who do not want do deal with antennas and far to little for those who use Remotetech (if only for the flight computer ).

[godefroi]

My thought is that signal delay makes KSP, at least the probe side of it, a completely different game. It ceases to be about flying spacecraft and turns into a game about programming a robot.

Exactly. RemoteTech's computer is mildly interesting, and mostly frustrating. Signal delay without proper tools to handle it (and RT's computer isn't it, IMO) isn't fun.

I think that handling occlusion could be as simple as a new SAS mode called "execute nodes".

[Frozen_Heart]

I do quite like this new model, though as someone pointed out earlier, the colours need to be lighter to match the current aesthetic.

Really don't understand why people think it looks so unrealistic. I looks just like the Hubble one...

[tater]

My thought is that signal delay makes KSP, at least the probe side of it, a completely different game. It ceases to be about flying spacecraft and turns into a game about programming a robot.

"Programming a robot" in KSP should be trivial.

1. Make a maneuver node (with light delay, if that was a thing, the node would need to be no sooner to current position than the lag).

2. Done, as the probe, being a probe, would simply execute the node when it gets to it.

[godefroi]

I think it looks great. The fact that it's on a long folding boom is great; it makes it easy to get it out of the way of other stuff.

I play RemoteTech (without signal delay), and one of the issues I run into is getting several long-range antennas put together on a single relay craft. They either end up very wide (large antennas at the end of girders) or very tall (large antennas on opposite sides of a tall tower). Either way it's a bit unwieldy, and this kind of arrangement would help immensely. Hopefully we can get something like this for large interplanetary antennas.

- - - Updated - - -

"Programming a robot" in KSP should be trivial.

1. Make a maneuver node (with light delay, if that was a thing, the node would need to be no sooner to current position than the lag).

2. Done, as the probe, being a probe, would simply execute the node when it gets to it.

Probes should be able to execute nodes without a connection; creating a node can/should require a connection, but execution shouldn't.

[cantab]

"Programming a robot" in KSP should be trivial.

1. Make a maneuver node (with light delay, if that was a thing, the node would need to be no sooner to current position than the lag).

2. Done, as the probe, being a probe, would simply execute the node when it gets to it.

If you can make a soft landing on Vall using solely automated manoeuvre nodes I'll be seriously impressed. If you can then extend your solar panels, perform science experiments, and transmit the results to Kerbin all using solely automated manoeuvre nodes I'll wonder just how insanely buggy KSP is that that's even possible.

[godefroi]

If you can make a soft landing on Vall using solely automated manoeuvre nodes I'll be seriously impressed. If you can then extend your solar panels, perform science experiments, and transmit the results to Kerbin all using solely automated manoeuvre nodes I'll wonder just how insanely buggy KSP is that that's even possible.

If you can do that with RT's flight computer, I'll be just as impressed. You'd need kOS for that, unless you were willing to do a LOT of trial and error. If you had a connection to transmit science, though, you'd have the connection that (given RT and AntennaRange's rulesets) would allow you to do the landing manually.

[tater]

If you can make a soft landing on Vall using solely automated manoeuvre nodes I'll be seriously impressed. If you can then extend your solar panels, perform science experiments, and transmit the results to Kerbin all using solely automated manoeuvre nodes I'll wonder just how insanely buggy KSP is that that's even possible.

Maneuver nodes in KSP really take the place of kerbals with slide rules and computers figuring out the maneuvers, and typing them out for distribution (or downloading them) to the spacecraft.

We'd need more robust nodes, that include atmospheric effects, and are accurate down to X meters. Note that "X" could be a function of the amount and type of "science" you have generated on the target world. Send a hi-res mapper to get better elevation data, for example (science that would actually be useful, go figure). You could then place a "landing" node for the craft, etc.

I think it's totally doable with the UI we have, but with some specific enhancements.

There could also be new parts, like "Landertron" that provide radar-altimeter based retrorocket fire. Perhaps with the ability to "fire until X m/s decent rate" and various altitude toggles as well (drop to 10m/s at 1000m, then 5 m/s at 10m, etc.

Edited September 14, 2015 by tater

[Fearless Son]

Myself, I like the new antennas but then I tend to put gameplay over aesthetics anyway.

My only question is how are we going to do capture burns with unmanned craft on the far side of a planet?

I REALLY don`t want to have to send two craft for each mission or be forced to send a kerbal first...

That would be lame.

Send one craft in two-parts. One of those parts is as small and light as you can make it transmission relay. Detach it well ahead of your normal burn point and start its burn early. Get it into a high elliptical orbit, so it has enough distance to trace line-of-sight to both Kerbin and the other probe. Once you have both settled into relatively stable orbits, you can do some correction burns on the relay to get it into an ideal position.

Better yet, send two relay probes with your explorer probe and have each end up on opposite ends of your orbit, so you have at least one in sight of Kerbin at all times.

[Errol]

What if some of us want a game about programming robots? I'm ok with not having an implementation as intense as remote tech, that's what remote tech is more.

I really like the direction rover took LS when he decided to do his own LS instead of using TAC as the main LS system. I would love to see what he comes up with for adding a bit of difficulty to interplanetary transfers. Even if it were just a bit of lag added in or something.

[tater]

Lag is a really bad idea without the mechanisms used on real spacecraft to deal with this. Probes need to be able to execute nodes, basically. Landing ops require far more predictive node creation (since in RL you can calculate pretty well where things will end up, even in atmospheres), and/or specialized node types for certain functions.

This is where "real" science would be a great addition. Have something akin to scansat, where you generate maps based upon passes by instruments of different resolutions (orbital mappers, crasher probes like Ranger, landers, and manned missions, etc). Then allow map mode zoom based upon the level of scanning done for that area. If you can zoom down near 1:1, then perhaps any maneuver node placed within XX meters of the surface is automatically changed to a surface, "landing node." Stretching retrograde then has the surface velocity decrease that you can see. Set it to 1 m/s or whatever, and you've made a landing node (you'll be at 1m/s upon hitting the node, these nodes would assume that the burn starts at the exact time indicated, which will be set back from the landing, so if it is a 1 minute, 37 second burn, the timer clicks down to "0," and you hit Z (or the probe core does automatically), and at t=+1:37 you are at 1m/s and on the ground). It might be set such that t=0 (landed) is actually a few meters above the surface, or that can be a setting.

[Superfluous J]

I'm totally cool with "Programming the robots" being something left to mods, though it'd be nice to be able to drop an "instruction node" onto an orbit and do things like "Do all science" or "Pull the chutes" or "Align retrograde," as well as "do this maneuver node."

[BlueCanary]

If this unfolds fast enough could it be used as a kerbal catapult?

[LostOblivion]

if this unfolds fast enough could it be used as a kerbal catapult?

o.m.g.