Jump to content

cybutek

Members
  • Posts

    390
  • Joined

  • Last visited

Posts posted by cybutek

  1. One suggestion and one question:

    Suggestion: could you please make it so that the log messages say which file is being parsed? It's hard to find problems (or even to know if they're in your file or somebody else's) otherwise.

    Thanks for pointing out that problem with the log messages. They were not showing up due to the way threading works. I've sorted out that problem and have made them fairly verbose to help with any .version file debugging.

    Question: how do you indicate that a mod is compatible with, say, both KSP 0.23.0 and KSP 0.23.5?

    I'm working on that by allowing KSP_VERSION_MIN and KSP_VERSION_MAX fields. The plugin works on the assuption that all KSP_VERSION fields are optional, so just leaving them out completely will default it to assume the add-on will work with everything.

    I'll aim to get an update out later today with these changes :)

    depends (modX use plug-in from modY, if modY if upgraded, warning may be displayed)

    Including dependancies would be an extremely nice feature, but this area will have to be thought out carefully.

  2. KSP-AVC Plugin 1.1.6.2

    KSP Add-on Version Checker

    This system is a spawn from Tyrope's endevours on this thread.

    After seeing the moderate take-up of a .version file format and the subsequent enthusiasm fall off. My thoughts were that a true .version system had to be created for it to even have a chance to sticking around. Not just for plugin developers and users which could type up a JSON file by hand in seconds, but also the artists and parts creators as well. It is all well and good to have external applications which manage your mods, but there has to be a more integrated solution for wide spread use. This is where my KSP-AVC plugin comes in, as it does all of the .version file checks from within the game. If any issues are found, they will be displayed to the player in a convenient way. An extention of the .version file has also been made to include an optional download field for use with this plugin.

    NOTE: Version 1.1.5 works in all 1.0 versions of KSP. Use 1.1.6 for KSP 1.1 and later.

    FOR DEVELOPERS...

    Have a question or require some help? Leave a message in this thread or PM me.

    If you wish your add-on to have KSP-AVC support even if the player does not have the KSP-AVC Plugin installed, you may use MiniAVC. Just bundle the .dll in with your mod and version files. Because of the bundled nature, the player will be given the option to allow update checking on the first run. If the player does disable update checking, it will continue to run in local mode assessing game version compatibility. MiniAVC will always run from the most up-to-date version which has been bundled with any of the installed add-ons. If a player has KSP-AVC Plugin installed, MiniAVC will automatically be disabled to allow the KSP-AVC Plugin to run.

    For more information read the online readme file.

    Get MiniAVC Here!

    Please not that if hosting a version file yourself, it must be encoded in UTF-8 without a Byte-Order Mark.

    The source code and project is part of the same repository on GitHub as KSP-AVC Plugin.

    Licensed under GNU General Public License v3

    Additionally

    This software searches through only the KSP GameData directory and subfolders.

    This software contacts the internet to check if add-ons have newer versions available. Data is only read from the internet and no personal information is sent.

    This software has the ability to open up a browser window to what is set in the DOWNLOAD field of the remote version file.

    All remote destinations set in version files are up to the respective add-on developers and I hold no responsibility for how these features are used.

     


    KSP-AVC Online

    Easy Versioning for Everyone!

    As I see it, the way to get proper versioning to go mainstream has to be that it is easy. This means super easy for everyone no matter what their skills are. It shouldn't matter if you're a programmer, artist, content creator, parts developer. You have the right to version your add-on in a simple and convenient way. With complete compatibility with the KSP-AVC plugin as well as any other 3rd party software which conforms to the .version file standard.

    ksp-avc.cybutek.net

     


     

     

    DONATIONS

    Completely voluntary, absolutely amazing, and really does help me out a lot!

    btn_donate_LG.gif

     

  3. There's a 1.0?! Is that going to be based off the new dev code in the other thread?

    KER 1.0 currently has nothing to do with what's in the other thread, as that thread is just a modification of the 0.6 code. The other thread is a place where Padishar's helping out with an altered simulation logic system based on 0.6. Although his work is being done on the 0.6 base, we have discussed the situation on making sure the simulation is modular and can be bolted directly into 1.0. Version 1.0 has been in development for a while now and is a complete re-write of Engineer from the ground up, and apart from a couple cosmetic similarities, it's completely different. As of yet, I have just been unwilling to do a release because there is no updated simulation logic due to time constraints on my part.

  4. May I suggest a change the accuracy of the display value of the orbital period?

    I've been messing around with rss and rt2 and when the orbit period is longer then a day

    KER is only showing days as a decimal which is ok i guess but rounded to 3 significant figures, that's an error bar of about +/- 40 sec.

    This might not be a problem when playing with the stock planets but with the larger planets and speeds with RSS it's very noticeable.

    In the worst case scenario this inaccuracy could result in a orbital migration between 2 satellites of half an orbit in 554 days in my case.

    So whenever I want a higher orbit accuracy than that I have to do the calculations myself.

    5 significant figures would give an accuracy of slightly less than a second.

    Or better yet, make it display the orbital period like the other time values showing dd:hh:mm:ss could this be possible?

    How you describe what you want is fully implemented, but is formatted in its current way purely because of space and layout concerns (governed by how 0.6 does its layout). Using the 00:00:00:00 notation causes layout problems solvable only through clipping (chopping it down so you don't get all the information anyway) or having it span multiple lines (causes readout labels to be out of alignment with their values). All sorted in KER 1.0 though. It's pretty safe to assume that all problems relating to formatting or layout are fixed or can be extremely easily fixed in 1.0 due to it's much more robust and modular design. Right now I am just waiting on feedback from Padishar's alterations of the fuel simulation and it's stability. It will then be pulled directly into 0.6 and transferred into 1.0 for a release.

  5. Loving the work Padishar, just did a test of it and it looks very promising. I did notice that it doesn't like fuel lines yet or was not staging correctly, not sure if I was getting an old version or not etc. Just got the one on GitHub... Oh and by the way, feel free to change the whole simulation if you find that easier.

    All that is required:

    A way for every readout to request the simulation to run.

    A way for every readout to get a list of stages containing data like the current one.

    A simulation has to be told to run and will only run if it has been requested.

    A simulation will only run after a certain amount of time based on ship complexity so it doesn't drop fps with big ships.

    Might be worth taking a look at https://github.com/CYBUTEK/KerbalEngineer which is KER 1.0. Because as soon as you've done your bit, I'll be trying to shimmy it into that as soon as possible. As that is my ultimate goal, 0.6 is horrible under the hood and seriously hard to maintain with each KSP update. :P

  6. Don't criticise the code too much (even though it is pretty bad), it's been through a number of major KSP updates that have completely trashed the whole thing. The basis of KER is still on old code that was put down back in 0.16 when it was a small mod for myself and released just for the hell of it. The only real solution for KER is a complete redo in my opinion, and that's where 1.0 comes in. The only things left to redo in 1.0 is the simulation code and the rendezvous readout modules. The simulation code is the biggest part to redo, a part which cannot be easily done with little chunks as and when time allows. I am eagerly awaiting the fruits of Padishar's efforts, of which will be implemented ASAP into 0.6 when all the issues have been ironed out. Shortly followed by an official release of 1.0.

  7. Just so everyone knows... I know all about the locking issue, it is because KSP changed the way in which the GUI in the editor is locked with the last update. KER 0.6 has a quick bodge which got the old code working with the new system (works, but can break if not handled properly) while KER 1.0 uses the updated fix. I've been pretty busy with real life, hence the lack of updates. But when I get a bit of free time, some of the smaller bugs like this one will get sorted in a quick hotfix. :)

  8. Version 0.6.2.3 is now available!

    Updated to work with mods using ModuleEnginesFX that are not using MultiModeEngine. (Thanks for the heads up Hyomoto). I've also disabled the remote version checking because it's not been used in a while, and is a bit of a hang over from an older system.

    I see that people are still having problems with KER freezing... I've tried to reproduce it but without much luck, and thus cannot fix it. Building a rocket, flying it around and then reverting to the VAB just doesn't cause any problems for me. Sorry :(

  9. I started a new sandbox game, started with a mk1 pod, slapped Engineer7500 on it and started building; adding parts (stock only, though I do have mods installed; looking at the craft file, at least KAS adds some modules), altering staging, switching reference bodies, mostly between Kerbin, Mun and atmosphere/no. 10 minutes later, KER froze. Craft file.

    I have a thought. If you build a rocket large enough (not really large at all by my standards, see craft file above) with one reference body, then switch to another reference body, KER will hiccup for maybe half a second calculating the values. If at this point in time, before KER shows the updated new values for the switched reference body, you switch reference body again, it freezes. I think that's what caused it on this test at least.

    There may be a separate bug that has the same effect, though, since I've had this freeze while adding parts as well. (though you may have fixed that one, don't know)

    I've been messing around with your craft for a good while now, attaching things, removing things, switching the reference body all over the place over and over again as fast as possible. I've even been messing with the staging and tweakables as fast as possible to try and cause this bug. Changing reference body whilst it's still calculating etc. Suffice to say, I cannot reproduce it. Without being able to reproduce this bug, there's no way for me to know where it is. Sorry. Can't fix something which I can't break :(

  10. Personally I don't see the need to have KER be a PartModule at all.

    It's a PartModule because that's what had to be used back in the day, as there was no way of making anything part less without using hacks. KER started its life before even PartModules were implemented! I must strongly state again, such feature changes which are already in 1.0 and require more effort than just copy/paste a bit of code wont be coming to 0.6. It's the matter of, do you want 0.6 for longer or 1.0 earlier?

    Being partless aside, I have another request - a migration of the UI to the 'smoke' UI style that Mechjeb and such uses. In particular, a highly-compact mode.

    The current UI is extremely large and takes a ton of screen real estate. I personally use the compact Mechjeb UI, but even just going to the transparent smoke style would be great since that style alone saves a considerable amount of screen space. Whenever I'm building rockets I'm constantly having to move the engineer window around, whereas the Mechjeb vessel info is extremely compact and easy to work around.

    Already in 1.0 apart from the "smoke" style UI because that's Unity default and isn't stock. It actually requires more effort to make it look stock. That "smoke" style is in fact the lack of any styling at all.

×
×
  • Create New...