Devnote Wednesday: Tuesday Edition

[John FX]

2 minutes ago, Mitchz95 said:

Mine has a 2.4 GHz Intel Core i5. Is that okay? Can it be replaced/upgraded?

I appreciate all the help, guys!

The thing that matters more is the ability of your graphics interface. Usually you can`t upgrade a CPU or graphics in a laptop unless you but one that is specifically designed for it. Often the processor is hard wired in, not in a socket and the graphics are part of the motherboard too. A lot of laptops have intel 4000 graphics which will run KSP at low texture resolutions with the settings lowered at a reasonable frame rate.

A 2.4Ghz I5 is OK for KSP, it`s not the worst, it`s not the best.

[NathanKell]

1 hour ago, CobaltWolf said:

@NathanKell what changes if any have been made to the dockingNode module? I'm starting to work on some now and I wanted to know if there was anything I should be aware of.

@taniwha would be best placed to answer that one.

[John FX]

3 minutes ago, llanthas said:

Yeah, replacing a processor is a challenging task, even for experienced builders working on a desktop.  There is no room for error in a laptop.  You're much better served by just waiting for the 1.1 update, and seeing what it does for your performance. 

In general though, if you're going to be gaming on a laptop, you will most definitely need a Dedicated graphics card. 

I`m just wondering if external cards for laptops are a thing or whether I have just imagined them.

*googles*

Ah yes, they are a real thing although which you can use seems to depend on your exact laptop. Some use expresscard, some need a power supply, some give you a proper GFX card slot that you can put a desktop card into.

[CobaltWolf]

2 minutes ago, John FX said:

I`m just wondering if external cards for laptops are a thing or whether I have just imagined them.

*googles*

Ah yes, they are a real thing although which you can use seems to depend on your exact laptop. Some use expresscard, some need a power supply, some give you a proper GFX card slot that you can put a desktop card into.

Yeah basically the only laptops that still have the kind of slots you'd need to the throughput are Lenovos IIRC. I looked into it once. Not many options.

@NathanKell thanks! Since you tagged him I suppose I'll just wait till he shows up instead of pestering him.

[Mitchz95]

Thank you guys for all your help! Sorry for derailing the thread.

[Archgeek]

18 hours ago, NathanKell said:

Gimbal code was sped up by rewriting it to use fewer quaternion ops. A happy upside is that gimbals can be constrained individually in X and Y, though it does require that gimbal transforms obey the same orientation as thrust transforms (i.e. gimbal transform needs Z along the thrust axis).

So still no lowered or tweakable gimbal rates of yet.  Blast.  Here I was hoping for a reduction in SAS instability and cosine losses from them moving their full range in a single physics delta without just constraining the crud out of 'em, giving up their maximum authority.

[FullMetalMachinist]

3 minutes ago, Archgeek said:

So still no lowered or tweakable gimbal rates of yet.

Claw's Stock Bug Fix Modules comes with StockPlus, which, among other things, let's you set gimbal response rate. 

 

[Archgeek]

Just now, FullMetalMachinist said:

Claw's Stock Bug Fix Modules comes with StockPlus, which, among other things, let's you set gimbal response rate. 

 

Yes it does.  That module is how I found out just how much it rather needs to be stock.  Insta-gimbaling is insane, and can easily prevent otherwise reasonable payloads from reaching orbit.  It also severely reduces the usefulness of certain pilot abilities.  Ever tell a pilot or a probe to hold prograde for a minmus injection from a tight parking orbit with an LV-T 45 or worse, a Vector?  The difference the dampening of a finite gimbal rate makes is so tremendous, it should really be stock.  Not necessaryilly the tweakability, mind, but the property of being finite -- such that the SAS has time to rescind or alter its input before the change gets quite out of hand.

Plus, now that Claw's onboard, I'm rather surprised he hadn't gotten a chance to implement it yet.  Now where'd that appostrophe come from?

[FullMetalMachinist]

3 minutes ago, Archgeek said:

Plus, now that Claw's onboard, I'm rather surprised he hadn't gotten a chance to implement it yet.

We actually don't know that for sure yet. He may have, and we just haven't heard. Though I'll admit, that doesn't seem too likely. 

But honestly, I think just about any discussion about what should or shouldn't be stock is pretty moot at this point, at least as far as 1.1 is concerned. Squad has likely long decided what will and will not be included. 

[maceemiller]

For me this is the best Dev note yet. Loved reading every word and just made me smile. Felt good

[taniwha]

3 hours ago, CobaltWolf said:

what changes if any have been made to the dockingNode module? I'm starting to work on some now and I wanted to know if there was anything I should be aware of.

I added an extra state for the dockee node such that it's not in a docked state until it actually is docked (instead, it's in a passive acquire state), and both sides do a better job of finding the other node when needed. If a node can't find its other node, it gives up and falls back to being in the ready state. None of the changes should affect modders as they're all just book-keeping.

docker: node on child vessel, the one that has "undock" when docked

dockee: node on parent vessel, always passive

Child/parent selection is automatic and is based on vessel type (base + ship, base is parent), then vessel mass (more massive is parent), then vessel id (pretty random, I suspect, or maybe age based).

 

[CobaltWolf]

Just now, taniwha said:

I added an extra state for the dockee node such that it's not in a docked state until it actually is docked (instead, it's in a passive acquire state), and both sides do a better job of finding the other node when needed. If a node can't find its other node, it gives up and falls back to being in the ready state. None of the changes should affect modders as they're all just book-keeping.

docker: node on child vessel, the one that has "undock" when docked

dockee: node on parent vessel, always passive

Child/parent selection is automatic and is based on vessel type (base + ship, base is parent), then vessel mass (more massive is parent), then vessel id (pretty random, I suspect, or maybe age based).

 

Alright thanks! I've never made docking ports before so I didn't know if there would be any new behaviors not documented elsewhere.

[Archgeek]

25 minutes ago, FullMetalMachinist said:

But honestly, I think just about any discussion about what should or shouldn't be stock is pretty moot at this point, at least as far as 1.1 is concerned. Squad has likely long decided what will and will not be included. 

Perhaps, but this is no parts mod or some bit of prettification.  Insta-gimbals are arguably a bug, or at least a glitch.  I'm ultimately saying they just plain be fixed in stock, and not by a mod.

[regex]

8 hours ago, KasperVld said:

And to be fair, the Intel HD 3000 is an integrated graphics card, which means your machine does not meet the listed minimum specifications for KSP

Here are the listed recommended computer stats for KSP on Steam:

RECOMMENDED:

OS:Ubuntu 14.04 

Processor:Core i5 

Memory:4 GB RAM 

Graphics:SM4 1GB VRAM 

Hard Drive:2 GB HD space

My Gazelle Pro laptop meets or exceeds all of those requirements.  i7 Quad, 8GB RAM, Intel HD 4000 SM5 with plenty of shared VRAM (when the MarkLogic server is killed to be fair), and an SSD main drive to boot.  I get the same PQS lag that Mitchz95 experiences.

Perhaps the lag has nothing to do with minimum specs.  Alternatively, your requirements are completely wrong and should be clarified.

[Spazmataz]

46 minutes ago, Archgeek said:

Insta-gimbals are arguably a bug, or at least a glitch.  I'm ultimately saying they just plain be fixed in stock, and not by a mod.

Have you considered using a joystick or at least a controller? That way you can use the full range of gimbal if you prefer.

Keyboard keys are inherently discrete input sources. Even if Squad was to reduce the stock rate of change of gimbal motion, the [gimbal] accleration rate would still be all-or-nothing based on a keypress -- and it would make the gimbal response more sluggish.

I'd rather have responsive gimbals than sluggish ones.

I have a joystick if I need it, but I rarely ever use it. Instead I do the "modulation" approach by repeatedly tapping on keys to get the gradual, desired effect. I acknowledge though that it would be a lot more smooth if I bothered to pick up the joystick.

If you feel that accurate and smooth gimbal motion is important to your style of play, I recommend a joystick or controller for those times you will need it.

Here is a link on how to configure the joystick for use in KSP:

http://forum.kerbalspaceprogram.com/index.php?/topic/79780-how-to-set-up-a-joystick/

 

Edited February 24, 2016 by Spazmataz

[GeneCash]

I have an Intel HD Graphics 4000 and it's garbage for running a game. It's meant to run Powerpoint, Excel, and other business stuff, and that's it. As a matter of fact, I wrote an article on how to get shadows working on it in Linux for KSP.

I finally got an nVidia GeForce GTX 960 and things are much much better.

For a laptop, you're screwed, as it doesn't have expansion slots for a graphics card.

Edit: My motherboard is smart enough to enable the onboard graphics along with other graphics cards (usually the card replaces the onboard) but X11 really doesn't play ball, so I turned off the onboard graphics.

Edited February 24, 2016 by GeneCash

[FullMetalMachinist]

6 minutes ago, Spazmataz said:

Have you considered using a joystick or at least a controller? That way you can use the full range of gimbal if you prefer.

Player control input is not the issue. It's the way that stock SAS can get into a self-induced wobble, that makes a feedback loop and gets worse and worse. Instant gimbal is one of the contributing factors. 

55 minutes ago, Archgeek said:

Insta-gimbals are arguably a bug

I don't think you can call it a bug, it's definitely acting as intended. I'm not saying that it shouldn't be fixed, just that I don't think you should call it a bug. 

[regex]

2 minutes ago, GeneCash said:

I have an Intel HD Graphics 4000 and it's garbage for running a game.

Runs The Long Dark just fine.  Certainly it's not a dedicated card with all the performance that implies but it most certainly meets the recommended specs.

[GeneCash]

Well, mine kinda-sorta runs Minecraft and Don't Starve, but not well, and those aren't very graphics-intensive games. Once I got the GTX 960, I realized how I didn't need to put up with herky jerky graphics and waiting for Minecraft to fill in the horizon.

Edit: runs Solitaire great though! so it does do gaming!

Edited February 24, 2016 by GeneCash

[Elway358]

 

31 minutes ago, regex said:

Runs The Long Dark just fine.  Certainly it's not a dedicated card with all the performance that implies but it most certainly meets the recommended specs.

I'm running KSP on a similar laptop as a couple others have listed and not having any issues besides the "standard" framerate drops and memory crashes that I see most having with large ships, etc. I've just come to terms that this game just doesn't run well period, for anyone that I see even doing streaming. Hopefully 1.1 will bring slight improvements at least.

My laptop is Lenovo with i5 4200u @ 1.6GHz -  2.3GHz, Intel HD 4400 graphics, 6gb RAM, Win 10. I'm very interested to see if the PS4 version performs better or worse than this non-gaming laptop.

[regex]

10 minutes ago, GeneCash said:

Well, mine kinda-sorta runs Minecraft and Don't Starve, but not well, and those aren't very graphics-intensive games. Once I got the GTX 960, I realized how I didn't need to put up with herky jerky graphics and waiting for Minecraft to fill in the horizon.

Interesting.  I get 60 fps solid with 12 chunk render distance (fullscreen 1920x1280) in Minecraft under normal circumstances  (unless I have a raft of mobs in a farm I've been staring at for an hour AFK, for instance).  I almost got FONV running but it chokes under Wine when I go outside.  Inside the intro house I got a decent framerate.

KSP runs quite well with the Realism Overhaul package but looking at the ocean, under RO or pure vanilla, kills my framerate.  I have zero issues adjusting graphics settings to suit my hardware but the ocean lag remains no matter what.  Something is wrong with the PQS system.

Edited February 24, 2016 by regex

[Guest]

41 minutes ago, regex said:

Something is wrong with the PQS system.

I think something's even worse with the water shader.

[Perry Apsis]

9 hours ago, Temeter said:

Without deeper knowledge, I'm pretty sure that's something completely different. The VAB sometimes just ranks stages incorrectly and therefore mixes them up. I think I've actually read about the stage logic being optimized and fixed in a lot of ways? The UI elements certainly had to be rewritten, so there might be some huge improvement.

Said docking issue the devnote is talking about is probably more about two ships having two staging lists that shouldn't be mixed in the first place, but which is unavoidable when they joint to a single entity. So to 'fix' the bug you'd need to have to be able to switch between multiple persistent staging lists for docked vessels, which would require a completely new system to handle stages.

Thinking about it, systems like this would be pretty handy in VAB. Imagine being able to group stages into a box, and being able to move said box around the staging list. Shouldn't even be that complex to integrate, should it?

I wonder if the docking change would fix the problems with Infernal Robotics's moving parts and docking ports. That would make me *very* happy.

[mattssheep4]

Will one of the many squashed bug include the one for maneuver nodes where sometimes you have to ignite the engines for a moment before it will show the burn time?

[Buster Charlie]

6 minutes ago, mattssheep4 said:

Will one of the many squashed bug include the one for maneuver nodes where sometimes you have to ignite the engines for a moment before it will show the burn time?

If they don't I sure hope they ask the guy who wrote a mod that shows just that already... Seriously how this is not stock?