Jump to content

Kerbal Space Program 1.11.2 is live!

UomoCapra

By UomoCapra
in 2021

 Share

Recommended Posts

Anth

Anth

Posted
Posted

Look to the following:

STATION was launched all in one shot therefore all parts have the ID of 1 (just as an example)

Therefore STATION has a container that has the ID of 1

SHIP has the ID of 2 therefore all parts have the ID of 2

Any Physical Struts that are placed into the container with an ID of 1 change their ID to 1.

To have a permanent connection you need to take the physical strut out of the container (ID1)

and then first place onto the SHIP (ID2) first and then onto STATION (ID1) and it will work.

 

Does that make sense?

Link to comment
Share on other sites
Anth

Anth

Posted
Posted

Also this might work but I haven't done a lot of testing of this in space:

  1. Take Part A and let it go in space
  2. Take Part B and let it go in space
  3. Take a Physical Strut and let it go in space. (Identifier resets...I think)
  4. Attach Part A to the station
  5. Attach Part B to the docked craft
  6. Attach the physical strut from Part A to Part B.

 

Link to comment
Share on other sites
KerbMav

KerbMav

Posted
Posted
5 hours ago, Anth12 said:

@RW-1The autostruts for some reason identify with the craft they were taken from (including the kerbal)

Let me see what the best configuration is to make it work properly

 

Does that mean I have my refueling lines in stock already? :sticktongue:

Link to comment
Share on other sites
RW-1

RW-1

Posted
Posted (edited)
15 hours ago, Anth12 said:

Look to the following:

STATION was launched all in one shot therefore all parts have the ID of 1 (just as an example)

Therefore STATION has a container that has the ID of 1

SHIP has the ID of 2 therefore all parts have the ID of 2

Any Physical Struts that are placed into the container with an ID of 1 change their ID to 1.

To have a permanent connection you need to take the physical strut out of the container (ID1)

and then first place onto the SHIP (ID2) first and then onto STATION (ID1) and it will work.

 

Does that make sense?

I'll try both your suggestions and see what I get ...  :)

 

Also wanted to add, STATION not launched all at once, modules flown up on separate launches as it was expanded.

modules moved top various configurations as expansion planned.

Likely have many ID's, im assuming I have to look in persistant for this info?

 

I think my issue is there must be many containers since each module was brought up and joined to the core of the station itself. Bu tI leave it to you more experienced to figure out what may be occurring :)

 

I typically have a ship arrive, and transfer the struts to one of the station modules inventory slots, then use an engineer to go eva on that module and connect them, so all the modules possibly having diff ids makes sense to me (anyway)...

 

Edited by RW-1
Link to comment
Share on other sites
Anth

Anth

Posted
Posted (edited)
On 3/17/2021 at 5:31 AM, UomoCapra said:

This small patch focuses on fixing a few remaining bugs from the last update that were causing some headaches to players.

Kerbal Space Program ALWAYS has more bugs than Squad ever fixes "a few remaining bugs from the last update" I am assuming is in reference to 1.11.1. Not 1.11.0

and that is a false statement. You will experience more bugs in EVA construction in 1.11.2 than you did in 1.11.0, but the benefits seem to outway the disadvantages once you account for them

Bug #27246: Taking parts out of the inventory are coming out at weird angles causing issues with part placement on crafts (Planet Surface) - Kerbal Space Program - Squad Bugtracker

The above bug is the most annoying one that came with 1.11.1 that wasnt fixed.

That was perpendicular in 1.11.0 and isn't in 1.11.1 or 1.11.2.  I have to rotate it, or drop it on the ground first.

Edited by Anth12
Link to comment
Share on other sites
Curveball Anders

Curveball Anders

Posted
Posted
6 hours ago, aeroeng14 said:

So, as someone who is running 1.11.0, is 1.11.2 worth the upgrade stock or wait for 11.3/12.0 depending on the remaining bugs?

Impossible to answer since everyone is playing the game in different ways.

The best solution is to make a copy of your current install and then upgrade that one and see if it works for you.

If it doesn't then just go back and play that one that does.

 

Link to comment
Share on other sites
Goufalite

Goufalite

Posted
Posted
On 3/24/2021 at 3:57 AM, aeroeng14 said:

So, as someone who is running 1.11.0, is 1.11.2 worth the upgrade stock or wait for 11.3/12.0 depending on the remaining bugs?

I think you must switch to 1.11.2 because of the Mk1-3 RCS bug which prevents you from saving/loading the game. Backup your KSP installation folder before in case you find a game breaking bug in 1.11.2.

Link to comment
Share on other sites
Mythos

Mythos

Posted
Posted

I was quickly assembling a space plane with my son, yesterday. It was really strange

  • placed some stuff in plane symmetry, ended up having more than two instances laying over each other (sometimes visible by z-fighting)
  • pressing alt to force node attachment did do visually, but did not accept actually placing it by click
  • removed all the wings and tried just placing a pair in symmetry, CoL indicator went crazily off to one side

This was the first thing I did in KSP after some weeks of abstinence, while in the meantime I did update from 1.11.1 to 1.11.2. It totally did work fine before. So is that introduced by 1.11.2?

Link to comment
Share on other sites
Vanamonde

Vanamonde

Posted
Posted

Mythos, there is a long-standing issue in which if you place parts in mirror symmetry and then mirror that assembly, you get a phantom extra copy in precisely the same place of one of them. It mess with mass and drag and stuff but is only visible by the z-fight. Unfortunately, I have never found a way around it except not to double-double parts like that. 

Link to comment
Share on other sites
Mythos

Mythos

Posted
Posted
17 minutes ago, Vanamonde said:

Mythos, there is a long-standing issue in which if you place parts in mirror symmetry and then mirror that assembly, you get a phantom extra copy in precisely the same place of one of them. It mess with mass and drag and stuff but is only visible by the z-fight. Unfortunately, I have never found a way around it except not to double-double parts like that. 

Yes, I think a mirror of mirror was involved. And probably my usual builds don't use that, so I didn't notice before.

Link to comment
Share on other sites
Murdabenne

Murdabenne

Posted
Posted (edited)
On 3/16/2021 at 11:31 AM, UomoCapra said:

Hello Kerbonauts! 

Kerbal Space Program 1.11.2 is live! 

@UomoCapra, I was checking the additional DLC purchases in preparation for a clean 1.11.2 install, and these appear to be the listings:

Breaking Ground 1.6.1 "Use this installer if you have a non translated copy of KSP 1.11.2" ->  KSP-Breaking_Ground_Expansion-en-us-1.6.1.exe
Making History Expansion 1.11.1 "Use this installer if you have a non translated copy of KSP 1.11.2" ->  KSP-Making_History_Expansion-en-us-1.11.1.exe

These appear to be the same as the previous ones.  Is it safe to say I can reuse those or do I need to download what appear to be identical files for a fresh (updated) install to 1.11.2 all around?

(A suggestion: sync all the DLC to have the name versioning file name as the base game for which they are intended.  It would clear up any possible misunderstanding, even if it is simply a filename change, maybe something like "KSP-Breaking_Ground_Expansion-en-us-1.11.2.exe or even "Breaking_Ground_Expansion-1.6.1-en-us-for-KSP-1.11.2")

Edited by Murdabenne
suggestion
Link to comment
Share on other sites
Maxxim

Maxxim

Posted
Posted

Multiple reports of fuel lines and struts built in space, that will no longer connect after a save/reload.

The workaround is to float around and do the work again. Not really fun.  

I see a list of changes in changelog, but I never see a high quality assurance testing group specifically list the things they did or did not test after every build.  In the business, this is called a "test plan", a.k.a. "doing the detailed work of checking things that also werent supposed to change"..  a.k.a "regression testing".

 It would also be nice if a large group of users could be allowed access to the test server build or in a separate instance to volunteer to "break things".

From working in dev and QA many years, I know this is needed because: it puts accountability on the person(s) credibility and job quality to explain why it was let out to the next patch.

Link to comment
Share on other sites
Lisias

Lisias

Posted
Posted
On 4/3/2021 at 1:53 AM, Maxxim said:

Multiple reports of fuel lines and struts built in space, that will no longer connect after a save/reload.

The workaround is to float around and do the work again. Not really fun.  

I see a list of changes in changelog, but I never see a high quality assurance testing group specifically list the things they did or did not test after every build.  In the business, this is called a "test plan", a.k.a. "doing the detailed work of checking things that also werent supposed to change"..  a.k.a "regression testing".

 It would also be nice if a large group of users could be allowed access to the test server build or in a separate instance to volunteer to "break things".

From working in dev and QA many years, I know this is needed because: it puts accountability on the person(s) credibility and job quality to explain why it was let out to the next patch.

An early access program is being asked for years already. You don't need to add new content to the early access, just new code and some assets that use them, so people can scrutiny the thing and look for regressions and new bugs.

That would help in the past for sure, when lots of people willing to test things were around to see how their plugins would behave on the new version. Nowadays, we have few authors around, and even fewer maintainers (one of them with 400 plugins under his stewardship). Too few eyes to worth the effort of maintaining a public formal artefact with its own life cycle IMHO. Crowding depends of a large base of contributors.

I agree about the accountability. The RCS thrusters problem on 1.11.1 was beyond description - or they didn't even fired up the thing once before shipping, or someone sneaked a merge after the QA testing. In any case, one single dude jeopardised the whole team.

A dog with too many owners starves to death. (local saying brute forced into English)

Link to comment
Share on other sites
Kerbart

Kerbart

Posted
Posted
58 minutes ago, Lisias said:

An early access program is being asked for years already. You don't need to add new content to the early access, just new code and some assets that use them, so people can scrutiny the thing and look for regressions and new bugs.

That would help in the past for sure, when lots of people willing to test things were around to see how their plugins would behave on the new version. Nowadays, we have few authors around, and even fewer maintainers (one of them with 400 plugins under his stewardship). Too few eyes to worth the effort of maintaining a public formal artefact with its own life cycle IMHO. Crowding depends of a large base of contributors.

I agree about the accountability. The RCS thrusters problem on 1.11.1 was beyond description - or they didn't even fired up the thing once before shipping, or someone sneaked a merge after the QA testing. In any case, one single dude jeopardised the whole team.

A dog with too many owners starves to death. (local saying brute forced into English)

Just imagine KSP had built-in scripting, kRPC style. You could test every engine, its fuel flow, performance. Then test every tank - how long does it take to drain it? Test for a craft with all kinds of landing gear in all kinds of conditiojs if it "walks" or not. And all automated.

Link to comment
Share on other sites
Lisias

Lisias

Posted
Posted (edited)
11 hours ago, Kerbart said:

Just imagine KSP had built-in scripting, kRPC style. You could test every engine, its fuel flow, performance. Then test every tank - how long does it take to drain it? Test for a craft with all kinds of landing gear in all kinds of conditiojs if it "walks" or not. And all automated.

We already have kRPC. Having the scripting embedded is not a prerequisite for automating tests nowadays. And since kRPC has bindings to Python, C and the kitchen's sink, integration with QA tools is a breeze. From Rational Test Manager to Unit tests on Github's Continuous Integration, choose your poison!

There's a catch, however. Automated tests are software artefacts with their own life cycle and cost center. For every change on the product, the respective automated test needs to be updated too, not rarely doubling the efforts (and costs).

I had had features of mine being rejected because there would be no available developer to update the Test Cases ("Agile"... Yeah...).

Developers are way scarcer than manual testers. Sometimes you just can't afford to waive the development time on such a task.

Edited by Lisias
Grammars. I'm evolving from tyops! :P
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...