Jump to content

Kerbal Attachment System (KAS) 0.4.7 - Pipes as fuel lines and even fewer explosions!

Majiir

By Majiir
in KSP1 Mod Releases

 Share

Recommended Posts

koksny

koksny

Posted
Posted (edited)
I'm having serious problem with 0.4.7. Whenever I grab part from ship or take it from the container ship explodes.

This never happened to me in previous versions of KAS. Anyone knows how to solve this?

Exactly same problem here, renders KAS unfortunately useless. Log of this happening below:

[LOG 06:20:23.765] [KAS] Grab - Grabbing part :solarPanels4

[WRN 06:20:23.811] [PartJoint]: None of the provided nodes was valid!

[LOG 06:20:23.894] [00:00:28]: Structural failure on linkage between FL-T400 Fuel Tank and 6S 1m Service Compartment Tube.

[LOG 06:20:23.899] [00:00:28]: Structural failure on linkage between Pipe end point and FL-T400 Fuel Tank.

[LOG 06:20:23.902] [00:00:28]: Structural failure on linkage between OX-4L 1x6 Photovoltaic Panels and Jebediah Kerman.

[LOG 06:20:23.925] [00:00:28]: Structural failure on linkage between LV-909 Liquid Fuel Engine and FL-T400 Fuel Tank.

[LOG 06:20:23.963] liquidEngine3 collided into fuelTank - relative velocity: 7.842641 - impact momentum: 17.6

[LOG 06:20:23.963] liquidEngine3 Exploded!! - blast awesomeness: 0.5

Also symptomatic is the grabbing itself dont work - part is just detached from vessel and not attached to Kerbal. Help?

EDIT:

Can confirm it's problem with KAS and not with other mods - running stock and grabbing anything with KAS still results in same behaviour - ship is flinged hundred meters away, explosions inducing, kraken inviting.

EDIT2:

Incompatiblity with KSP 64. See below.

Edited by koksny
Link to comment
Share on other sites
smart013

smart013

Posted
Posted (edited)
Having trouble with fuel lines. I get the two ships within 20m of each other and null out the DV. Then EVA and attach pipe ends. Prior to EVA I ensure mechjeb is turned OFF on both ships.

Then I switch to either ship and use tac fuel balancer move the liquid and oxidizer. I have tried 0.1, 1.0, 10.0, 100.0 and the results are the same the ships start oscillating, slowly at first, but it keeps building until it's violent enough to EXPLODE the ships.

Once it reaches a point you cannot get the eva'd kerbal to the pipe end to unlink it. The only way I have found to stop the bucking is switch tot he eva'd kerbal, making sure he is off any ladders and quickly tap the period and comma to warp for an instant and the oscillation will instantly stop but will gradually grow again so you have to rush and unlink.

Why is this happening and how do I stop it please?

I am running career mode, 0.23.5, with the latest KAS.

thanks in advance for any advice / help.

Nice tip with the warping, thanx. Whenever i do this myself i have to really, really make sure that the relative motion of both vessels is near zero. Even a bump from a eva kerbal can trigger this cycle of getting out of control, so these maneuvers are always very stressfull :)

But its possible to get it done and be safe. One of my stations has a permanently connected (20m) probe now for some kerbal months, and no tendency to spin out of control there. Ok, granted that a little vessel connected to a large vessel seems to be a bit easier anyway than two mostly equal sized vessels.

Edited by smart013
Link to comment
Share on other sites
koksny

koksny

Posted
Posted

After some testing i have found that last version of KAS is not compatible with KSP 64bit.

Problems with exploding parts/flinging ships and Kerbals are only present in KSP64. No fork or other, older version works as well. Surface attachment node seems to work different in KSP64, or maybe it's just case of much higher floating point precision making stuff collide.

One way or the other, can we hope for 64 bit fix for KAS?

Link to comment
Share on other sites
Majiir

Majiir

Posted
  • Author
Posted
One way or the other, can we hope for 64 bit fix for KAS?

Not from the KAS side. The KAS plugin is fully managed code. It's agnostic to CPU word size. In other words, KAS doesn't have anything to fix; it would run just as well on a hypothetical 128-bit architecture. If 64-bit KSP is causing issues with KAS, that means there's either a bug in 64-bit KSP/Unity (highly likely) or a bug in 32-bit KSP that KAS is inadvertently depending on (less likely). If you can dig up more information that shows certain KSP/Unity functions are unreliable in 64-bit, it might be possible to pick alternatives, but my guess is not.

Link to comment
Share on other sites
koksny

koksny

Posted
Posted (edited)
Not from the KAS side. The KAS plugin is fully managed code. It's agnostic to CPU word size. In other words, KAS doesn't have anything to fix; it would run just as well on a hypothetical 128-bit architecture. If 64-bit KSP is causing issues with KAS, that means there's either a bug in 64-bit KSP/Unity (highly likely) or a bug in 32-bit KSP that KAS is inadvertently depending on (less likely). If you can dig up more information that shows certain KSP/Unity functions are unreliable in 64-bit, it might be possible to pick alternatives, but my guess is not.

One more thing tho - could you please provide link to latest version source code? I tried to find it on Github but even the latest forks seem to have not updated compatiblity checker since 0.23.

As far as i can tell, KAS generally speaking works (you can move parts on vessel using "attach" button), but the odity generating code seems to be:

Transform nodeTransform = new GameObject("KASNodeTransf").transform;

nodeTransform.parent = p.transform;

nodeTransform.localPosition = attachNode.position;

nodeTransform.localRotation = rotation;

attachNode.nodeTransform = nodeTransform;

Of course i can be totaly wrong, but i assume it knowing that, for example, MechJeb in KSP64 reports distance from target in pico-meters. And the part behaviour after grabbing looks like it's hitbox is spawning inside kerbal (Or just generaly bugs out, because it doesn't attach to it after all).

Is there for example possibility that some variable should be defined in different way for 64bit build? Really just shooting blind here trying to pinpoint some hotfix. Maybe it's just some simple case of turning float Vector3 somewhere into double Vector3d? (Yes, i have no clue about C#, just really want to fix that god damn satelite with KAS)

EDIT:

Also i'm assuming this one is the latest code-changing fork? https://github.com/angavrilov/KAS/tree/76ca2cd2c5fae469817e17ad04538a4c1d9adc5a

Edited by koksny
Link to comment
Share on other sites
Majiir

Majiir

Posted
  • Author
Posted
One more thing tho - could you please provide link to latest version source code? I tried to find it on Github but even the latest forks seem to have not updated compatiblity checker since 0.23.

Sorry about that; seems I forgot to push after the last release. My KAS repository on Github is now up-to-date.

Is there for example possibility that some variable should be defined in different way for 64bit build? Really just shooting blind here trying to pinpoint some hotfix. Maybe it's just some simple case of turning float Vector3 somewhere into double Vector3d? (Yes, i have no clue about C#, just really want to fix that god damn satelite with KAS)

64-bit portability usually deals with pointer types, which aren't present in fully managed code. If Unity somehow changed its geometric functions with the 64-bit version, that's a Unity bug and inconsistency that's not documented as far as I know. It's certainly not necessary for 64-bit compatibility.

Link to comment
Share on other sites
Myrten

Myrten

Posted
Posted
After some testing i have found that last version of KAS is not compatible with KSP 64bit.

Problems with exploding parts/flinging ships and Kerbals are only present in KSP64. No fork or other, older version works as well. Surface attachment node seems to work different in KSP64, or maybe it's just case of much higher floating point precision making stuff collide.

One way or the other, can we hope for 64 bit fix for KAS?

I can confirm this, my explosions are in 64 bit version.

Link to comment
Share on other sites
koksny

koksny

Posted
Posted

So after some testing, i can further confirm that problem is only related to event handling decoupling part from original vessel and attaching it to Kerbal. When part is grabbed, a lot of force is being applied to vessel itself, what leads to structural failure between Kerbal and part connected to him.

Also its worth noting that the part is not being attached to Kerbal correctly - it's state is set as grabbed, but it's just treated as new vessel (debris). After "ungrabbing" it and grabbing again (not from vessel but from ground) no problem shows up and everything works.

So there is either different method in code for grabbing stuff from ground/vessel, or it's just case of collision boxes being miscalculated (What leads to no problem when grabbing stuff from ground).

I did logged same situation on both 86 and 64 clients, but it's really not adding much, just the difference with Structural Failure being logged in 64 version.

I have also succesfully achieved modyfing the code to the point where after grabbing force is being applied to Kerbal, not into vessel. It obviously cuts off explosion, but slinging someone in orbit is also a bit counterproductive.

Any hints? I believe it's possible to backtrack the problem with more log messages injected into code, but maybe someone with more experience have some brilliant idea before i will start painfully spawning DebugError in every function related to EVA?

Link to comment
Share on other sites
BudgetHedgehog

BudgetHedgehog

Posted
Posted
question: how would i be able to add other parts from mods so that they will benefit from this?

I presume you mean the grab and store functionality?

@PART[partnamehere]:Final
{
MODULE
{
	name = KASModuleGrab
	evaPartPos = (0.0, 0.0, -0.15)
	evaPartDir = (0,0,-1)
	storable = true
	storedSize = 2 //change this to an appropriate number
	attachOnPart = True
	attachOnEva = False
	attachOnStatic = False //can attach to ground
}
}

Link to comment
Share on other sites
koksny

koksny

Posted
Posted (edited)

After quite long debugging i have found out the issue causing incompatibility with 64 bit version, and explosions/big velocities on grabbing part with KAS. And in fact Majiir was totally correct, the issue is not related to KAS code in any way.

There seems to be difference in how .decouple() works in 64/86. Basically, it looks like in 64 the direction vector of force after decoupling is null (or some other wonky number), following with force being applied to both parts in attachment node point. Following with explosion because of collisions.

Most important fact is - same problem shows up, for example, in ProceduralFairings, because of also using the .decouple() function.

So now the question is - can we modify the .decouple()? Replace it with some custom function? Or is it just so deep in Unity we are screwed?

EDIT:

Can it be related to http://bugs.kerbalspaceprogram.com/issues/2412 ?

Edited by koksny
Link to comment
Share on other sites
MikeAeronautLZ

MikeAeronautLZ

Posted
Posted

I do not know if the internal API of KSP allows you to get too deep into the guts of how things work, but if the decouple() function is spitting out a bogus force vector, then the solution is to spoof it. Before KAS code calls decouple(), it stores the physical data of the vessel and all the forces acting on it. Then it calls decouple, and immediately resets all that physics data in the two vessels and reapplies the force vector as it itself calculates it. It's like fixing cusps in differential geometry: isolate the point and excise it cleverly. You'd want to dump that code into a spoofed function spoof_decouple() and have everyone use that instead.

Link to comment
Share on other sites
koksny

koksny

Posted
Posted
I do not know if the internal API of KSP allows you to get too deep into the guts of how things work, but if the decouple() function is spitting out a bogus force vector, then the solution is to spoof it. Before KAS code calls decouple(), it stores the physical data of the vessel and all the forces acting on it. Then it calls decouple, and immediately resets all that physics data in the two vessels and reapplies the force vector as it itself calculates it. It's like fixing cusps in differential geometry: isolate the point and excise it cleverly. You'd want to dump that code into a spoofed function spoof_decouple() and have everyone use that instead.

Unfortunately i have no clue how to get to decouple() code. What i did was painfull debugging of variables being used (in KAS an ProceduralFairings) before calling decouple(), hoping to catch any difference, but to no success. And since i believe decouple() is part of CSharp Assembly, i dont really know how to proceed. Dump the bytecode from memory? It makes reverse engineering this code almost nonsense - we will probably get 0.24 before it's done.

Also there is possibility it's bug related to Unity 4.3 ( http://forum.unity3d.com/threads/hybridobbcollider-crash-issue-in-x64-standalone-player.224486/ ), fixed in Unity 4.5. Can't check it for obvious reasons.

Link to comment
Share on other sites
Chris_C

Chris_C

Posted
Posted

I adapted the Makefile from MechJeb to work with KAS, I'll abandon it here in the hope its useful to someone...

I have only tested the Makefile in Linux - it may erase you harddrive use at your own peril

I notice I can't for instance switch a light on or off (no right click menu) when I'm controling a craft, when there is a kerbal outside the ship, is this a known issue?

also right alt is supposed to twist (the attachment pointer) as far as I can tell from the code, is this supposed to be the alt-gr key? - if so it does nothing in Linux...

# Makefile for building KAS - by codifies - based on MechJeb Makefile 


ifeq ($(OS),Windows_NT)
	# do 'Doze stuff
else
	UNAME_S := $(shell uname -s)
	ifeq ($(UNAME_S),Linux)
		#KSPDIR  := ${HOME}/.local/share/Steam/SteamApps/common/Kerbal\ Space\ Program
		KSPDIR  := ${HOME}/.steam/SteamApps/common/Kerbal\ Space\ Program
		MANAGED := ${KSPDIR}/KSP_Data/Managed/
	endif
	ifeq ($(UNAME_S),Darwin)
		KSPDIR  := ${HOME}/Library/Application\ Support/Steam/SteamApps/common/Kerbal\ Space\ Program/
		MANAGED := ${KSPDIR}/KSP.app/Contents/Data/Managed/
	endif
endif

KASFILES := $(wildcard Plugin/*.cs) \
	$(wildcard Plugin/Properties/*.cs) \

RESGEN2 := resgen2
GMCS    := gmcs
GIT     := git
TAR     := tar
ZIP     := zip

VERSION := $(shell ${GIT} describe --tags --always)

all: build

info:
	@echo "== KAS Build Information =="
	@echo "  resgen2: ${RESGEN2}"
	@echo "  gmcs:    ${GMCS}"
	@echo "  git:     ${GIT}"
	@echo "  tar:     ${TAR}"
	@echo "  zip:     ${ZIP}"
	@echo "  KSP Data: ${KSPDIR}"
	@echo "================================"

build: build/KAS.dll

build/%.dll: ${KASFILES}
	mkdir -p build
	#${RESGEN2} -usesourcepath Properties/Resources.resx build/Resources.resources
	${GMCS} -t:library -lib:${MANAGED} \
		-r:Assembly-CSharp,Assembly-CSharp-firstpass,UnityEngine \
		-out:$@ \
		${KASFILES} 

package: build ${KASFILES}
	mkdir -p package/KAS/Plugins
	cp -r Parts package/KAS/
	cp build/KAS.dll package/KAS/Plugins/
	cp LICENSE.md README.md package/KAS/

%.tar.gz:
	${TAR} zcf $@ package/KAS

tar.gz: package KAS-${VERSION}.tar.gz

%.zip:
	${ZIP} -9 -r $@ package/KAS

zip: package KAS-${VERSION}.zip


clean:
	@echo "Cleaning up build and package directories..."
	rm -rf build/ package/

install: build
	mkdir -p ${KSPDIR}/GameData/KAS/Plugins
	cp -r Parts ${KSPDIR}/GameData/KAS/
	cp build/KAS.dll ${KSPDIR}/GameData/KAS/Plugins/

uninstall: info
	rm -rf ${KSPDIR}/GameData/KAS/Plugins
	rm -rf ${KSPDIR}/GameData/KAS/Parts


.PHONY : all info build package tar.gz zip clean install uninstall

Link to comment
Share on other sites
Chris_C

Chris_C

Posted
Posted
Is that the thing that was just reverted? http://jenkins.mumech.com/job/MechJeb2/260/

maybe its hard to see if that got dragged into the revert with the other code changes, the only diff is the platform IF statement if you are just using on Linux you can remove the parts for OSX and Windows

In both cases the MechJeb Makefile has incorrect paths (they were correct just after I pulled) the Makefile above has correct paths for Linux and has only been tested on Linux - where it works for KAS and no longer has anything to do with MechJeb other than its origin - it will no longer work with MechJeb because of changed various changed paths and also different resource handling

Link to comment
Share on other sites
marce

marce

Posted
Posted (edited)
It is possible to make two strut endpoints connect in the VAB/SPH (for easy strut placement?)

I can't speak for KAS, but this functionality will soon be possible with my mod which does not have an EVA focus but allows to do many things with struts (and with struts only).

If you are interested to test, write me a PM.

@Majiir: sorry for hijacking your thread a bit.

Edited by marce
Link to comment
Share on other sites
BudgetHedgehog

BudgetHedgehog

Posted
Posted (edited)
How do I make certain items KAS "grab"-abble in EVA? I have some errant quantum strut guns I don't want on the exterior of my station rid of.

You should download QS Continued. Not only does it include KAS support, but makes them available in the tech tree and enables tweakables.

EDIT: but to answer your question, a MM config containing:

@PART[blah]
{
    MODULE
    {
       name = KASModuleGrab
       evaPartPos = (0.0, 0.0, -0.15)
       evaPartDir = (0,0,-1)
       storable = true
       storedSize = 5
       attachOnPart = True
       attachOnEva = False
       attachOnStatic = False
    }
}

Is your standard boilerplate KAS grab and store module. Feel free to change values as necessary/required.

Edited by ObsessedWithKSP
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...