nightingale

Actually, it's fixed in the latest Texture Replacer (but he's not using it, and has ATM, so it's not that issue). The other common cause of this is if you tried to do a blind DDS conversion on your GameData dir and converted agency icons that shouldn't have been converted. Beyond that, we'd need a log file to do much more than guessing.

There's a TON of exceptions in that log, so it's hard to say exactly what's going on. I'd start looking at CrewQ based on this one: NullReferenceException: Object reference not set to an instance of an object at CrewQueue.CrewQueueRoster.RestoreVacationingCrew () [0x00000] in <filename unknown>:0 at CrewQueue.CrewQueue.OnLevelWasLoaded (GameScenes scene) [0x00000] in <filename unknown>:0 at EventData`1[GameScenes].Fire (GameScenes data) [0x00000] in <filename unknown>:0 at HighLogic+.MoveNext () [0x00000] in <filename unknown>:0 That being said, your best bet is probably to start removing mods until the problem goes away to try and figure out which one is causing the issue.

Please provide a log file - if you're unsure how to do that, you can read this post.

I'll be honest, I forget which contract pack it's from (best guess is linuxgurugamer's Advanced Progression), but it's definitely Contract Configurator. A couple things: The contract won't care whether you use an existing vessel. You don't need to name the vessel anything special. There was a bug fixed really recently (in 1.6.6) where the ReturnHome check wasn't firing at the right time. Double check that you're on the latest Contract Configurator, as this could be the same problem (although that issue was very specific, so it may not be). The workaround would be to leave the scene and come back before recovering (or quicksave and quickload). If it's still not working, send a screenshot with the vessel in question landed (and the in-flight contract window showing). Also throw in a KSP.log too - just in case it's some weird exception that is stopping things from working. Oh and one last thing - are you losing any parts of your vessel between meeting the first section of the contract and the return home? It's a possibility that if you decouple something it's decided that you're really a new/different vessel than the one that orbited. It shouldn't happen, but the screenshot will help me eliminate that possibility.

Whoops, glad you posted a reminder, because I completely lost your reply over the page break. Anyway, I made some changes so that the casting from string to VesselIdentifier will now work as expected. Give this dev dll a try. I pulled some stuff out to make it easier for me to play around with, but the way you posted it should work now. If not, here's what I tested with: DATA { type = VesselIdentifier theVessel = "innerorbiter"+"@targetBody" } PARAMETER { name = innerorbit type = VesselParameterGroup define = @/theVessel ... PARAMETER { name = innerhome type = VesselParameterGroup vessel = @/theVessel ... - - - Updated - - - Huh... that's just one of those things I just assumed was there. I think I stayed away from it because the recovery stuff always scares me (if it goes wrong, the player could be forced to redo the whole contract). Anyway, makes sense in your scenario, so raised [#295]. - - - Updated - - - I'm glad you mention going to the space center and tracking station, as that helped me isolate where in the log this happened. In flight before you went to the space center, there's this fun little exception: NullReferenceException at (wrapper managed-to-native) UnityEngine.Transform:INTERNAL_CALL_TransformDirection (UnityEngine.Transform,UnityEngine.Vector3&) at UnityEngine.Transform.TransformDirection (Vector3 direction) [0x00000] in <filename unknown>:0 at ActiveJoint.getControlOrt (Vector3 refAxis, PartSpaceMode mode) [0x00000] in <filename unknown>:0 at ActiveJoint.applyCoordsUpdate () [0x00000] in <filename unknown>:0 at ActiveJoint.onPartPack (.Part p) [0x00000] in <filename unknown>:0 at EventData`1[Part].Fire (.Part data) [0x00000] in <filename unknown>:0 at Part.Pack () [0x00000] in <filename unknown>:0 at Vessel.GoOnRails () [0x00000] in <filename unknown>:0 at FlightGlobals.setActiveVessel (.Vessel v, Boolean force) [0x00000] in <filename unknown>:0 at FlightGlobals.ForceSetActiveVessel (.Vessel v) [0x00000] in <filename unknown>:0 at VesselSwitching.Update () [0x00000] in <filename unknown>:0 The key part of the exception is ActiveJoint - that's used by the claw, so I have to pretty much write this one off as Claw Weirdnessâ„¢.

Some fool Kerbal left a grabby-car in the sky!! protip: leaving the altitude out in SpawnVessel will spawn it on the ground. If you need to make adjustments due to the vessel height not being properly detected, use the height attribute. - - - Updated - - - Okay, a couple of the Contract Configurator things: You can put the lists of coordinates into a DATA node in the contract group (so you don't have to define them over and over and over again). You can do @partToScavenge within a text string (like the contract description or title)... this'll make it easier for the player to identify the part that he's going to get. I'd recommend doing something on contract completion either via the completedMessage or Message behaviour (or the DialogBox that is coming in 1.7.0, more below on that) to communicate to the player what part(s) they've gained access to. Is it by design that you don't actually have to recover the vessel (I used it to accelerate my testing by skipping building my own grabby-car)? And more subjective things, take with a dose of your favourite flavourant (extra u's in there, just for you): Grabby mission felt like the right difficulty, I have to reload a couple times to get the right angle to land a reasonable distance from it using the solid booster. I could see the "go grab a single part" thing getting old quickly. Some possible suggestions: Make the contract have multiple parts scattered within a 50m radius, and have the player grab all of them (maybe the equivalent to one tech's worth of parts). If a part is skipped, later contracts could give out that part as well (eg. getting the orange tank would also give the smaller tanks of the same radius). There's a requirement that allows you to have contract require a certain amount of funds/science/rep to fire. If you want to give science points a different meaning, you could use that to offer something special when the player does hit certain science thresholds. Overall I like the idea, because it's different. We need more different things. My concern would be that if I was playing this I might be bored/frustrated quickly, as it could start feeling like too much of a bunch of "fetch quests" tied together. This may not be a concern once you expand on the breadth of contracts. All you other people reading this are not off the hook - go give 5thHorseman your feedback. Oh, and you might be interested in the feature that I'm currently working on, it might fit well into your contract pack - rich text dialog boxes:

Yep... you caught me doing the "only reading half the post" thing that I sometimes do. I'd probably be willing to take a peek (although I'm more likely to just look at the config than play in-game too much). Post or PM a link and I'll have a look.

Oh right, forgot about dissassociateVesselsOnContractCompletion. This is the exact scenario that it was intended for. If you need to allow multiple simultaneous versions of this contract it won't do though... - - - Updated - - - No problem - let me know if you see further issues, and try to get an immediate log... I'm still concerned that I never found the real root cause.

Hmm.... I suspect that'll complain about casting from string to VesselIdentifier. Could you describe what you're doing in more detail (or post up the config). I may be able to suggest other ways of accomplishing it.

Truth is stranger than fiction - this is almost right out of Robert A Heinlein's The Man Who Sold the Moon:

Oh - and to answer the technical question - I don't see scripted changes based on altitude as being an issue.

Raised [#294]. I'm sure you already know this, but I do feel the need to point out that players won't be able to use the craft unless they've researched all parts that are used in the craft file.

Oh, I misunderstood your original post and though it was your own composition. I have no problem with reuse of existing music, as long as it is allowable within the license the composition is released under. Remixing the Interstellar soundtrack for personal use is probably okay (IANAL, so don't quote me on that) - but releasing it wouldn't be (and would also go against Squad's add-on posting rules). The creative commons site has a page about were to find music under the creative commons license for use in videos (which in general would be okay for use in a mod too). So I can't support you if your approach will be remixing the Interstellar soundtrack. If you're willing to do this using music released under a more open license, then I'll still be willing to work on this.

Raised [#293] to add Crawlerway back in. I'd filtered down the KSC contracts pretty heavily, because otherwise you just get a bunch of contracts for things like "Northwest R&D Building", which is just obnoxious. But Crawlerway makes sense to leave in.

I would second Contract Configurator for somewhat obvious reasons. In the second post of the thread I've got a listing of all the active contract packs, I'm sure you'll find one or ten that strike your fancy:

New release with a handful of bug fixes. Download now! Contract Configurator 1.6.6 Fixed exception in Science sub-system (happens in latest FieldResearch release). Added additional check conditions for ReturnHome (thanks Lewtz and Jirnsum). Fixed another rare exception when removing a planet pack (thanks Hlaford). Fixed exception when recovering a vessel completes a contract (thanks AccidentalDisassembly).

Ah yes, I actually already fixed that, but forgot that change is unreleased. You can add Scaps.cfg back in - the exception won't actually affect anything (other than not offering the broken contract), and once I release the next version of Contract Configurator it'll start working again. I see the EVE exceptions (the Cloud stuff, right?) in every other log that someone sends me. It's annoying because the error is so spammy, but doesn't seem to be a real big problem. That's all I know about that. - - - Updated - - - Thanks for this, I've managed to reproduce and it'll be fixed for Contract Configurator 1.6.6.

Hmmm... perhaps you'd be interested in some Quid Pro Quo work? I'm working on my next contract pack project, and would like to have some specific ambience music for a cutscene-style sequence at the end (probably 30-60 seconds long). If you'd be willing to work on that for me, I can put your plugin together. Are you able to post or PM a sample of the type of thing you're working on? In terms of the plugins we'll have to discuss the specifics of what you're looking for, but taking a quick look it should be possible. The constraints that I can see is that the samples will need to be encoded in Ogg Vorbis. Aside from that, the following should be possible: Straight-replacement of stock music, which are: Main Menu theme Main Menu ambiance Credits Tracking Station Space Center VAB/SPH Ambiance Editor (List of arbitrary length) Astronaut Complex Admin Facility R&D Mission Control Flight (List of arbitrary length) Changing music on coded events (there's tons of possibilities, some easy, some hard - let me know the specifics of what you have in mind, and I'll let you know how difficult it is). Cross-fading Cross-fading into a specific time index (in PCM samples, not absolute time)

That looks fine. As long as there's one parameter, a contract will be valid, and this will remove the landing parameter for bodies without a surface.

Sorry, not on this one.

It's been requested a few times, but something like that would be a pretty big thing to do. Right now the only way is to manually expand it, and have a REQUIREMENT to check if you've gone off the end of the list (example from here): PARAMETER { name = InnerTarget type = Any title = Point a dish at ONE of the inner planets disableOnStateChange = false PARAMETER { name = HasAntenna type = HasAntenna antennaType = Dish targetBody = @/targetBodies.ElementAt(0) } PARAMETER { name = HasAntenna type = HasAntenna antennaType = Dish targetBody = @/targetBodies.ElementAt(1) REQUIREMENT { type = Expression expression = @/targetBodies.Count() > 1 } } ...

If it happens again, please provide your KSP.log file... I've got sort of a fix for 1.6.6.... but I think I'm just fixing the symptom, I can't figure out a good reason why it would be happening (and it may not be Contract Configurator, but Kopernicus). It seems that CC isn't able to find the saved body by name (not sure which contract, but likely it's looking for "Earth"). So the only thing that makes sense is if you loaded without the RSS configuration or something odd like that (ie. it's looking for "Earth", but "Kerbin" is there).

Hmm.... there's a whole ton of FAR exceptions in there... wonder if that's where the problem lies?

Interesting, this is the first I've heard of this, but your guess as to the cause seems reasonable. Can you provide a log file?

Did some testing for new features in Contract Configurator 1.7.0