diomedea

Since version 3.0 fairings bases are resizable, just right-click on them in VAB for the tweakable size commands.

I reckon the Karmony modules internals are mostly yet to be finished, so the issue I am having with lighting levels is probably going to be addressed anyway. However, as it could be of help, the images here are to show what the effect is now on IVA on another module (used a stock Mk 1-2, but any part with a IVA would do) when Karmony modules are attached. The effect of a single Karmony module attached is quite marked, though still bearable; it increases with the number of modules, and if something excessive is built (like I do for the last images) the lighting level becomes unacceptable. Thanks for all the excellent work already done, I hope the above could be useful to further improve this mod .

There are so many excellent mods that enhance KSP, it is almost sure any recommendation will leave something out. Would say, depends a lot on what you like to have. First off, mod manager. My suggestion is to go with KSP Mod Admin (if you use windows). Reality mods: sure you should look at Realism Overhaul, or to begin with RSS. Very tough, however. I like to use other mods that enhance specific aspects and bring variety to the stock game (yes, "stuff to do"). My list of mods that can't miss include FAR, DRE, RT2, TAC LS, SCANsat, MCE. For stuff, I like L-tech, Cacteye, Kethane, Interstellar, Extraplanetary Launchpads. Plus a lot more just to add beauty or features. All the above mods and those I forgot (sorry, I use so many I can't really list them all) are listed here: http://forum.kerbalspaceprogram.com/threads/55401-Community-Mods-and-Plugins-Library Plus, a suggestion: try one mod at a time, getting all at once is overwhelming. And, if something is wrong with your way of installing mods, you will not have a hard time to discover which mod it was causing trouble. Buggy mods: please note each mod was delivered for a specific KSP version and developed without full knowledge of possible incompatibilities with other mods. Issues may always be found, when using a different KSP version or a combination of mods different than the ones already tested. Wouldn't call those bugs, however. If you stick to using mods tested for the version of the game you have, you will avoid a lot of issues, and the few that still may emerge will probably be already debated in the respective threads. Final frontier: would say yes, best use it with a new game.

Found an issue with SteamGauges 1.5 and KSP 0.23.5: the new engines KSP introduced with the last version (parts in "NASAmission" pack) are not recognized by the HUD for calculating current and maximum TWR. If engines are mixed (active at the same time) only other engines are computed. Note from the Steamgauges sourcecode, in file SteamShip.cs, that TWR is computed from parts having module "ModuleEngines". The new engines have module "ModuleEnginesFX" instead, but there are no lines about current and maximum TWR calculations in SteamShip.cs for those "ModuleEnginesFX" parts.

Your progress has been really impressive. Congrats for the release of KSPTOT v. 1.0, really something to celebrate . Yes, I like all the options about different sets of bounds for plots. Too complicated? Perhaps (I will have to try to get how plots may differ if I limit the number of points, against a limited range of dates), but having all those different options may really help users get what they like, while keeping under control computing time and resources. About users, I would say that anybody going to use KSPTOT likes to handle complicated stuff anyway; however the learning curve is steep (it took months for me to learn how to use MA). You may enable specific options "only for advanced users", tying them to a setting to be managed via a menu switch. But I guess every KSPTOT user is going to select "advanced mode" anyway. About plotting multiple flybys, I like that approach, keeping it in but checking memory usage to prevent overflows. Together with stricter bounds, some of those plots may indeed be possible to generate within a 32bit memory space. And, even if MCR 64bit (up to ver. R2014a) proved not to be usable with KSPTOT, a future version may be working, allowing more memory to be used. And, TBH, I foresee more powerful computers to be used to run KSPTOT, than the ones currently available to the average KSP user.

Sure now KSP loads with that recompiled dll. And, tried with a Cacteye telescope already in orbit, it works. Albert VDS, many thanks .

Confirm, after updating HullCamVDS to ver 0.3 this mod makes KSP stuck at load time. All three processor parts are actually involved (high, mid, low). Tweaked a bit with various files, it shows the issue is related to the module "name= TelescopeProcessor" with each config file: removing just that module from the config files, KSP loads. I would suspect there is now a similarly named module with HullCamVDS, and that is creating incompatibility (the values within the config don't match with the HullCam module), but have to further investigate this. If it is a confirmed issue coming from HullCam, I am going to post over that thread to mention this inconvenience.

Unfortunately this thread has turned pretty ugly, since a number of ideological stances have begun to emerge. There is a reason if community rule 2.2.b "Discussions of a political, ideological or religious nature" exists, that is to prevent the flaming that always comes once posters begin to defend their own positions against any other, instead of peacefully discussing while keeping open to the possibility that the other sides may be right. Of course a number of posters here did not, but who did take such ideological positions showed why this and similar threads are always a danger. We better have it closed to avoid the climate get any hotter (so, even worsening the troubles due to the energy sources debated here).

Let me spend my 2cents here. The way KAC already implements transfer alarms could hardly be improved. The most we may ask is for an increase in the number of years the model solution is already calculated. To compute correctly the timing of transfer windows, with orbits that are elliptic and inclined, there is not a single formula to be used. The method used is a variant of iterative procedures, first used by C.F. Gauss in 1801, and requires to minimize errors in a system of 3 equations with 3 unknowns for determining the transfer orbit parameters (semi-major axis, semi-latus rectum, eccentric anomaly with the transfer orbit) given the positions of the bodies involved. Flight time with one of those equations is used to check the error against the flight time used initially. As the method is iterative, it can't really be applied to any tool designed to work in real-time, like KAC. The amount of CPU cycles required to solve for a single day and a single pair of bodies is already significant, but if used to compute along a number of years for all bodies orbiting the Kerbol system, that would either make KSP appear extremely laggy or stopped, or would not complete until after a very large number of KSP frames are elapsed (truly not acceptable real-time wise). Therefore, the best approach remains to use a table of precomputed windows, just what the model mode actually does. The formula mode in KAC, computed almost real-time, is actually close enough with most orbits to be good for a generic alarm. But for any transfer window that I really want to use, I prefer to double-check with Arrowstar or Alexmun tools. The more so with highly eccentric orbits like Eeloo.

Then yes, as I knew MacTee was already linking whole package with every release (what I actually download each time), your previous post seemed to me aimed at having the Curseforge link removed and another link added with only the .exe in it. Glad you cleared it. I am happy with whatever site and service MacTee chooses, sure the whole package is better to have.

Very nice, both the revised sorting UI and the added info. I am beginning to appreciate those images showing how you use your tool. Nice tutorials, more effective than a written manual .

Sure I must be one of the remaining 1% who much prefer to see addons accompanied by source code and license (as required by community rule 5.2), and I know many other users and modders who do as me. Very good reasons exist to have that, but am not going to digress here. You sure are not amongst those users, but that is your opinion only, not a proof of 99% users backing it. MacTee, please keep uploading complete packages of KSP Mod Admin, wherever you want them to be hosted. Thanks . Notice: as this thread is meant to discuss KSP Mod Admin and not how addons should be distributed in general, I need to remind that posts dealing with the latter risk being considered "derailing" (community rule 2.3.. To discuss relative merits of different ways of packaging addons, posts must be addressed to a different thread. To discuss Curse or curseforge, a thread already exists. Otherwise, you are free to PM me or other staff.

Tested on KSP 0.23.5.464, Win 8.1, i7-3770, 16GB RAM. Clean or slightly modded install, simple vessels, works fine. Then tried with the same install I use in game with KSP 32bits, plenty of mods, lots of plugins: a config that stresses the machine to the limit (virtual size RAM used 3.2 GB at load time, almost always close to the 4GB limit while in flight). Disabled Active Texture Management, Virtual Size RAM at load time jumped to 5.5 GB (DX9 and DX11), but at 2.6 GB with OpenGL. Works with "simple vessels", tried up to 150 parts (not yet tried most of plugins functionalities). However, the "real" vessels I use in game (more than 350 parts), still load in VAB but make KSP crash at initial loading in flight mode. Consistently every time, every kind of settings. Possibly it is related to parts connected to a specific mod, rather than just the number of parts. Each error.log report goes with "KSP.exe caused an Access Violation (0xc0000005) in module KSP.exe at 0033:yyyyyyyy" (location changes at each report). No specific info about a module causing the crash, must investigate checking with each single mod removed/reinstalled. For me up to now, this was an interesting test; however have to keep normal 32 bit files to play, until what caused the problem is found.

Hope your machine doesn't resent to have to work so hard! The results are awesome, I really hope to be able soon to make those on my PC as well . Definitely that second plot is much more useful and similar to what I was expecting . It is possible to see specific departure dates where most of the DV minima are concentrated, though dispersed in duration; those dates seem to come at each Kerbin-Eve synodic period, really what helps me to make sense of the plotted data. Believe that second plot is so good, it should not require to go further. Also, if 4GB RAM were used to have that, there is not much possibility to have more if we keep working with a 32 bit MCR. But certainly, this shows the limit. Any multiple flyby plot will require a lot more RAM to keep the solutions found (just for the added time dimension). Therefore, this plotting feature may have to be limited to a single flyby (until the time JPL graciously allows to use those computers they have to make plots for KSP). I notice the Delta-V range (color-coded) is very large (0 - 45 Km/s). I get you had to make the range so large or most of the areas in the plot would be blank (no solution), and it is definitely helpful to see all areas plotted, rather than left blank. However, the best solutions are all at the very bottom of that range, and color does not really discriminate among them. I believe that second plot is much better than the first also because it makes colors different for those solutions. One thought: would be possible to assign colors along an exponential scale rather than a linear one for DV? Instead of evenly spaced ticks every 5 or 10 Km/s, to have evenly spaced ticks at each power of 10 (10^N, and I would make intermediate ticks every 3*10^N: e.g. ticks at 30, 100, 300, 1000, 3000, 10000, 30000, 100000 m/s). One feature would be required next: possibility to zoom in a particular area of the plot (therefore, with stricter limits in departure dates and durations), and recompute solutions only falling within that area, so to generate a highly defined plot for that area (the zoom in feature already with KSP TOT porkchop plot enlarges the plot, but still draws the contour based on the points already stored; instead I would like to generate more points to have more defined contour lines). Or, the possibility for the user to set not only the earliest date for departure and arrival (so to define the left-down corner of the plot) but also the latest dates to be plotted (and so, the right-up corner). Or even both the above features, as some users may like more the first and others the second.

On my Win 8.1 PC, for unknown reasons, KSP TOT always fails to find MCR the first time it is launched (after a machine reboot). It always succeeds the second and following times. Therefore my suggestion is to just try it a second time, it may work if you have the same issue.

Excellent. Seen how fast version 0.2 with the fix for AGs arrived . Easily could scale the model, making new config files for parts of different sizes (but tweakable will be the best), and mod the masses (and costs while at it) to go with the sizes . OK about physicalsignificance; I also like parts to behave as they should, though with high part count some efforts at limiting computing physics should be done. Glad you're considering those suggestions. Happy also you are about new textures. Glowstrips seem easy to make into nice signs, I'm considering to make a few to customize my ships (e.g. left arrow, "exit", "snacks here"). However, this is where I found a problem: I missed to find a reference to the textures packaged with config files or the sourcecode; so my take is the textures are linked with the MU models. Sure I can make a new texture file and name it the same for an existing one, but that still makes only one texture available in all. Could some trick be used to allow different textures? (A mod allowing to choose different textures at runtime is Fustek Station Parts)

philly_idle: exactly as you initially wrote, no issue if you just mod it for yourself. But sharing would be a violation, anyplace but "kerbalspaceprogram.com" where you upload the original or derivative mods. Even if you were sending by e-mail, as it would be "hosted" on the mail server. Even if you were allowing others to download directly from your own PC (as it would then become the host). I agree the original author citation requirement would not make sense if one is only allowed to keep any derivative work for themselves. But the author wanted derivative works to also be allowed, hosted only on "kerbalspaceprogram.com". Anyway, that second sentence in the license "...may only be hosted on kerbalspaceprogram.com" may have to be read differently. When the mod was published, Spaceport was the only official download site for KSP mods. Then, it may be implied the author's intention was to always keep his mod only with the official download site. What if Squad changed name and registration domain for Spaceport? All contents would have remained with the site, but still that site would not be named as required in that sentence. Now, there is a new official download site, supported by Squad. Could be implied that the author's intention would be to have his mod available there? I am not taking a conclusion now, and probably this will in the end be the matter of Squad's legal staff. In case the above was considered an acceptable interpretation, there could be the possibility to migrate this mod from Spaceport's archived data to curseforge.

OK, sorry. I can see your name as releaser on that github page, that's why I wrote so. But indeed the release date tells differently. Perhaps it's a glitch with github when rights are transferred.

If you have a correct download file with RT2, you have a zipfile that just includes the folder structure as required starting by Gamedata; as you stated to be able to install mods, you certainly know what is required is just to copy that Gamedata folder within your KSP install (so it updates the existing /KSP/Gamedata structure, effectively placing the RemoteTech2 files where they need be). But, as you say this doesn't work, means you have a uncorrect download. RT2 ver 1.3.3 can be downloaded from the new repository created by Starstrider42; I also want to suggest to then install the patch from this post.

Thank you a lot, very interesting to know those details on the flyby search algorithm. So you made me think about those angles again, and (of course) you are right. I wasn't thinking that the outbound orbit may pass at the perihelion before encountering the destination body. If only the most direct orbital patch was considered, then the phase angle would be relevant: with any body at a phase angle lower than the flyby body, it would be impossible to get a gravitational assist in the correct direction. On the graph below there is a correct flyby on Duna, found by MFMS; and in purple I sketched what kind of orbit I had in mind. So, the correct algorithm shows I can almost always find a valid outbound trajectory, going the longer way. About displaying info. Certainly I don't want you to replicate what PLAD already did. I expect DeltaV to be a continuous function (where solutions exist) of time, duration. So I would like the possibility to have it plotted as a continuum. I did not consider MATLAB plotting limitations, however. Definitely agree duration would show large jumps, finding continuity may prove hard. If going by the different graphs, my preference would be with your second option, all referenced to departure time: would make easier to follow the evolution in time. No bugs found yet (but I am doing almost exclusively flybys now, new MA features are still unknown to me). I am coming to the conclusion the single flyby sequencer is no more useful, is slower and probably still affected by that Vinf issue you corrected with the MFMS (so it outputs worse solutions than the MFMS).

Another excellent suggestion. Thank you . BTW, very happy to find a new version. Impressive work!

Yes, seems to work for me too. Thanks for your suggestion .

Yes, unfortunately (had to try, I'm not so fond of other parts to try using them in all possible positions). So that may not have a solution until Squad deals with it. Thank you a lot .

Sorry in case what is below was already mentioned (though I can't find about it with a fast thread search). I am testing what I can achieve with Fustek X0.04-3-1 Dev parts. Really beautiful, but I find an issue while surface attaching to them in VAB. Any of the Karmony modules, when rotated horizontal, show to have a single point from where the collider direction is oriented. That makes other parts to automatically rotate so to follow what appears like a spherical surface when in contact with a module, instead of the cylindrical surface of the module mesh. Those other surface-attachable parts will actually get attached with their center to the module mesh, but oriented in relation to the single-point center of the module, instead of the module center axis. With the warehouse module opened, that behaviour is also found with the internal surface. The same modules, if kept vertical (as they initially are, not rotated), are absolutely fine, surface attachment works well (parts are oriented in relation to the vertical center axis of the module). Sorry for any terminology mistake (I may not have right what a collider is, not being a modeler). Here a short gallery of images that should show the issue.

Display: yes, I wouldn't know how to say that better, total flight time and departure date on 2D axes, Total DeltaV color-coded. It could come useful to allow to select each body in a (multiple) flyby instead of the destination, and show total flight time up to that body and DeltaV with that flyby, but other combinations may be found working better and this is a field where I have yet to build any practical experience. Memory. Thanks for talking about that. Flight time! I have to think a bit about that, my feeling is valid solutions must be bound within a lower and upper limit, however it is a different approach than what I believed. I had hopes there was an angle relationship, valid flybys could only be found if the phase angle of the flyby body was within some specific range of values. Should be time for me to see if there is any corollary to the Lambert's problem solution useful in this case, instead of making you lose time .