Chris_C
Members-
Posts
63 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Chris_C
-
[All OS][Java][WIP] KSP Savefile Editor v0.2.2 (24.11.14)
Chris_C replied to SMILIE's topic in KSP1 Tools and Applications
I made a Pull Request on github, not only an ant build file, but I also got rid of a bunch of generics issues -
MechJeb not deterministic depending on FPS
Chris_C replied to Chris_C's topic in KSP1 Mods Discussions
I agree its probably nothing to do with physics ticks -
MechJeb not deterministic depending on FPS
Chris_C replied to Chris_C's topic in KSP1 Mods Discussions
Which doesn't happen exactly every 20ms if an underpowered system is being used.... -
MechJeb not deterministic depending on FPS
Chris_C replied to Chris_C's topic in KSP1 Mods Discussions
Sorry mentioning a physics engine was probably a bad analogy for why calculations are interval dependent. I was discussing how mechJeb does its calculations NOT unity.... -
While my laptop isn't a slouch it certainly doesn't have a power house for a gpu... that said it can play KSP fairly well with very modest settings. Having taken a break from KSP (I know can you believe it...real life, sooo inconvenient sometimes!) The new update prompted a look see. MechJeb was behaving rather poorly, but obviously before posting some vague useless and time wasting "it doesn't work" issue on the tracker I though I should investigate further and gather as many clues as I could - see if I could find anything in logs etc... First port of call was reproducing the various issues on another machine, get it onto my desktop and it behaves like an absolute dream... It then dawned on me that most of the input to MechJeb probably happens at intervals ie once every frame probably, given the nature of the calculations - there will be very large differences in output in different input intervals are used... If you've ever played with physics libraries changing the number of iterations in solvers or the frame rate will usually have massive impact for similar reasons. This is no doubt obvious to the developers, however I posted here as its not obvious to less technical but avid KSP / MechJeb users. I do wonder how many "issues" on MechJebs tracker at at least partly if not wholly caused by systems running at low frame rates - I wonder if MechJeb shouldn't dump FPS to the logs every 5-10 seconds (maybe even have a debug mode you must use before having an issue accepted....yeah like people would use that....)
-
I cant remember where I read it but I was under the impression that the KSP dev's would try not to break mod during minor version updates ie 1.0.2 -> 1.0.3 shouldn't effect mods where 1.0.3 to say 1.1 probably would....
-
hmm isn't 1.0.x and 1.0.y supposed to be mod compatible ? 1.0.3 doesn't like current KAS/KIS
-
I've encountered this issue during a number of versions of KSP, usually fiddling and faffing I can get it to select, in my current save I'm in orbit around the Mun and cannot select Kerbin, if I zoom out far enough I can click the small selection sphere that's usually in the centre of the planets (at a normal zoom it's not visible), however as soon as I do this it says no target I can select other planets, but not Kerbin both 32 and 64 bit versions behave the same. here's a list of my GameData directory ModuleManager.ConfigCache ModuleManager.ConfigSHA FPSViewer.dll *TriggerTech *000_USITools *CommunityResourcePack *Firespitter ModuleManager.2.5.9.dll *Regolith *UmbraSpaceIndustries *MechJeb2 *dockingtube *Squad *NASAmission Has anyone else seen this or have any ideas about a solution?
-
Although I can pick up my model and place it on a ship and attach stuff to it, it doesn't highlight when the mouse is over it. I've tried making the collision mesh both slightly bigger and slightly smaller than the visual mesh without any difference (collisions do work with kerbals for example) I'm using blender and exporting as a dae anyone else seen this before any clues as to what I might be missing?
-
Flexible docking tube - idea... need comments
Chris_C replied to Chris_C's topic in KSP1 Mods Discussions
its already published in another mod, I have detailed above how you can separate the component from the mod (see above) should you not want all the complexity and 1001 other parts (its a great mod if you want all the extra complexity of resource management) but its a bit much if all you want is just the one component! -
Flexible docking tube - idea... need comments
Chris_C replied to Chris_C's topic in KSP1 Mods Discussions
I'll do what ever I like on my own machine that's unpublished if you don't mind.... There is no code anyhow, just a config file where i changed a couple of paths ...... I'm more than able to read a licence file... -
Flexible docking tube - idea... need comments
Chris_C replied to Chris_C's topic in KSP1 Mods Discussions
It does dock craft, and looks like it works with connected living space too..,, -
Flexible docking tube - idea... need comments
Chris_C replied to Chris_C's topic in KSP1 Mods Discussions
anyhow although put off my the crazy complexity of MKS I did manage to break out flexotube to be a modlet of its own... here's what I did first I modified the .cfg file so it looked like this gameData/flexotube/flexotube.cfg PART { name = flexotube module = Part author = RoverDude rescaleFactor = 1 node_stack_bottom = 0.0, 0.25, 0.0, 0.0, 1.0, 0.0, 1 node_stack_top = 0.0, -0.25, 0.0, 0.0, 1.0, 0.0, 1 node_attach = 0,-.2,0,0,-1,0 MODEL { model = flexotube/parts/DockingPort } cost = 200 category = none subcategory = 0 title = MKS Kerbitrail(tm) flexotube manufacturer = Umbra Space Industries description = Expandable, Bendable, attachable tubes up to 50m long. Requires KAS. attachRules = 1,1,0,0,0 TechRequired = Unresearcheable entryCost = 50 mass = 0.05 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 1 crashTolerance = 12 maxTemp = 3200 fuelCrossFeed = True MODULE { name = KASModuleStrut nodeTransform = DOCKING type = TubeSize1 maxLenght = 200 maxAngle = 100 breakForce = 10 allowDock = true allowPumpFuel = true hasCollider = false tubeScale = 1.1 jointScale = 1.1 textureTiling = 1 tubeSrcType = Joined tubeTgtType = Joined evaStrutPos = (0.05, 0.059, -0.21) evaStrutRot = (190.0, 0.0, 0.0) tubeTexPath = flexotube/parts/FlexOTube } MODULE { name = KASModuleGrab evaPartPos = (0.0, 0.40, -0.3) evaPartDir = (0,0,-1) storable = true storedSize = 20 attachOnPart = true attachOnEva = true } MODULE { name = ModuleConnectedLivingSpace passable = true passableWhenSurfaceAttached = true surfaceAttachmentsPassable = true passableDockingNodeTypes = top,bottom } } @PART[flexotube]:FOR[KolonyTools]:NEEDS[KAS] { TechRequired = advConstruction category = Utility } this is basically just altered paths the other files are unedited but the paths are different chris@localhost ~/.steam/steam/steamapps/common/Kerbal Space Program/GameData $ ls flexotube/ -R flexotube/: flexotube.cfg parts readme.txt flexotube/parts: DockingPort.mu TubeParts.png TubeParts_NORM_NRM.png FlexOTube.png TubeParts_GLOW.png so that saved a butt load of coding and pain! not the exact mechanic I had in mind but I use KAS quite extensively anyhow..... -
Especially with bases on rough terrain, I've often thought it would make life so much easier to have a flexable docking tube. In some cases if modules are at different angles it can even be impossible to dock... try to imagine an old fashioned camera with a concertina lens body http://www.earlyphotography.co.uk/Images/C347.JPG here the Z axis is looking down the tube... the tube can change direction in a limited amount (say +/- 20 degrees) x & y axis and can go in and out along the z axis additionally the docking ring can rotate in a limited manner on 2 axis (x & y) This should give a vastly superior docking ability for bases I can handle simple modelling in blender and can code in a number of languages - however a very quick google failed to find and KSP API documentation? (I really don't go for intelli-guess programming) I've also managed to compile both MechJeb and KSP using a Makefile in Linux any guidance/help would be most welcome Does anyone have any thoughts about how useful or not this mod might be or suggestions for it?
-
not at all just get rid of windows..... ) *seriously* *if* this is the issue (which it entirely might NOT be) I remember hearing about it ages ago (ie its probably been fixed/worked round many times) Whats really needed is someone to run a debugger or at least show detailed logs so someone can at least get a clue as to whats causing the issue - watching a slowmo youtube might have been enough but I can't replicate the issue with my setup so I've no way to tell if any meddling I might do would help....
-
In that case its *definatly* a windows issue of some kind I like the directX floating point theory as I know its caught people before I recommend Debian "Jessie" 64 bit, I would help bug hunting but I don't have windows on any of my machine (thankfully! ) .... I do wonder if the bug would happen in windows if you run debian 64bit in a virtual machine on windows.....
-
BUG??? if anything its a *lot* more stable using it in 64bit since KSP was updated, I'm yet to be able to reliably replicate any explosive behaviour, mind you the only other mod I'm using is MechJeb - is this a Windows / other mod interaction issue ?? I'd be interested to hear from anyone else who has only KAS installed and can *reliably* recreate explosive behavior with a .craft file and simple instructions to replicate....
-
Jeeze you don't even need to code - the change to get it working is rather trivial, just change the version checking code to check for the current version of KSP (ie change a single number) - and it basically works as it did... You don't even need an IDE it will compile with a rather simple Makefile... If the KSP api was decently documented and I had the time I'd volunteer to maintain it myself... but well who wants to get whined at...
-
I've had a quick play with 0.24 and found that at least to get it running only the compatibility check needs updating... I compiled using a Makefile just cause I don't like IDE's, after grabbing source from Majiir's git hub and making a franken-merge from an older version that had models in the part directory and textures, sounds that seem missing from Majir's git hub? I was able to get it running... I was almost hoping to see some kind of obvious error message in the logs - so I could be sure I'd fixed something! I haven't had time to properly test KAS with 0.24 but it looks good! I managed to attach a radial connector to the ground and drag a capsule with a winch - no explosions! but puzzled about 64-bit build ? seems to work in 32/64 bit version of the app ???
-
Now please don't tell health and safety I've been doing this but... I've been letting my kerbals ride around on the end of a crane swinging around not just because its fun for them but also because its handy to have them in just the right position to be dropped off and hook up the crane... While leaving the game and returning to it (with a kerbal attached to a crane), I've noticed that kerbal has vanished! is this a known bug? Of course the easy work around is simply not to leave kerbals dangling... but I was curious to know whats going on - I notice the game doesn't allow you to save on a ladder, so I persume its a limitation of how the game save code works (and likely to be none fixable - if you can't prevent the user leaving for the space centre from a plugin...) Now all I gotta do if figure out how to get that flimsy mobile crane to the Mun...
-
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
-
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
-
if you have the part installed on your ship and you see no mechjeb gui the its quite likely you didn't actually install it properly Extract it inside the gameData folder, but double check the folder structure inside gameData is the same as it is in the zip A few clues about your set up might help... 32/64bit (tried both) Linux Mac or some other OS? 1mb ram or 64mb?