diomedea

Please find it here.

Anybody else here who has this issue? Toolbar plugin by Blizzy allows to change button order. That works, for me, with every mod button using the toolbar. Every button, but for the one from Ingame notes and the one from Kalculator (both mods by agises). If I use the toolbar menu to unlock the button order, I can then drag buttons around within the toolbar and have them snap to another position. When a button is dragged, an orange line appears to show where it will be inserted if released in that moment. With the buttons from the mods by agises, I try to drag them but only the "orange line" appears (before actually moving any button) and moves with the mouse pointer within the toolbar, however these buttons stay put and don't change position (are not draggable). And, while the orange line associated to these buttons is shown, the whole "button-ordering" feature ceases to work (I have to either drag the line outside of the toolbar, or to lock the button order from the toolbar menu, to make that work again. After moving one of the normal buttons, the KSP log gives: Instead, doing the same with Ingamenotes button, I have this: Here how any of the normal buttons are dragged within the toolbar. Here after clicking the Ingamenotes button with the button-ordering feature active. Note the orange line shown even before actually dragging it. Here the orange line is dragged around within the toolbar. Note that the button stays put, does not move with the pointer. Here the orange line remains active (and the button-ordering feature is locked) even without the pointer in the toolbar (can't show that, but mouse button was released also). Toolbar version 1.4.2, Ingame notes version 0.7, Kalculator version 0.1

Thanks for your answer. Well, that is another nice idea, to have "BaseActions" included in Action Groups. However, I must have been unclear about the aim. I would like if the total of Action Groups could be extended from 10 to some larger number. So many parts now exist that have actions associated to them, but hard to make in the few existing Action Groups. To give an example, with any of the camera parts from the HullCameraVDS mod I have 11 actions associable to AGs (not that I am going to use all AGs for those, but...). I am not worried about keybinding, but certainly that would then be the next step to deal with, if AGs number could be greatly raised.

I would really like the first, is a bit weird IMO that a dish pointed at a planet can contact anything in its cone of sight, but if pointed to a craft none other. About the second, I sense some issues may come from that (e.g., what if an "array" is so sparse that some of its members are actually outside of the dish cone or range?). Believe Ralathon could be right in this regard.

OK, thanks. Have never gone in depth with Unity objects, and I missed you were not talking about one from KSP itself. Hope I am not actually making you lose time. But if that is a Unity concept, and KSP uses it as a template to build one of its own objects, then it is very possible that KSP never creates instances of a Prefab, just creates derivative objects based on that. Of course the GetPrefab() method is inherited as well, but I miss to see how you could find anything belonging to the Prefab class, while there may be plenty of objects of other inherited classes.

@ codepoet: just a guess here, I don't really know about Prefabs. But if you resorted to a brute force attack to find something...could Prefabs have anything to do with Subassemblies (what goes saved within VAB/SPH)? If you have none in your development copy of KSP, then you would never find one.

Thanks for your point, it is certainly true given how difficult it is to bind some keys in KSP, and deserves be reminded. Anyway, let me state that again, my interest is about allowing KSP to recognize more events of the same kind (class?) of action groups, not about how those events are invoked (user banging keyboard or plugin setting them). Sorry if it may not sound right, but I have no idea yet of how those "events" are named within (internally to) the game.

While I would like KER to include such a feature, I suggest this mod I am using: RCS Build Aid. Only works in the VAB/SPH, not in flight, but better than nothing. It provides Delta-V with RCS for the ship as a whole (instead of for every stage) so it may require some effort to determine RCS thrust at each stage, but it is usually good enough for probes, lander modules last stages and orbital tugs.

@ Sir Julio: given the experience you built with this mod, I believe you may know if any possibility exists to increase the number of action groups recognized by KSP. Even if it may require another mod to make so (or be another feature to add to this one). Not so much about binding more keys to more action groups, but if the amount of different events recognized by KSP as actiongroup activations can be changed. May this feature require to change a class definition in KSP code? If so, such class may be amended or is closed? Would like, if you have any idea about that, if you could provide some details on how it may work.

Hi Papa_Joe, in a way yes, that is correct and your suggestion on spot to prevent similar issues. Had I deleted notes 0.4 completely before installing 0.7, that would not have happened. In the end it seems like old files were kept, while new files did not go where they should have. I actually let an automated mod manager do that update the first time, so the different structure of the mod versions may have caused some garbling. When I resorted to do the install by hand (the second time) all went well.

Works fine here too, since when I reinstalled 0.7 for the second time and every file was put where it belongs. That was why I could not replicate the issue at first, notes 0.7 was working. Thanks again.

Found what the issue was , was able to make that happen again and made a couple screenshots. The toolbar is positioned in the lower part, left to center. Somehow, the texture files from version 0.7 were not installed, or at least not where the plugin wanted them to be. I was made to believe it was all OK with the texture file as I could still find the previous icon.tga file from notes o.4. Agises, thank you so much for this fine tool. In a way, by suggesting I could have left two notes.dll in, you made me check what the differences in the installs were (so to see if the dll was put in different places) and so was clear that the texture folder and files have changed. To your other question, I always use the most recent toolbar, 1.4.2 indeed. I have been using it since the very first public version, with a lot mods that make good use of it. But that weirdness was the first time for me. Now it may be clear from the screenshots, anyway there is one button without texture (but active, it opens Ingame notes) while at the same time the toolbar is sized to count one button less than the actual number. In the VAB shot, it shows I had a full row of buttons gone outside of the toolbar rectangle, all of them could not be used.

Cannot. Didn't take one while having the issue, but after cleaning the mess and reinstalling (both Ingame Notes and Toolbar) all goes well. And keeps well even with the latest version, now. Will stay put if something similar happens again.

Issue report. Installed Ingame notes version 0.7, was using version 0.4 previously and all was well. However, now there is a button with no texture on it on the toolbar, still opening this mod main window (it was textured correctly with version 0.4) and, what is worst, the toolbar seems to not be counting correctly the existence of this button: this button is drawn within the toolbar, but other buttons (form other mods that have always worked fine and did not change) now are "pushed out" from the toolbar. Just a guess, but seems like a toolbar method is called so to place the button, but another is missing so that the toolbar is not sized accordingly to the presence of this button.

Believe you did not miss anything, I keep checking everytime if those icons were released, nothing yet.

First, thanks again, happy to know you have already plans for some of the improvements I want. About the "Documentation": that is one of the pillars in Configuration Management. All information about a project/system in CM is kept in sync with the parts. So, e.g., blueprints or technical sheets, and even user manuals, are versioned and valid only in relation to a specific version of the items mentioned in them. In software industry, documentation includes about everything but the compiled object: case studies, analysis, CASE diagrams, models, source files, and anything to be read by the users. In case of KSP, we are not involved with what Squad does to manage it. The only "documentation items" we may have available and (in case) be interested to keep versioned, should be source files and version notes with mods. Even if I am writing about this possible "feature", I may not ever use it. But, in general, somebody may find useful to have that feature to keep consistent records of everything about KSP, and KSP MA has the potential to make so. So, my idea is that another tab (at the level of the ones in KSP MA for mods, parts, crafts, flags...) should be easy to make (believe most of the code done for other tabs can be reused), and allow to enter information about any kind of document if someone wants to keep a record.

Most of the plugins listed in the opening post include already this tollbar plugin, so if you install them (within KSP/gamedata, as every mod should be) you will already find a folder "gamedata/000_Toolbar" has been created. And that's that, you run KSP and it works (unless you have totally different issues). But, plugin versions created time ago may include a toolbar version as it was available at that time. The version with this thread is, however, always the most recent version published of the Toolbar. Therefore, you should download and install this later version so to replace whatever came with another plugin. If installing new plugins in future, you should take care to not overwrite this newer version with what version those plugins include. With past versions, it was possible that some plugin installed the toolbar plugin in different places, and when KSP was run, the many toolbar_plugins found were run concurrently, creating issues. That issue should now be solved as of toolbar version 1.4.2.

This is a very useful tool, and gets improving. Many thanks for it. I have been using it for a couple weeks now (in parallel with my system of manual recording my installed mods I kept doing before), and KSP MA has proved accurate and dependable, so I may soon forget about my system once I finish reversing all supplementary info with each mod (author's name, notes, version). For the record, I keep notes of (up to now) 97 "configuration items" (mods, mod-mods, and tools) tied with each KSP version. And in case, yes, that develops from configuration management (CM) practices used in large projects. I have a few notes about KSP MA. It may be some feature exists, but I was not able to find or to use those. Or, maybe, it could still be possible to find ways to improve it? 1. Automatic update of list entries. All is well when I add a new item to the list. Quite often, this "new" item in KSP MA is a newer version of a mod already installed. If I just "process" this new mod version, it gets installed over the existing one, however, the existing one still remains on the list (so, KSP MA still provides an entry for an item that was radically changed, but has no info about that change with that entry). The only way out is, for me, to find and remove the previous version, before processing the newer one. Suggestion: could KSP MA use a check, if a new item is corresponding with previous ones (it may require to verify one or more key files with the new item are already existing, in the same folder structure), so to remove the previous entry in the list? 2. Mod-mods. A bit of clarification here: a mod-mod is anything conceived to alter, or improve over, an existing mod, and in particular if originated from a different author (so, it would not generally ever be included with the main mod). One single icon or texture or config file, if provided separately, is a mod-mod. I need to have those recorded if I want to be able to replicate an install. Issue here: mod-mods are generally not created by programmers, and don't include a folder structure according to the gamedata folder in KSP. So, where and how to put them to work, must be provided to KSP MA at the user responsibility. Mod-mods should be listed with a clear reference to the main mod thet are built for. To show, they could use the tree structure that KSP MA already shows with each mod files. But, it should also be possible to make them clearly out as separate items (listed with other colors? a different icon?) that also must have separate information about them. Note: until a time when KSP MA allows automatic removal of the old entry with a newer version of a mod (as suggested in 1.), removal of a previous version before installing the newer one also means to remove (without even noticing) all the mod-mods with that. 3. Tools. With tool I mean any software item created to have significance in KSP, but not depending on KSP to be opened/run. KSP MA is certainly one such. Just like mods, tools also are versioned and there is need to keep track of them. It would be useful if KSP MA gave the possibility to record tools, of course those don't go installed within gamedata, but it may be let to the user to provide another directory where to install them. KSP MA may mark them apart from mods, again with another choice of color or different icon in the list; however best thing should be to have a different panel in KSP MA for tools (as mods, parts, crafts, flags...tools!), provided that information fields like exist for mods can be used for tools as well. 4. Documentation. It could be relevant for someone to extend recording to documentation items, meaning any human-readable item connected with KSP (personally, I would not use that, but someone with CM expertise may feel better to have it. Documentation is, generally, one main area to be kept within CM). Such items may only be recorded, using the information fields KSP MA already provides for mods. Best if those are listed with yet another panel.

That's a nice, useful tool, able to solve Tsiolkovsky equation for different stages. (it works with any spreadsheet able to open MS Excel files, does not strictly require MS Excel to work). One thing: total Delta-V is given from stage 1 to stage 20 here. That is more similar to how stages are numbered IRL (let me say, as NASA does). KSP numbers stages in reverse order however, so it may come useful to make that in reverse as well. In case you are going to implement something more complex, like calculating mass of every stage considering what is the mass of the stage before it, that becomes a relevant thing to consider. Another useful improvement: as it stands now, those equations are only valid in case of pure sequential staging. In KSP it is often the case that stages are run in parallel for some time, so thrust is added from all engines active. That requires also to know the burntime for active engines (and that changes with atmospheric pressure) so to know how much fuel is spent before other engines are shut off, and then solve the equation for a pure single engine type (same ISP). Moreover, while different engines are running, ISP to use is the average for all engines. See here for better details.

Be sure I am not implying what you wrote. My point was very different, and making that "silly" appreciation in that way makes my opinion very negative. Those computational tools (I know about a lot of them) certainly would fit a CPU, that as you suppose can easily be considered already existing within a command pod. But it would be more than adequate to consider parts also as SOFTWARE. And that software must actually be installed within that CPU or you don't have it. So much, I would say it is immersion-breaking to NOT have a part (to each his own! You are entitled to your opinion, others to theirs). When we will have to compute the cost in building a craft, we are going to add also the software parts installed (no pirated software here). What I agree with, instead, is we don't need any hardware parts unless those are very specific with some feature in the mod that has reason to exist in a hardware piece. Take, e.g., the MechJeb Pod. I hope now you get what I mean. If you don't concur, that's to you. If you dare again to mark anybody else's opinion as silly, I will request a ban on you.

Mun rotates, or you would not scan anything else than along one single orbital path, always repeating. It is tidally locked with Kerbin, meaning its rotation period is the same as its revolution period around Kerbin.

Well, thanks for explaining, that weird coding is certainly not your fault. Even if that's just the attribute file, and that has to respond only to how biomes are managed and coded within KSP, it still seems unnecessary to me to use floats. Each biome image, just as you said, must have the colors for each point coded as bytes. So, why to use floats in that attribute file, just to make those colors correspond to a specific biome, instead of using the same, trusted and proven byte-long format? So to make KSP internally have to make some translation of sorts, because they like to use floats with every kind of data? (sorry if the above may seem a bit rude, I have nothing against you, but just can't understand why things are made more complex then they need be, at least in my view of things. If you or others have hints on why they resorted to such coding, I would appreciate it).

The NODE one is the easiest. It will orient the ship in the direction for the burn at the next node. Of course you must have at least one maneuver on the orbit for it to work. The other buttons will orient the ship according to the function, so if you have a target selected TGT will orient otwards the target, RVEL along the relative velocity vector. With ORB you can orient the ship according to the orbit, using the 6 buttons below (from GRD+ to NRM-, those the prograde, retrograde, radial inwards, radial outwards, normal and antinormal directions). With SRF you can orient the ship in relation to the surface, use PIT, HDG and RLL to specify those angles. KILL shuts off any orientation. Then, set the Throttle and Burntime. You can open a side panel where you can find a list of all single maneuvers ordered (yes, you can stack many single maneuvers, and you can set the time when each one is to be executed).

Many thanks. Works exactly as desired. I join 5thHorseman as experience with manual maneuvers is invaluable here. Do it a few times, and you develop a sense of how the orbit will develop. Well, PreciseNode is precisely the kind of tool that lets you do so in a better way, rather than just grabbing the maneuver gizmo around. I always go for the perfect burn by adjusting the velocity components in PreciseNode, and then continue to move the timing with those components until I set the maneuver with the minimal total DV bringing the orbit exactly where I want it to be. So, my end result is exactly what you want but is done by hand. I actually move all velocity components at the same time. Now, you certainly know some maneuvers are best executed at periapsis, some at apoapsis, while inclination corrections at the nodes. So, matching different maneuvers together actually means to have a sense for timing with all those single maneuvers. If mixing, e.g., a change in inclination with a raise in apoapsis, those are unlikely to be more convenient when combined, even if one node is at periapsis (because you would spend more DV to change inclination while your speed is greater, so it is best done with a node next to apoapsis). Instead, for changing inclination and periapsis, they go together very well and perfect when the apoapsis is aligned with a node. So, if timing for both single maneuvers is the same, joining them together is just as simple as to add the single velocity components. If timing for the two maneuvers is different, it may not be convenient to do them together at all. But I believe you know when not to join those maneuvers.

I am wondering who ever made coding colours with float numbers. RGBA values are generally single bytes, colour coding is normally seen in the hex range $00-$FF for each colour channel. Using floats with colours would make images a lot heavier than they are. (And, single bytes are the most complex way to coding colours ever used in IT. Someone here remember the days of EGA or VGA, we had only 16 then only 256 colours to choose then).