Devnote Thursday: Tweaking and Turning Gears

[AlamoVampire]

Side thought if a maneuver is out of sight and being done on a flight comp like mechjeb or kos or remote tech will that allow for throttle control or force an all or nothing throttle? If it forces only full stop or 100% even if the burn is set for say 3 minutes at 7% but no active link a full throttle burn will break the mission especially if its the first or second sat up but the ksc is beyond line of sight.

IF thats the case proposed change Is game breaking and needs adjustments 

[adsii1970]

1 minute ago, Alshain said:

It's not as glamorous as it sounds.  It's actually fairly tedious as you often end up doing the same tasks repeatedly, hundreds of times.  It's not just a matter of playing the game and hoping something breaks where they can see it.  They go out looking for problems.   I am a professional software tester, so I know what this entails (though I don't do games).  I know nothing about this company, but assuming they are a good one then they know exactly how to attack the testing situation.

Yeah, I know. Was a beta tester when I was in college for some programs... I was just trying to be humorous

[RoverDude]

15 minutes ago, AlamoVampire said:

6th? Also probes are now all or nothing in throttle? Wt heck? How can you fine tune orbits using only a sledge hammer now?

If your probe has control, you're fine.  The control locks only kick into play when you lose your connection (via occlusion or lack of signal strength).  By the way, I was able with the auto pilot to very creatively align to a node, even when occluded - was just a bit tricky   of course your best bet is to make sure you have signal and pre-align.

14 minutes ago, DaMachinator said:

Will this break scripted autopilot mods like kOS and kRPC? I like seeing my scripts continue to execute properly even after signal loss when playing with RemoteTech, it gives a unique feeling of accomplishment. (It also feels more realistic, but that's not the primary attraction for me.)

Nope, these are control locks, so your mods should be fine

12 minutes ago, AlamoVampire said:

So some form of link still gives full throttle ranges?

Correct - if you have a good signal, your probes operate just like they do today.

7 minutes ago, AlamoVampire said:

Hope its true or its a step backwards. Some mods require some serious precision in orbital maneuvers and making probes either full stop or full go is gonna hurt mods 

Mods will be fine, I expect @NathanKell can provide more detail as he was the coding wizard that updated the control locks

3 minutes ago, adsii1970 said:

Yeah, but think of it this way...they get paid to play KSP...

I sure hope this is the case. Will there be a way to toggle back to the less real version of satellite communications? I play on an older machine and am not sure it could handle creating a huge network of communications satellites and stations to continue exploring the Kerbol system...

It's a toggle in your game settings.  You can even change it in-game if you so desire   Tho you really are not going to need a large relay network other than to avoid occlusion issues, given Kerbin has a pretty nice built in DSN.

3 minutes ago, FullMetalMachinist said:

@AlamoVampire the control limitations are for when the probe core or pilot-less ship does not have connection to either Kerbin or another control point. 

(bold mine) I assume that this means that when they do have a connection or pilot, then they will have full control, i.e. what we currently have now. 

This is correct

2 minutes ago, AlamoVampire said:

Side thought if a maneuver is out of sight and being done on a flight comp like mechjeb or kos or remote tech will that allow for throttle control or force an all or nothing throttle? If it forces only full stop or 100% even if the burn is set for say 3 minutes at 7% but no active link a full throttle burn will break the mission especially if its the first or second sat up but the ksc is beyond line of sight.

IF thats the case proposed change Is game breaking and needs adjustments 

Your mods will be fine, we are only locking the input controls.

[AlamoVampire]

@RoverDude My concern is more with the thing going bonkers and burning harder and longer than intended. Like i said, say i have a ship going to another ship and the rendezvous happens outside of an active link, but i told mechjebs rendezvous comp to arrive and hold 5 meters off my target. An act that needs way less than 100% throttle near end. If the autopilot or script has the commands already they should function as expected even with 0 signal?

 

edit: been an exceedingly bad day for me. Hence the picky nature here  just seeking my own clarity in my fog

Edited August 25, 2016 by AlamoVampire

[Shadowmage]

36 minutes ago, SQUAD said:

[...]

Nathanael (Nathankell) fixed outstanding issues with deployable parts: solar panels, radiators, antennas, and so on, and fixed a long-standing issue with Kerbals sliding on ladders. As it turns out this issue was linked to orbits, where Nathanael refactored the way in which vessel stats and orbital data are calculated each frame. An important note for modders is that the CoM and other vessel stats are now correct for the physics frame in which they occur. Vessel movement going on and off rails has been mostly eliminated, solving a persistent and noticeable issue. All forces except those for ragdoll Kerbals and wheels are now tracked and only applied by the flight integrator, and no longer at the PartModule level.

[...]

@NathanKell

How will this change to physics forces-applied-by-flight-integrator effect things like mod-added physics-based parachutes or mod-added wheel systems that currently use rigidbody.addForce()?  (E.G. RealChutes, or the upcoming KerbalFoundries wheel-collider replacement component)

Or, essentially, will there be API-accessible methods added to FlightIntegrator for PartModules to still add physical forces to parts/vessels?

 

[DaMachinator]

7 minutes ago, RoverDude said:

If your probe has control, you're fine.  The control locks only kick into play when you lose your connection (via occlusion or lack of signal strength).  By the way, I was able with the auto pilot to very creatively align to a node, even when occluded - was just a bit tricky   of course your best bet is to make sure you have signal and pre-align.

[snip]

Your mods will be fine, we are only locking the input controls.

Oddly enough, I think MechJeb somehow respects input control locks. Either that, or it has special handling for RemoteTech. I know Pilot Assistant does, but that's irrelevant.

It appears probes will still be functional. If the targeted SAS works properly now (e.g. it starts stopping rotation BEFORE it gets to the target point) it will be entirely usable, albeit finicky. If the RCS can be USED, rather than just toggled, you can use RCS for fine adjustment.

 

[Superfluous J]

Awesome devnotes. Love the orbit stuff and ... well I'll wait patiently to see the telemetry stuff in action, but it sounds like it'll add interesting choices and options for missions. And no more sliding on ladders! Can't wait.

40 minutes ago, Jarin said:

Any word on PorkJet's work with the rocket-part models?

There it is. Who had "Reply #6" in the betting pool?

[NathanKell]

@Shadowmage yes indeed. The only exception is that I did not bother to add ForceMode.VelocityChange or ForceMode.Acceleration; you will need to convert yourself before passing. I did implement ForceMode.Immediate because it's just (force / deltaTime). It's exactly about making an API, both for us and for you to use. Since it's just wrappers, I paste them below. (RigidBodyPart is the first part up the chain that has a valid rb, so you can AddForce to a part without one and it'll still be fine, just as now you part.Rigidbody.AddForce instead of part.rb.AddForce.)

For wheels, however, I suggest you continue to use the current method, since as I said in dev notes we're not doing it for wheels either (since they can best be considered a collision force, and collision forces in general are internal to PhysX and so go untracked/unapplied-by-FlightIntegrator).

    /// <summary>
    /// Adds force to the part's (or parent's up the tree) rb.
    /// NOTE: ForceMode == Force. If you want a different mode, convert to ForceMode.Force.
    /// </summary>
    /// <param name="vec"></param>
    public void AddForce(Vector3d vec)
    {
        RigidBodyPart.force += vec;
    }

    /// <summary>
    /// Adds force to the part's (or parent's up the tree) rb as an impulse (i.e. divides force by fixedDeltaTime
    /// </summary>
    /// <param name="vec"></param>
    public void AddImpulse(Vector3d vec)
    {
        RigidBodyPart.force += vec / TimeWarp.fixedDeltaTime;
    }

    /// <summary>
    /// Adds force to the part's (or parent's up the tree) rb, at the specified position.
    /// NOTE: ForceMode == Force. If you want a different mode, convert to ForceMode.Force.
    /// </summary>
    /// <param name="vec"></param>
    /// <param name="pos"></param>
    public void AddForceAtPosition(Vector3d vec, Vector3d pos)
    {
        RigidBodyPart.forces.Add(new ForceHolder(vec, pos));
    }

    /// <summary>
    /// Adds given torque to the part's (or parent's up the tree) rb.
    /// NOTE: ForceMode == Force. If you want a different mode, convert to ForceMode.Force.
    /// </summary>
    /// <param name="vec"></param>
    public void AddTorque(Vector3d vec)
    {
        RigidBodyPart.torque += vec;
    }

 

 

@AlamoVampire, @DaMachinator, et al: No, MJ does not respect input locks. If it did it wouldn't work, since it sets them itself. What it does is offer a hook which other mods can use to tell MJ to disable itself. That's what RemoteTech does. So, just to reinforce again and be perfectly clear: these locks will not interfere with mods. Period. We are not setting a flybywire controller, we are not locking actual actions (just GUI actions and keypresses).

[DaMachinator]

\o/

*rides hype train*

[Kerbuvim]

Damn! No one word about PS4 issues. They absolutely ignore us.

[MaxPrime]

3 minutes ago, Kerbuvim said:

Damn! No one word about PS4 issues. They absolutely ignore us.

Well it's only been a month and a half, it's not like we paid for something that doesn't work.

  These notes are awesome though, really like the direction ksp as a whole is taking. Only hope we see some of these on console eventually

[AlamoVampire]

4 minutes ago, Kerbuvim said:

Damn! No one word about PS4 issues. They absolutely ignore us.

From what i saw they left a bunch of stuff out. Id wager ps4 isnt ignored

[Armisael]

Will this patch include a change to make fuel crossfeed work on radial decouplers at all? Right now I can't get fuel to flow in any direction regardless of the toggle setting.

[Shadowmage]

9 minutes ago, NathanKell said:

@Shadowmage yes indeed. The only exception is that I did not bother to add ForceMode.VelocityChange or ForceMode.Acceleration; you will need to convert yourself before passing. I did implement ForceMode.Immediate because it's just (force / deltaTime). It's exactly about making an API, both for us and for you to use. Since it's just wrappers, I paste them below. (RigidBodyPart is the first part up the chain that has a valid rb, so you can AddForce to a part without one and it'll still be fine, just as now you part.Rigidbody.AddForce instead of part.rb.AddForce.)

For wheels, however, I suggest you continue to use the current method, since as I said in dev notes we're not doing it for wheels either (since they can best be considered a collision force, and collision forces in general are internal to PhysX and so go untracked/unapplied-by-FlightIntegrator).

 

[...]

Excellent

Thanks for the quick response, and your ongoing hard work!

 

 

[adsii1970]

6 minutes ago, Kerbuvim said:

Damn! No one word about PS4 issues. They absolutely ignore us.

No, they are not. There's simply nothing to report on. This set of devnotes dealt mostly with the PC version. As has been stated numerous times before, once Squad does make the updates needed those same updates must be approved by the console's manufacturer/game distribution system.

Squad is aware of the numerous issues and to simply say they do not care about PS4 players is not only unfair, it is dishonest. This company has always supported those within the KSP community better than any other I've seen.  Just give them time.

14 minutes ago, NathanKell said:

For wheels, however, I suggest you continue to use the current method, since as I said in dev notes we're not doing it for wheels either (since they can best be considered a collision force, and collision forces in general are internal to PhysX and so go untracked/unapplied-by-FlightIntegrator)

[edited by adsii1970 for relevant content]

Huh? Did I miss something? I thought wheels were supposed to be repaired in 1.2. Is this a change or am I misunderstanding something...

[NathanKell]

3 minutes ago, adsii1970 said:

Huh? Did I miss something? I thought wheels were supposed to be repaired in 1.2. Is this a change or am I misunderstanding something...

These two statements are...not related at all. All I was saying, as I said in the dev notes themselves, is that wheel forces are not shifted over to Part.AddForce. And in the bit you quoted I suggested Shadowmage do the same. When wheel forces are added to the rigidbody in a fixed frame has zero to do with whether the forces are correct. It's just bookkeeping.

[adsii1970]

4 minutes ago, NathanKell said:

These two statements are...not related at all. All I was saying, as I said in the dev notes themselves, is that wheel forces are not shifted over to Part.AddForce.

[edited by adsii1970 for relevant content]

Thanks for the clarification. I simply skimmed over them, hitting the high spots. When I saw your response, I was confused.

[Shadowmage]

15 minutes ago, Armisael said:

Will this patch include a change to make fuel crossfeed work on radial decouplers at all? Right now I can't get fuel to flow in any direction regardless of the toggle setting.

There is a setting that needs to be toggled in the...physics globals? config file in order to enable the radial-crossfeed functionality.

Hmm.. let me see... think I have a patch for it somewhere...

@PHYSICSGLOBALS
{
	@stack_PriUsesSurf = True
}

 

[Curveball Anders]

1 hour ago, EladDv said:

No Haiku from @sal_vager 

As Thursday roll
Users are waiting
Next week might be

Edited August 25, 2016 by Curveball Anders

[katateochi]

Sounds like some very positive progress! As a long time fan of remote tech I'm really looking forward to seeing how the comms systems work and that screenshot made it look like familiar territory.
Is there any scope for setting up 'actions' while a probe is in range for it to execute once it's out of range (like you can with remote tech)?  One of my fav things in RT was setting up wildly miscalculated/mistimed maneuvers and then watching helplessly as my probe fired its engines at precisely the wrong moment. (but seriously, when they were setup right it was very satisfying, so to have this in stock would be great). 

[AlamoVampire]

Thought i saw some mention on landing legs/gear but cant find it. But ill ask anyway: will landing legs, feet and gear now in 1.2 be stout enough that kerbals (in some cases) make them pop by simple contact and will the legs that experience detonation on even the slowest touch downs ( less than 0.5ms) be fixed? Makes eva near landing legs and gear scary atm

[pandaman]

Good devnotes, definitely worth the wait.  Thanks.

The last few have been very encouraging for what the future holds

Looking forward  to 1.2 and beyond.  Thanks. 

Edited August 25, 2016 by pandaman

[eddiew]

Is it bad that I'm most excited about the changes to orbit markers?

Srsly though, it's such an annoyance in 1.1 when you can't have a close approach until you're within a few tenths of a degree of the right inclination, this is going to be such a fantastic change  

...not so sure about reduced probe control. I feel like the top tier cores should be considered bleeding-edge autonomous and have no problems with touching down on vacuum bodies without a connection to home. Heck, NASA got Viking down on Mars with 0.1% atmospheric density, it can't be impossible for kerbals... Do what you want with the Stayputnik, it's dead to me already  

[Andem]

So, how similar will it be to AntennaRange v.s. RemoteTech2?

[Waxing_Kibbous]

I'm excited for Kerbnet, I think it's a really good, and logical, step forward in terms of gameplay