cybutek

A mod author has the right to use whatever license he/she wants. But the choice is not always black and white or straight forward. The author may use a restrictive license as a means to tightly manage the progress and direction a mod takes, and to have better control over what is actually floating around in the ether. This of course comes with some downsides, such as being constantly committed to the project and carefully trawling through user feedback. If the author is not vigilent, the community won't get what they want and will just leave it. More than likely coming along and creating something that does it better as an open collaborative effort. On the other hand, open licenses can have problems such as the possibility of many forks floating around, merge issues and just a big mess all over the place. But this allows the community to make a mod into what it wants, rather than what the author invisioned it to be. The probability of long term success of a mod is greatly increased with an open license in my opinion. I always use open licenses of some form or another, not only because a bus may run me over one day. But because there's been a few times where something in my code has been overlooked or done in a rush. Instead of it staying how it was, there's been awesome members of the community that have taken it upon themselves to make it better. I can then merge their changes and it's all hunky-dory for the next release. It should also be mentioned that what is stated in the license isn't the be-all and end-all. Even if a mod has a restricted license, it doesn't neccisserily mean that you cannot do anything with it. It just means that you require permission first. The author can give permission to anyone to do anything with their mod no matter what the license states, it is their property after all.

Version 1.1.4.2 is now available! Changed: Done a lot of under the hood refactoring. Fixed: Bug that would freeze the computer when checking many add-ons. Fixed: Bug that caused the compatibility display to show as a long thin window. MiniAVC has also been updated to 1.0.2.3: Changed: Done a lot of under the hood refactoring. Fixed: Bug that would freeze the computer when checking many add-ons.

The URL field in the local version file has to point exactly at its remote equivilant, yes. It doesn't use magic to find where it's located

I'm happy for anyone who uses MiniAVC to just add a bit of a blurb in their own readme file stating that it's GPLv3 with a link to the full license. If your mod already uses GPLv3 or an equivilant copy-left then all the simpler. But all licenses have the same problems in this case. Even the super left MIT license says that it must be included. Oh and I include my readme and license files outside of the folder that is to be copied over into the GameData directory. They are more visible when you open up the zip this way, but believe it or not it's not mandatory that you have to extract a whole zip file. You can just drag out the folder leaving the documentation where it is

I've merged your pull request. @Cyrik When you have a GitHub repository specified in the version file, it will only show that there is an update if there is a release with the same version available. The version file clearly states 0.2.2 but there is no 0.2.2 release on GitHub, only 0.2.1. The GitHub part of the version file is there for synchronisation purposes. So players don't get premature update notifications when you commit a new version file, and have not yet packaged a release.

No... MiniAVC only has the basic update checker. It was never meant to be feature rich, otherwise it'll get really bloated and hard to maintain. For the extra functionality the full plugin will be required. The bundled version is supposed to be used as a safety net, not a replacement.

Looks like it'll be popping up with a few updates the next time players start their game

Version 1.1.4.1 is now available! 1.1.4.1 Fixed: Log spam. Fixed: Checking window staying open after displaying the first run / updated window. 1.1.4.0 Added: Drop down action menu support allowing for multiple actions per add-on. Added: Change log support, allowing the player to view the add-on's change log. Added: Drop down list showing all KSP-AVC ready add-ons on loading and main menu. Changed: Versions will always have the minimum formatting of 'x.x'. Fixed: Issue with non-RAW GitHub version file hosting, extending the url formatter. Fixed: Bug where it would do a re-check when reloading the database. MiniAVC updated to 1.0.2.2 Changed: Versions will always have the minimum formatting of 'x.x'. Fixed: Issue with non-RAW GitHub version file hosting, extending the url formatter. Updated KSP-AVC Online Versions now have a field for the URL to your change log file. This file should be a plain text file as it is displayed within the game without formatting. Note that if you are creating your version files manually, it is possible to embed a change log into it using the 'CHANGE_LOG' field as an alternative to using the 'CHANGE_LOG_URL' field to fetch it from the internet. Change log information is only gathered using the details contained within the remote version file, not the local one.

I'm actually working on KSP-AVC right now implementing some more stuff. I've found the bug which is causing you problems and it'll be fixed shortly

That feature is already implemented for the GUI, just not turned on yet due to it not being a part of the simulation code. Considering that the simulation code is now going to be maintained on 1.0 and not 0.6, expect it to be implemented very soon Absolutely no difference apart from the awesome looks There's nothing stopping you from changing the cost in the part's config files.

I can definitely see about trying to sort out a readout which shows this

Thanks for the report, I'll take a look into what's actually causing this bug in a bit. Seems odd that the Distance is also 0, it is probably related and hopefully an easy fix.

That problem is something that I have been pondering over for a while, but just not got around to doing anything about it. Resizing the windows is a no-go as it would just cascade down a whole new set of bigger problems, so that's out of the question, at least for now. The easiest solution would be to just have the burn time always show on a new line. Also because of how the readouts work, it could possibly be fixed by just making the space flexible. This'll be a little bit trial and error with finding the best solution that's aesthetically pleasing and functional. If anyone has some suggestions feel free to chuck them in the pot, as I'll more than likely fix this in the next update That probably is because it is unpolished KER 1.0 is a public test after all... Not representative of the final product Anyone who opts to download and use KER 1.0 should be buckled in to experience the development process, where updates are regular and new features are being constantly added. It also helps to have feedback such as above, as it lets me know what people are noticing and where the priorities should be.

It's just a shame that kids being the innocent party are at the mercy of their parents stupidity... Considering the science, evidence of benefits and absence when it comes to scare stories, a childs life should be more important than a social meme or religious freedom.

With KER 1.0, it is always active and part-less in the VAB/SPH. It can be toggled on/off using the toolbar button. It did not make sense to have this moduled because it just forces the player to attach and detach a parts without any change in gameplay, only tedium. The setting for part-less and module mode is for the Flight Engineer only. Having the Flight Engineer in module mode adds a difficulty setting, as it costs money to place the parts and it's not just blanket on, and thought about placement is required. It is an option, and an option that I'm sure most people will never use, but it's there for anyone who wants a use for the awesome ER7500 model

Version 1.0.6 is now available! Added: Time and Angle to equatorial ascending/descending nodes in the orbital display. Added: Time and Angle to relative ascending/descending nodes in the rendezvous display. Added: Overlay tooltip information delay adjustment slider to the Build Engineer settings. Added: Ability to rename the stock displays in the Flight Engineer. Changed: Build Engineer is now hidden when not in parts view. Changed: Custom display panels will only show in the control bar if an abbreviation is set. Changed: Licensing and readme structures are now more verbose to satisfy the new add-on rules. Fixed: Updated MiniAVC to v1.0.2.1 (fixes remote check bug as well as other minor bugs). Version 0.6.2.10 is now available! Added: More verbose licensing to stay within the updated add-on rules. Changed: Separated out the changes from the readme file allowing for future KSP-AVC changelog support. Padishar's Fixes: Various bugs in the simulation logic.

5thHorseman is correct in regards that terminal velocity is kind of a pointless readout with FAR/NEAR. It goes up so quick that you reach maxQ and the vessel starts to dismantle its self, or becomes completely uncontrollable well before reaching it. If you do manage to launch and maintain terminal velocity with an intact vessel, it will be experiencing atmospheric shock waves and re-entry heating effects practically all the way up. As a side note, I am planning on creating readouts for practically all the FAR data which it provides through its API. NEAR on the other hand does not have an API to hook into, so it's not possible to retrieve pre-calculated data. The time and effort required to create readouts for use with NEAR is just not worth it, and the time could be better spent on other things. When I start working on the FAR stuff, I may ask Ferram if he can create an API for NEAR, but don't hold your breath. NEAR after all is a cut down version of FAR. So I wouldn't blame him for recommending people use FAR if they require the extra data.

The differences are: 1.0 does not include the EngineerChipFlight part, only ER7500 and EngineerChip which are also only required when not running part-less. 1.0 does not use the BuildEngineer part module as it's always part-less. The FlightEngineer module is now called FlightEngineerModule. If your crafts contain parts from 0.6 and do not find them, or the associated part modules, KSP may delete them. The save file tweaking should just be a simple find/replace in notepad changing EngineerChipFlight to EngineerChip, removing 'name = BuildEngineer' and changing 'name = FlightEngineer' to 'name = FlightEngineerModule'. I have not tested this out though, so cannot guarantee any form of success, only that it's technically possible to tweak the save file so it could be compatible. Remember that backing up your save file is always recommended before trying anything like this this out though. Has someone has actually tried making a 0.6 save compatible with 1.0? And can either confirm my tweak, or say it's a load of codswallop and recommend a better way?

Interesting, nothing that should hinder players, but I'll look into it.

Version 1.1.3.1 is now available! Fixed: Game breaking bug. And that's no exaduration considering the bit of code that was accidentally left in basically unloaded every single plugin and assembly from the game on startup. As I was seeing the feasibility of a one button update/install and if it would be possible without having to restart. All fixed now, and MiniAVC wasn't affected. Sorry

I'm trying to sort out a fix now... It's quite an odd thing because it's not actually giving any errors, just soft locking. *facepalm* like serious *FACEPALM*. Accidentally left in some experimenting code.

Version 1.1.3 is now available! Added: GitHub latest release checking. Added: Version file reading is now case insensitive. Fixed: Bug in version equality checking. (Now using a custom VersionInfo object). KSP-AVC now supports GitHub release checking. By having the remote version file contain GitHub information, the version checker can do a release check to see if the latest release is the same version as the version file. If there is a release to check with, and it's not the same version as it states in the version file, no update notice will be displayed to players. The check is done against the tag given to releases and does a regex removal of all characters other than numbers and points, so please bare in mind that "v1.0.0" and "v1.0.0-alpha" will both come back as "1.0.0", and "v1.0.0-alpha1" will be "1.0.1". Also if no download location is actually specified in the version file but an update is available and there is a GitHub release associated with it, the download location will link to the page for the player to download that release. MiniAVC has also been updated to 1.0.2.0 with the same functionality.

I did take a look into the GitHub API, but my focus for the last few days has been with Kerbal Engineer. The cycle will alternate back to KSP-AVC very soon (the next start of Visual Studio)

Ok... That bug is now fixed in MiniAVC 1.0.1.1. Give it a whirl and if there's any more problems, you know where to shout

Looks like a simple check was missed out. Good spot!