Lisias

It's not so simple "downthere" on the CPU. This subject is way off topic, so ping me here if you are interested.

News from the Front. For who is not following what I'm doing ("todo mundo menos uns 3 ou 4 gatos pingados" ), I'm hunting down and closing issues about patches for the next minor release, what I wanted to put on the wild this week but... This is the problem, and it's not a unexpected one. After adding ":FOR" on every patch, things works fine as much as everybody uses :AFTER , :BEFORE or :NEEDS . This will work for new patches (or for KSP installments with only Stock parts and TweakScale). But older patches, now, have precedence as legacy patches are applied first by Module Manager.. And then my patches bork due other Add'On "taking over" the parts: [LOG 19:19:18.920] [ModuleManager] ERROR: Error - paste command (#) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] [LOG 19:19:18.921] [ModuleManager] ERROR: Error - replace command (%) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/%MODULE[TweakScale] [LOG 19:19:18.921] [ModuleManager] ERROR: Error - paste command (#) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] [LOG 19:19:18.921] [ModuleManager] ERROR: Error - replace command (%) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/%MODULE[TweakScale] [LOG 19:19:18.929] [ModuleManager] ERROR: Error - paste command (#) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] [LOG 19:19:18.929] [ModuleManager] ERROR: Error - replace command (%) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/%MODULE[TweakScale] [LOG 19:19:18.929] [ModuleManager] ERROR: Error - paste command (#) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] [LOG 19:19:18.929] [ModuleManager] ERROR: Error - replace command (%) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/%MODULE[TweakScale] These are not parts from another Add'Ons. The parts borking are Stock ones. There're random patches "taking over" the control of Stock parts, and this will break everybody once I publish this next Release that would be relying on default TweakScale behaviour. There're no easy way out of this. Well. Bug fixes are in hold while I enumerate the Add'On(s) that are doing this. Definitively, not fun. — — — — POST EDIT — — — — I was wrong! The problem is not with the :FOR thingy, it is with the parts themselves!! At this point, this can be even a bug on MM or in any other Add'On that mangles GameData as it appears - the problem is not deterministic anymore: the same installed Add'Ons are not causing the trouble anymore for 'reasons', and now I'm trying to make the problem happens again... Oh, joy ! — — — — POST POST EDIT — — — — This Kraken food freaking problem has vanished. I, indeed, did updated some Add'Ons on the installment where that happens and had forgot about - just remembered now that I was updating some more and realized the timestamps of some directories. Duh.. Never mix fun and business, they say. In a way or another, it was indeed a patch related problem and so, it will probably happen again. But at least, now I know in advance about the issue, so I will respond to it way faster in the future.

Had you asked yourself why such Add'Ons are slow? What make you think that it wouldn't be slow too if such feature is incorporated on KSP? There's no free lunch. You need to write code for doing things, and then this code uses CPU time at the expense of other code.

Dude, I was in a hurry and hit Save too soon. The FS3WL is from FireSpitter. It's a part that once you launch the craft, teleport it to any place in the current body. It's very handy when you don't want KK neither MakingHistory. I used to use VeselMover to put the craft where I want for the first time. Then took note from the position, and then create a ".pos" file with it on the FIrespitter folder. Then I just strap the FS3WL part, select the .por file I want and then voilá.

It's not a CKAN issue. At least, no directly. The "remote site" (i.e., the place where your running CKAN is trying to fetch data) just closed the connection on the CKAN's face. Only the remote site owner can tell you whey this happened. Usually, this happens when the remote is overloaded and have to make harsh decisions about who to serve and who not. There're other situations when this happens, but, really, only the remote site's owner can tell for sure.

Install Kerbal Konstructs, and not Kerbin Side. KK is the one allowing to select launch sites. If you ara on KSP 1.4, you can use the "FS3WL Water Launch System". It's working for sure (I fixed it and made the push request to maintainer's). The .pos files need to be updated, however. I don't know about 1.5, but on 1.6 the thing is not working perfectly again (some small glitch, but I didn't found the time to figure out it yet)

Hey! This would make me jobless! On a side note, perhaps not the "full tweakscale". Trying to figure out a way to scale every single part that any crazy Add'On author could create would drive the guys nuts. But a stock interface to be realized by people willing to scale his parts would be interesting - so they withhold control on scaling critical datum (as mass), and don't have to bother trying to cope with crazy Add'On authors.

Do you remember I complaining about having my block out of power for maintenance of the public lines last Saturday? It was for nothing as it appears. I was shopping for groceries (and Coffee! Lots of Coffee!) when started to rain heavily. I was caught in the middle of the rain (and without soap - lost the opportunity to take the week's bath), with a bag full of groceries. Worst part: the whole block is out of power. For an hour already. And I had to walk up 13 flights of stairs until home. At least I made it. Now I'm mourning another lost work day while try to figure out why my home is so hot and this weird guy with horns on his front and goat shoes laughs at me every time I tell him to go away...

Not necessarily. The CFG files are just text describing what the code should do. You can rewrite the code without changing semantics of the data being read. It's the reason you can compile the same C source code on different machines using different compilers. Or can render HTML on different browsers. However, it will worth the cost? Would not be better to have a external converter tool. so we can just start over on a clean slate? These are the questions that should be answered before starting such a stunt. However, such a stunt is far from being not possible. In a nutshell: "Hey, user, I can reuse your older stock crafts. It will cost you 20 bucks on the fee. Are you willing to pay for it?"

I don't care (too much) about such breaks. Things change, and you can't be a prisoneer of the past. I just stated what would made my life a bit happier when such things happens. You are wrong. Kopernicus is one Ad'On that breaks loudly, and this is a good thing. Silent breaks (as we had with TweakScale) are the nasty ones. but, and again, things change and we need to learn how to cope with it. I just stated something that would made things a little easier to cope. At least to me.

(sigh) One of the best videos from Nassault got silent recently. Probably a copyright strike. Sad. Anyone know of a copy of this video somewhere else?

You should fork a bunch of them and code review them A huge amount of small things that used to work fine is broken somehow (some of them mangling the savegames and crafts to problems), but since this doesn't crash the game, people doesn't notice it immediately. But then small glitches came from nowhere start to annoy the users, and this usually tends to reflect negatively on KSP. Small things tends to cause a huge grievance as the time goes by. Deep dive on my forks (mainly the Unofficial ones), I'm documenting everything I find there. It's my opinion too (and I am not shy about telling it). Even the last "heavy" breakage that happened on the 1.4.4 ended up being hugely positive in performance, it had worth the pain. I just preferred that it happened on a 1.5.0 version, I didn't expected such breakage on a minor release. Expectation is the keyword. Glitches and breakage are not a problem. Unexpected glitches and breakage are. I'm usually all by "meta-Add'Ons" like Kerbal Konstruction and Firespitter - where one tries to abstract and include features to make Add'On authoring easier. Something breaks heavily? The bad news: everything relying on them break too. The good news: you fix them, everything is fixed at the same time too.

On a personal note, I would be happy with a somewhat semantic versioning. The frequency of the update would be a minor issue (if an issue at all) if I could rely on the version number to foresee possible breaking changes. KSP 1.4.4 should be "1.5.0" an my book, due the breakage on some Add'On. Nothing really changed to the 1.5.1 (mainly bug fixes and new features). It appears to me that version should be, really, "1.5.4". Of course, I'm ignoring any API or feature novelties, I'm focused on the perceptible effects on Add'On authoring.

I agree. That's the reason I made this: http://ksp.lisias.net/showcase/L-Aerospace/Parts/mk1-extensions/ @Tonka Crash , I also use that Add'On (Mk1-Cabin-Hatch), but for spaceships. Airplanes and crewed rovers doesn't work very well with this. Something like this?

What will really solve the problem is better patches. BDarmory is not the problem, rogue patches are. I'm applying some fixes on the patches on TweakScale, I expect some improvements on the current status quo. About KSP-AVC you will find a newer version (working on recent KSP) here. It's what I'm using. About the crashes, I need a full log with them to be sure. Bugs are social beings, they like to gather togheter.

Ugh. There're an awful amount of Duplicated TweakScale on your KSP.log. BDArmory and SpaceY are the preferred victims, I think. I expect this to be fixed on the next minor release, currently being worked. (yeah. The Refactoring will be delayed. Again) However, you stopped the log while still in Editor, so whatever it happens on launch, I didn't get it. So I still blind on the issue. On completely unrelated subject, I found some Exceptions that need your attention. On the spoiler below to prevent cluttering the topic with unrelated data.

This is a new for me. Can you share with me an craft that does that?

Let's be conservative. Try this one first. You need to install the Ferram4's latest. Then you delete the original DLL and unzip this one overwriting files if needed. If things didn't work out for you, publish another log, and then try this one: https://github.com/net-lisias-ksp/Kerbal-Joint-Reinforcement/releases/tag/RELEASE%2F3.4.0.4

Well, I found 000_KSPe on your log, and also found a Exception on DLL loading: [ERR 16:06:37.713] AssemblyLoader: Exception loading 'NextStarIndustries': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 This corrupts somehow something on Mono's runtime, and this something kills KSPe on its very basic features, killing anything that depends on KSPe in a chain reaction. Since I didn't found any Exceptions related to KerbalJointReinforcement (that it's being loaded), I conclude that you are using that DLL recompiled by… Who's the guy? I forgot… Anyway, it's Ferram4's latest recompiled to work on 1.6. In a way or another, I think you should fix the "NextStarIndustries" problem. If KJR/L ends up being the solution for your problems, it will borks due this. Now, about the issue under our nose, your machine is not exactly a potato, its 2.6 to 3.5GHz frequency should had be able to handle this. So I'm not sure KJR/L would help you on this. What I found on the log, however, follows: [LOG 16:17:07.653] [F: 21666]: R8winglet collided into EHInimitz (Nimitz) - relative velocity: 101.1924 - impact momentum: 11956300.0 [LOG 16:17:07.653] R8winglet Exploded!! - blast awesomeness: 0.1 [LOG 16:17:07.653] [R8winglet]: Deactivated [LOG 16:17:07.669] 1 explosions created. [WRN 16:17:08.582] [StageInfo]: Simulation Time exceeded! [WRN 16:17:08.785] [StageInfo]: Simulation Time exceeded! It appears that you had "heavy landed" on your wingtip. However, if by any reason you were still flying at range when the Nimitz got off rails, we have a hard nut to crack now. The WRN about the simulation it's expected when a lot of parts are on the scene and things explode. Everything and the kitchen's sink starts to reevaluate the surviving assets, and this is a somewhat costly operation. When something explodes in the sequence, the evaluation restarts, and so on.

I miss Scott Manley's videos on KSP, they had some clever (and scientific) approaches. I was being entertained but also taught on that videos. But he's still there, teaching me with another kind of videos, and we still have Matt and Shadowzone and others (sorry not remembering you all), so in the end I'm counting my blessings. But there're one Mission that I would love to be retaken - to tell you the true, these are the videos that first caught my attention and made me consider KSP as a hobby (all the others came after). The Super Kolonization. I still follow that guy, who knows if he decides to come back now with a lot of bugs on KSP fixed?

You have rogue patches on your installments (unfortunately, a few on them were on default patches on TweakScale). You can safely ignore the "TweakScaleDisabled" nodes. It's TweakScale preventing you to suffer from rogue duplicates, the real ones are preserved. So, this is not an error. It's an error being fixed. The crash, however, is something to be investigated. Please publish your KSP.log.

On a blind guess, you have too parts "alive" at the same time and something is not being able to catch, leading to physics kicking in before the joints can be rewired. Reproduce the problem and publish the KSP.log so we can see who's the Screaming Victim and then can start to investigate.

Well… Got tired of programming on C#. So I gone to lose some time on forum, found this post and decided it would be fun to try something. A simple, definitively not fancy and way slower than what I had seen on Youtube - but common, it's my first Rocket Car and I made this in 5 minutes. More on my site. MOAR BOOSTERS edition! Got 369m/s on this one.

There's an easy and automated way to do that if you are using 1.4 KSP: Firespitter has a part called "FS3WL Water Launch System" (fsmovecraftgadget) that automatically moves your craft to the desired location at launch. All you need to do is to create a file with the data, select the file on the part, and voilà. You are there, no mater where (interesting explosions wait for you if you don't mind the colliders). That part is working on the latest Firespitter. I'm using right now. The 'North Polish" is a preset, by the way. note: The part works, but the coordinates are completely screwed up on KSP 1.6.1. note2: If using Vessel Mover, turn off damages before moving the craft. The wheels are getting destroyed on my vessel on drop. [You need to use Place Vessel, not Drop vessel. Duh. )

You are the robots. I'm not you, so I'm human.