cybutek

A few people have had that problem... I am unable to replicate it and am yet to get a log file from any of them. If you're able to post your output_log that would be greatly appreciated

Looks like there could be a bit of a bug. I'll delve into it and try to solve for the next version.

It works exactly the same as normal, requiring a mod version in both the local and remote version files. The GitHub field is for synchronisation only. Basically put, what happens is that if a GitHub field is present it will also check the remote version against the release versions (tag) on GitHub. If a GitHub release version does not match the one in the remote version file, it will not display an update. This solves the problem with regards to committing an updated version file before having actually released it. Without using this field the act of committing an updated version file to GitHub will notify users of an update immediately, even though it's not actually available for download. Hopefully that makes sense

This is because it's doing a local compatibility check with the version file included with the mod, not the remote one. I would recommend in this case altering the version file that is bundled with your mod to be: KSP_VERSION:"0.24.2", KSP_VERSION_MAX:"0.25" There is information about these extra optional min/max fields in the readme. This will get rid of any compatibility warnings for anyone using versions 0.24.2 through to 0.25, but will still cause a warning if they use 0.25.x or 0.26 for safety reasons. Of course this relies on anyone getting this compatibility warning to re-download the bundle with the new version file. It might be worth incrementing your version by 0.0.0.1 so anyone continuing to get the compatibility warning also gets the new version notice as well. It's always safer to assume your mod will be incompatible with the next release and put up with doing this little update, rather than it say it's compatible and end up not being. I'll have a look into the possibility of making this easier in future versions of KSP-AVC.

They've always had a cost and never had a weight. Even though it may say a weight in the VAB/SPH, this is just because the game requires it. They are set to be physically insignificant so they are not processed by the physics engine.

I believe that this would be a very nice feature, and would definitely give the new control centre that is currently in the design phase a must have use. As such a system would be limited by the current user interface, or the very least become extremely messy and complicated to the point of frustration for the player. Sounds like a plan

It should stay the way you left it, but I'll look into it to see if it's a bug.

Version 1.0.9.3 is now available! Get it here! Fixes a few issues that were in 1.0.9.2 and adds/changes a couple things. Added: Title of the build engineer in compact mode now shows if you are using atmospheric data. Added: New readout to the surface category: - Vertical Acceleration - Horizontal Acceleration Changed: Atmospheric efficiency readout now shows as a percentage. Changed: Atmospheric settings (pressure/velocity) in the editor condensed onto a single line. Fixed: Bug where the overlays in the editor would stay open outside of parts screen.

I would still use 1.1.4.2 in KSP v0.24.2. The fixes in 1.1.4.3 are minor. Also don't worry about there being a nag screen, as KSP-AVC will notice that you're running 0.24.2 and the latest version is for 0.25; so will not recommend the update. I'm not sure of what game elements you're referring to considering there's nothing in the top left of the menu screen, and it's disabled as soon as you enter the space centre. But I have been thinking of ways to make it less obtrusive and fit in better aesthetically. So expect something better in a future update

There's always a chance, but is there a reason? Right now there's no reason to increase my workload by uploading to multiple places without there being any benefits for me or players. I've no need for any of the analytics on KerbalStuff, and CurseForge works perfectly fine for me as a place for hosting downloads. CurseForge is a premium service, ad free, and full speed for everyone; unlike standard Curse. If this wasn't the case, or ever changes, then I will stop using it. Until then, I don't see how the overhead of me having to upload and manage multiple distribution platforms makes clicking the download button in the top right corner of the CurseForge page easier. KSP-AVC/MiniAVC notifies of updates, and it directly links to the page where they can be downloaded for all of my mods; so it's never more than two clicks from downloaded. Nothing against KerbalStuff or for CurseForge. But my process of distribution right now is pretty smooth so it'll take a real reason for me to alter it. Never say never though

Versions 1.0.9.2 is available! Get it here! Updated for KSP v0.25.0 Changed: Prettyfied Latitude and Longitude readouts. Changed: ModuleLandingGear now uses the physical significance flag. Changed: Updated MiniAVC to 1.0.2.4. Known Bugs Overlay vessel and resources displays get in the way of crew and action group screens. Fixed .dll can be got from GitHub/Output if you find it extremely annoying. Version 0.6.2.11 is now available! Get it here! Updated for KSP v0.25.0 Changed: ModuleLandingGear now uses the physical significance flag.

Version 1.1.4.3 is now available! Updated for KSP v0.25.0 Fixed: Typo in AddonInfo.ToString() Fixed: Bug with empty version files which would cause the top drop down to not work. MiniAVC updated to 1.0.2.4! Updated for KSP v0.25.0 Fixed: Typo in AddonInfo.ToString() Fixed: Bug with empty version files.

Hopefully it comes out soon soon as I'm all ready to re-compile and update KSP-AVC, MiniAVC and both Kerbal Engineer Redux v0.6 and v1.0

It shouldn't have been disabled. Try going into the settings and toggling the visibility of the overlay.

Please bare in mind that ksp-avc.cybutek.net is not a database of all mods. It's not meant to be a search tool, just a convenient place for remote version file hosting. A version file can be hosted absolutely anywhere. Edit: Sorry, misunderstood what you meant by database load. Thought you meant it as a continuation of what was previously said, but it was with regards to the loading of the game after re-reading. To answer the statement... There's no way to install or update plugins whilst the game is running. All plugins are loaded into the AppDomain at launch, and because of how the AppDomain works, it is not possible to remove any assembly after it has been loaded. This requires a completely new instance of the AppDomain to be created, which requires a restart of the game anyway.

If a mod's local version file links to ksp-avc.cybutek.net then yes, as it's being used as intended. I just ask that you don't excessively hit the website whilst testing. Use your own local server or similar. Also note that an official out of game tool is not off the cards, as a few people have asked for it. But until then feel free to create your own.

The problem we have been discussing is purely because KSP does not give access to these values. They will have to be calculated from scratch with only the basic orbital parameters and a method for finding a position at a specific time at hand. If it did, the readout could be implemented in a matter of minutes, and it would be a complete non-issue

I've just had a look at HexCans and it looks as if there's a blank .version file bundled with it. This could be the culprit, but I'll need to test to make sure.

The periapsis readout only works for your current orbit, not successive ones. Which is where looking into the future patch conics is required for getting a closest approach for a celestial body. This of course only works when you have an encounter already, so is not a great solution. It could use the same system that a vessel closest approach would require, but I am hesitant to even contemplate this work until I can put a fair amount of time into it. As the process of iterating over an orbit in time fragments could prove very costly with large orbits. Requiring many thousands of iterations every frame if done without optimisations. An optimisation which does come to mind would be segmenting the orbit and working towards ever smaller segments, much like how a binary search algorithm works. This may sound simple to implement, but nothing is as simple as it seems and will more than likely require a fair amount of time to get working and then balance. That is if such an optimisation would even work, as there's a chance that it'll fall flat on its head given highly eccentric orbits.

Closest approach for celestial bodies shouldn't be too hard. That's just a matter of cycling through the available patched conics until it finds an encounter with the same body as the target. You can then just display the periapsis of this conic, which will be the closest approach. As for other vessels, this is a bit trickier as there isn't anything within KSP that gives you this number. So the way of doing this will be to iterate over the orbit in time fragments to get the point at which both vessels are closest.

Possibly... It is something that's been asked for many times. Just that it's not a simple readout to implement, but I'll try to get it in at some point.

It's already implemented as "Longitude of AN" under Orbital, or are you talking about the lack of that readout for targeted vessels in Rendezvous?

This is caused because of the underlying vessel simulation logic required for the readouts used under that section. It runs perfectly fine on most machines but given a large enough vessel or a computer lacking in power, this can slow down. There is a readout under the miscellaneous category for solving just this problem, it allows you to adjust the delay between vessel simulations. Install this readout into any section and adjust it until it doesn't cause lag.

I have to admit that the longitude and latitude readouts really need a bit of work done with them. Right now they're just pumping out whatever KSP is giving it, which as you've probably noticed can sometimes require doing a little mental gymnastics (or calculator usage) to make sane. KER 1.x is in alpha, feature incomplete and this is one of the bits that requires some polish. I'll try to give it a shine in the next update

I've not looked in-depth into what exactly TweakScale was doing to cause the resize. But KER was calling GetModuleCosts() which TweakScale has an implementation of. The implementation of GetModuleCost() in TweakScale calls to initialise its self if it's not already done so for some silly reason. So the TweakScale part initialisation was being done prematurely and using some default scale values such as 1.0 instead of 1.25, instead of what it should be using from the .cfg files. The fix is basically to wait a frame so that any parts that use TweakScale can do their thing first. Not much of a fix because it shouldn't have been a problem to begin with. I have basically hacked around a bug in TweakScale. Which will happen again with any other mods that try to get the costs for TweakScale parts at creation time.