scimas

Hey devs, are you aware of this (https://github.com/KSP-KOS/KOS/issues/2328) bug with KOS - RT interaction? From the comments in that thread, it seems like the cause is how remote tech works. Is there any chance of a fix?

Ah, thanks for pointing that out. That's exactly the issue I'm experiencing. Time to see if knocking on RemoteTech devs' doors gets any progress on the issue..

I have a rocket with a command pod manned by a pilot, it has an antenna (activated) and it's sitting on the launchpad. Is it expected that ADDONS:RT:HASKSCCONNECTION(SHIP) will return false in this case? Yes, I do have local control, but I would still expect it to return true. I want to know if I can copy files over from archive or not.

Yeah, boot script works. I was just wondering if it was possible to have it deactivated right from VAB, like extendable antennas. But it isn't a big deal.

Is there a way to have a processor turned off when launching a rocket from KSC?

Actually that changes it a lot. The burn time changes exponentially with the required delta V. I suggest taking it into account. Look up the specific impulse and terminology pages on the KSP wiki. Those two have all the additional equations you will need for delta V and burntime calculation.

Yeah, if I remeber correctly, principia doesn't touch a craft's rotation at all. But I understand off center CoM causing pitch and yaw issues, I can't imagine what would cause roll problems. Unless the engines are placed to deliberately produce rolling torque. You would need both off center CoM and a thrust vector unparallel to the heading vector. Basically an offset AND rotated engine.

If you want only axial tilt, check the starmods post in Daily Kerbal forum. The Tilt'em mod is supposed to do exactly that. It is a very new mod, so read through its thread for known bugs and stuff.

I think it's more along the lines of "work is being done, we are aware of it. But our legal/pr hasn't decided what to release to the public." Of course a simple "News about Console version will be available in a few weeks" should have been better in one of the previous few weeklies..

@N70 or whoever else is maintaining this mod, CKAN is currently installing the 1.3.1 version 1.9.0 for this mod on 1.4.5 KSP.. Please get this fixed, I spent so, so much time figuring out which mod was causing problems to kerbalism

@linuxgurugamer Wanted to point out that Toolbar Controller is not listed as a dependency on CKAN. It has worked properly until 1.4.3 and I spent 2 days figuring out which mod was causing AGExt to not load in 1.4.5

@passinglurker just a humble suggestion. Please proof read your posts. For all the good insight in your contents, you miss a lot of punctuation and capitalization. It becomes difficult to figure out where one sentence ends and another starts.

I mostly like it. But the difference in reflection is still too much, just like the OKTOs. The foil reflects like there's a bulb inside the foil and the non foil surfaces don't reflect at all. They look totally flat. Perhaps make them a bit more reflective, or make the edges a bit more pronounced.. Somehow bring those other surfaces out of flatness.

kOS (or any other mod) can only create stock nodes, not the principia ones. The MechJeb devs are working with the principia devs to make the principia data available to other mods (better ask in the principia thread about this, they can tell better). At that point if someone creates a principia addon for kOS, you will be able to do all kind of stuff. Until then you still can sort of access the principia nodes. When you click "show on navball" in principia, it creates a stock node that's continuously updated (except that its delta v doesn't tick down). So, although you can't create a node or edit it from outside of principia, you can partially access it and do things like 1. point in the maneuver direction 2. wait till execution time 3. whatever else you come up with that doesn't involve changing the node itself with kOS.

What else are they supposed to do? Blitworks might be working on the console version, but they aren't separate from Squad as far as KSP is concerned. The console players bought the game from Squad (might be owned by T2 now, but originally Squad). And this is a forum for all KSP players, not just KSP PC players. Until and unless Squad/T2/Blitworks decide to open a different forum for console players, this is the place for them to praise, complain or whatever.

That's more like it. Devs / Art people, go and compare these OKTOs to the HECSs for yourself. These look so much better. Was it a deliberate decision to keep the sides of the OKTOs non-foil shiny? A little more light reflection from those surfaces might be good. Right now the sides look a bit flat. Then again this might be my personal preference. The Mk1 pod looks great too. The hatch - pod boundary could be a bit more defined on the dark variant.

As far as I know principia does not draw the orbits of planets, only of ships and asteroids.

I didn't really want to get into this argument, but this doesn't make sense. I understand that motivated artists do beeter work; in fact that is not limited to artists at all, it's true for everyone. But you can be motivated to make better art than your predecessors even when you're required to stick to a style. These artists aren't doing their own thing, they're working for KSP. If a style is decided for the game then they have to stick to it. If they don't want to stick to it, they need to change every single part to match their new style. I'm in no position to decide which style is better, but I can certainly understand the logic behind choosing and sticking to one.

Could you please ask whoever is writing the post to use the phrasing "mostly completed" from next time? It makes clear that the art team is happy with what they have done but are also open to make changes depending on feedback. Just asking to avoid the finality that "completed this work" expresses.

Okay, the texture on its own looks better, but as others have pointed out, it looks too much like monopropellant tanks. And the repeated texture on hammer just doesn't look good, make at least small changes to it. Right now it looks like two fleas stacked on each other, with one nozzle removed.. Give them something unique of their own. The end caps look nice, perhaps the nozzles could be detailed a bit too? Don't know what to feel about this though.. @SQUAD are you saying in advance that you don't care what the players think about the work done? That nothing is going to change no matter how much the player base hates or likes things?

The new version of HECS 2 actually looks worse to me. Now wait, I'm not saying all of it is bad. But the whole time I couldn't focus on anything but the gaping black hole on top. It's like the old gold foil was 'okay' and the old end cap was 'okay' so the result overall was 'okay' too. With the new version the gold foil is 'whoa photo realism' and the end cap is 'why is my paint drawing a part of KSP now?' The contrast in the quality actually makes it an eye sore.

Yeah, I understand. I've been around since 1.2.2 and suspected as much. That is why I'm not complaining all over the forums about it. Only mentioned it here because the topic popped up. It's just that there was noticeable performance difference for me when using dx11. And so it not working with 1.4.x was a big disappointment.

And Squad dropped dx11 support with 1.4 release, which is one of my biggest issues with that update. I don't know whether dx11 was ever officially supported or not, but nothing used to brake when using it in upto and including 1.3.1.

That doesn't work as you would expect. The orbit calculated by principia isn't exposed outside the mod. So the contract system just checks everything against the stock orbits. And that means that sometimes, even though your principia drawn orbit looks exactly like the one you need, the stock orbit is very different and the contract isn't fulfilled. This is usually only a problem in high orbit, not in low orbits where patched conics and n-body are more or less identical. Check out principia's faq. It turns out that n-body calculations is sometimes easier on your cpu than patched conics calculations. The faq talks about orbits of planets, not vessels, so I'm not sure whether the same argument applies or not.

Yup, agree with @nanomage. Looks like you were doing plane change burn, but didn't keep the flight planner window opened. That leads to the maneuver direction not changing during the burn. Another cause could be that you executed a decoupling staging or enbled / disabled engines after making the flight plan. That messes up the calculations too.