Dunbaratu

I see potential for a problem if it's not a toggle option but instead is always on when you spectate. You might not realize the other pilot was going to move your clock forward, and were only intending to look for a bit and then switch back to your own work - which is now ruined because you missed your window and can't rewind the clock. I figure just have a button for "lock sync" versus a button for "once sync". "once sync" works like sync does now - it just jumps you forward, whereas "lock" sync would jump you forward and then keep jumping you forward with that person when they do. Maybe a little padlock button next to the sync button - click the padlock to lock the sync.

Is there a way, when spectating another player, to slave your clock to theirs so when they time warp or phys warp you just automatically jump ahead with them? Having to constantly watch for the sync times when someone else does rendezvous or docking and thus is warping a lot can be really error-prone.

I just thought of an idea that could solve an annoying problem. People like to watch each other as they do stuff. One fun thing is to be piloting a space station and watch someone come in to dock with you. But in practice we've NEVER gotten this to work because even when the two clients are synced to the same time, they keep "arguing" with each other over the exact position of the station. It keeps teleporting around once a second or so, jumping several meters this way, then several meters that way, and so on, making docking with it impossible (and deadly when it happens to jump to a position superimposed with the incoming ship and BOOM.) The problem seems to be caused by the fact that one client, let's call it the "passive" one, is piloting the station and the small changes it makes with full physics on cause the on-rails calculation of its position that the other client sees, the "active" one, to be all over the place. To fix this, would it be possible to allow a player to put the camera on a vessel but choose to lock himself out and be passive (as if someone else was controlling the vessel even though they aren't) and treat the ship like it was on rails but at 1x speed? You know how when you go to 5x rails speed you are able to swing the camera around and look at things but you cannot touch the ship? Is there a way to enable that rails mode but have it doing that at 1x speed? That way the "passive" player's client won't be constantly messing with the position of the station and making it jump around. Only the "active" player's client would be in charge of choosing both the ship and the station's positions.

Can anything be done about these keyboard focus issues with the chat window? 1: You can't focus on the chat by clicking on just the chat window- you have to click on the specific narrow chat input line. Is there a way to send focus to the chat line upon any click on the entire chat window? 2: When typing a line in the chat window, if a player connects or disconnects, the message that appears in the chat window to tell you that they have joined (or left) the server causes the keyboard focus to shift away from the input line while you were in the middle of typing. I've lost lots of craft that way because of how often you type "spacebar" when typing text words. When the focus is taken away in the middle of typing text, I end up activating a stage with the spacebar because I type too fast to stop myself upon seeing the message appear.

No. Really pretty much *any* exception during the loading process causes parts of the ship to vanish. KSP doesn't protect itself against exceptions when loading PartModules, and it just quits wherever it got to so far at that point when one of them throws an exception - leaving the rest of the vessel unfinished. It's a bit frustrating because it's a very common symptom of just about *any* problem during the loading process, so often totally unrelated problems get reported as the "same" problem because users see this same symptom as the end result of several completely different problems.

That's weird because I had the exact same problem back in 0.13.1 so I didn't see it as a 'new' bug when I saw it in 0.14. I was like "yeah but that's always been that way - that needs to be addressed eventually".

Loading/saving has *always* been unreliable with kOS for me. *Always*. kOS attempts to put the computer back into the same exact state it was in when the vessel went on rails, by reloading the program from disk, putting the instruction pointer where it was, and restoring all the variable values to what they were. That system has never worked for me, and has always been prone to throw exceptions that cause the ship to get truncated. I'm in the habit of turning the kOS computer off before saving the craft to avoid the problem. I'm not 100% convinced that 0.14 introduced the problem. It might have just exposed an existing problem. For those who found the problem, is it only quicksave/quickload that does it and regular save/load still works? That would be really weird because they're both the same exact system just using a different filename to store the persistence file.

Nope, I knew that. and it's not entirely correct either. The origin point is only *near* the current ship, not directly ON it. When you first come off rails, the origin is right on the ship. As you fly in normal physics time after that, however, the ship drifts away from the origin. But in any regard, it wouldn't matter because I'm getting the relative *difference* between the two vessel's position readouts, and setting the tail of the arrow at the vessel1's position, so it should work regardless of whether vessel 1's position is (0,0,0) or something else.

Maybe the only thing I can do to bypass KSP's undocumented API is to just explicitly get the Unity Transform of the Vessel's Root part and use that to get its position. Then at least I know I'm getting the same consistent definition all the time.

I was wondering if anyone else can confirm this behavior because it really doesn't seem right and I'm wondering if I'm misunderstanding it. As far as I can tell, the definition of Vessel.GetWorldPos3D() seems to vary. Sometimes vessel.GetWorldPos3D() returns the position of the ship's center of mass. Other times it returns the position of the ship's root part. Can anyone else confirm that I'm not nuts here and this really is the way it seems to work? It makes no sense but it would explain some of the weird behavior I'm getting if it was true. Basicaly I'm doing this: arrow vector = ( vessel 2's GetWorldPos3D() - vessel1's GeWorldPos3D() ). Draw this arrow vector with origin transformed to vessel1's GetWorldPos3D(). And getting a picture of an arrow that is aimed as if it was pointing from vessel1's cockpit to vessel2's cockpit, BUT it's origined at vessel1's CoM instead of vessel1's cockpit so it looks wrong.

How about if kOS just allowed you to choose your own archive folder as a setting property in config.xml? Choose any full path string you feel like, like "\users\myname\myscripts\" or "/home/myname/myscripts" for the unixy users, and make kOS just treat that as your archive location? Then you can put your dropbox folder wherever you feel like in your directory structure and just give kOS the full path to it.

I like all these ideas, but not the "call it a day" part. They're alternate types of query to perform, but at the core of the entire system I'd still really like to see a WHERE clause for making sublists of larger lists be the low level engine underneath everything else. LIST PARTS IN MYLIST WHERE some clause here Where "some clause here" is any expression with a placeholder variable 'val' that does the work: WHERE val:Name = "some label I gave the parts". WHERE val:ACTIONGROUP = "action group I'm querying for". // More complex example: find all the engines that are mounted upside down // relative to the main root part: LIST PARTS in allParts. SET rootPart = allParts[0]. SET upsideDownEngines TO allParts WHERE val:TYPE = "engine" and VANG(val:ORIENTATION:VECTOR, firstCore:ORTIENTATION:VECTOR) > 170. Basically regardless of how people identify "this is a part I'm interested in", whether it's with a label maker, or an action group, or something else, we'll need some sort of syntax in kerboscript to specify that such a filtering condition is being applied to the parts. And I figure it probably takes no more effort to make it generically apply to all lists (whether they're parts or something else) than it does to make it apply to just parts - so it may as well be done generically on all lists. At least that's how I see it. You may have a different vision. At any rate, I see the problem of "how to identify if this one part is the one I want" and the problem of "how to query all parts for the one(s) I want" as being solvable completely independently of each other. I.e. in one update we might put out the label maker idea and add a suffix "LABEL" to all Parts. That alone would allow people to perform the part query manually anyway in a for loop. Then in a later update, add the where clause idea to make the for loop into just one line of code.

That's not a bad idea. Hmm. Now I'm picturing a part that you can only use in the VAB, that doesn't stay attached, that looks like this:

I want to highlight an important aspect of the update that was boldfaced, but the boldfacing got lost in how it was pasted into the forums. It's quite important: The usual setting in the past was 100. But that was 100 when counting ONLY the mainline code and never counting any work done by WHEN,ON, and LOCK. Now that these are being counted, you need a slightly higher setting to get roughly the same performance as you had before, under the assumption that in a typical program about half the execution work is done in WHEN and ON and thus wasn't being counted before. The reason we couldn't just automatically increase the number in the mod's update code is that whenever you run the mod, the config file is written, and once the config file is written, its values are taken as gospel and override whatever the mod's defaults are. So even though we changed the default from 100 to 150, that change won't take effect for anyone who had already run the mod in the past and thus already had a config file.

I get the same effect sometimes and I never use MM to put kOS into a main pod. Something is crashing during the reloading of the vessel from on-rails to full-physics and the code SQUAD uses to reload the vessel is very VERY fragile. If *any* part's module code throws *any* exception during the reloading process, then KSP aborts the loading of the *entire* remainder of the vessel from that point onward and you end up with a vessel with only some of its parts having been brought into existence. This is why truncated craft is a very common effect of a large number of different bugs from different mods. I don't suppose you happen to have the KSP logfile from that event? (Probably not because it overwrites each time you run, but I can hope).

The craft file would store the name, not the SCS part. The part just has to be there because there's no code running at all from the mod if the part containing the PartModule isn't present yet. You could add the SCS part, name bits of the craft, and then throw the SCS part away again and the craft should still have the names on it that get saved.

We've been tossing around the idea of some generic where-clause to trim sublists down: Get a sublist of a list where the sublist consists of all the elements in which (condition you write about an element) is true. something vaguely like: LIST PARTS IN mylist WHERE (some boolean condition you can make up as you wish). Thus you could get all engines where engine type is blarg, or get all parts where their type is WideAngleLight (or whatever the type name for that is called - I can't really look it up at the moment, but you get the idea.) I'd like this to be something not limited to just getting parts. I'd like it to work on *anything* of type LIST(). It may be possible to also write some code that activates inside the VAB/SPH editor to let you name parts yourself, but it definitely shouldn't work with the tweakables menus, as that requires adding a module to every part and that's an ugly messy bug-likely approach. When more than one mod tries doing that at the same time they can end up stepping on each others' toes. It may be possible to have the SCS part's kOS Module add a general UI button to the editor screen (so you can't access it until after you've added an SCS part to the craft, and therefore it's not something we have to do to every part in the game). Clicking the general UI button would then let you subsequently click on a part of your craft somewhere, and it would pop up a name to give the part. Thus the module code we write isn't attached to all the parts. It's module code attached to just the SCS part saying "point at another part and tell me what you want me to call it". This, given the way KSP modding works, should be doable without having to use modulemanager to add our code to every part. KSP allows parts that exist on the craft being built in the editor to run code right away while still in the editor screen. (Thus why kerbal engineer can show you the dV readouts during building), and that code can do things like read the mouse to see what part of the craft is currently highlighted under the cursor. I'm not saying I want to rush off and do it right now, as it's a nontrivial bit of work, but from what I've seen, that approach is possible. Ideally both could exist eventually - WHERE clauses for lists, and also being able to give parts kOS identifier names in the VAB (and save those names in the craft definition file). Not promising anything - just saying these things seem, in principle, to be possible. It's all just a matter of what is it worth spending the limited amout of free time on, since there's not enough time to implement every idea that's possible to implement. It's a matter of doing triage of programmer time.

This makes for a good user interface, but has one technical difficulty: It requires adding a module to each and every part in the game (to make the tweakable menu allow you to name it), and that means using something like the ModuleManager mod, which is a PITA to work with and not break things.

I've slowed down on pushing for adopting that because of the recent change that now allows any of the things kOS previously only gave out as Rotations to now be retrieved as Vectors. This has opened up a number of workarounds that were previously impossible. If you can convert rotations to vectors, then you can turn the cardinal directions of most interesting frames of direction into basis vectors of a reference frame. Once you have the 3 basis vectors of a reference frame, then you can see how any vector would be represented in that reference frame using those 3 basis vectors and dot products. It's not an ideal solution. It's still just a workaround. But the existence of the workaround made it less of an immediate need. I've been putting my spare time into working out a way to store the compiled program as a "machine language file", so you don't have to send source code on remote probes. It's one of those things that looked a lot easier at first before all the ugly details were dived into so it's been sucking up all my kOS programming time. Reference Frame - aware vectors is still a thing on the back of my mind, but of late, erendrake and I have had our minds more concentrated on the basic language features like better help, more organized OOP style features, and so on. We ran into a roadblock where many of the new end-user features we wanted to make all required things the language just couldn't do under the hood, so it was time to overhaul a bit of what's going on under the hood.

Except he didn't even have *those* skills either. He was no innovator, no visionary. What he did know how to do, was say "no". He was an idea *filter* not an idea *creator*.

The issue you linked to is flagged as "not a bug", meaning they won't actually make the change you seem to be afraid they'll make.

Without Woz there wouldn't have been an Apple computer. I don't mean the company. I mean the computer. You can't sell a product unless someone knows how to actually *make* it. Jobs' influence was mostly as a negative filter. His major influence was in saying "no" to his company's innovators a lot more often than saying "yes', and thereby cause a very strong uniformity of user interface. Jobs never really caused any ideas to happen. The credit he deserves is that he stifled a of bad ideas to ensure they *didn't* happen. But he took that idea too far to the point of being annoying.

Because they *call* themselves technology enthusiasts while not actually *being* technology enthusiasts. Actual technology enthusiasts know to credit the engineer, not the monitizer in the CEO's chair. There's also a lot of people who wrongly think Bill Gates is a good programmer. He was fairly lackluster when he was going through school and did a lot of copying. But at least he knew *something* about it, once upon a time, back when home computers all used BASIC. Steve Jobs was just the friend of a computer expert who needed him as a business partner.

This is certainly a part of any problem. There's a lot of things that would *in principle* be possible but *in practice* given the way the KSP API is structured are very hard to do quickly with limited spare time, using a poorly documented API that often doesn't do what you assumed it would when you start working on a feature. I remember spending about 8 hours of programming trying to figure out how to the use API to work out how to calculate STAGE:LIQUIDFUEL better when it kept returning wrong numbers. It turns out the API for "find all parts that hold resources that this engine can consume" is a royal mess because theres 3 utterly unrelated things to test for, and also the yellow fuel hoses use a totally different API than every other part does for this, for no apparent reason. None of this was doucmented -it was all found with trial and error, using a system that takes 5 minutes to run a test after each code change because you have to relaunch KSP and start flying the rocket again from the start sometimes.

I think it's more accurate to say that I don't understand what you're asking for, and how it would differ from the more generic solution of just getting the orientation of any part (which would cover engines, fuel tanks, whatever), which admittedly doesn't exist yet but we want it to.