cybutek
-
Posts
390 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by cybutek
-
-
So I wondered : there is a change on the approach of KER with the v1, or am I experiencing a bug ? I worked a long time with KER when I started KSP to understand all the angles, but with the v1 I'm totally lost. Can someone explain me ? ^^
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
-
Feeling weird about the mechaism of the .version file.
I made a plugin for 0.24.2 and now 0.25 is out, I tested the plugin and it's compatible to 0.25 so I don't need to make a new plugin version. What should I do then?
I went to the KSP AVC website and "Edit" the "KSP Version" entry to "0.25.0" but I still get the update warning when launching the game saying that the plugin is made for 0.24.2.
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.
-
Just curious why they have a weight and cost now. I was away from the game for a bit, so I'm not sure when those were added...
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.
-
This was a big advantage of the part-based system as the window state could be saved in the part so it could be remembered per-vessel rather than as a global setting. Perhaps it could use a scenario module that maintains a list of per-vessel settings. It could even let you save multiple window layouts so you could easily switch a particular vessel between different settings, e.g. you may want a completely different window layout during launch of a rocket, during transfers and during landing. Then a global option for the settings of newly launched vessels (possibly different for VAB and SPH) would allow you to choose the window layout and whether the windows are shown...
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
-
I haven't used the latest version so I don't know if this is changed, but is there a way to make the flight-scene engineer window not open by default? I always have to close it when I don't plan to use it, which is more often than not at launch.
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!
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.
-
Do you think these still work with KSP v0.24.2? Understandable if you haven't tested that.
I'm not moving to 0.25 until most of the important mods (including BTSM) have all successfully upgraded.
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 always have the dropdown menu with "Show All KSP-AVC Ready Add-Ons" on the top right. Is there a way to disable this dropdown once the game itself is started? The dropdown is not movable as well, so it hides important game elements too.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
-
Is there any chance of getting this hosted on KerbalStuff?
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!
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!
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
-
Sorry if I did not see a response, but why was the Vessel bottom Pop-up removed (from the VAB or SPH) from 1.0.9.1 ?
I saw it in 1.0.9.0, but no longer after upgrade.
I will try again with 1.0.9.0 just to confirm it is not some other mod that disabled it
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 there is no such tool, I was considering making it myself. If so, am I allowed to query ksp-avc.cybutek.net for the versions?
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.
-
:/ does ksp give you access to values for the current intersect time(s)/distance(s)? Even just displaying that would be helpful, even in map view (LOL). Would there be a way to estimate how this distance would change based on this distance and the different orbit times/circumference?
Just throwing ideas out, because if it is really damn complex or resource intensive it's probably not worth it
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.
-
Isn't it only when I already have encounter set up? And wouldn't then my periapsis read actually switch to it?
Not like I insist on such feature but I think it would be more relevant to have it when you are trying to get an encounter and not have to mouse over checking if you are getting closer
Or you did mean something else and you could do it that way.
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.
-
Tried searching around, even in the changes file on github, and was just wondering if there will ever be a closest approach distance and time listing in the rendezvous section?
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.
-
Any chance you'll add a "Longitude of the ascending node" readout?
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?
-
I noticed that when one window is open with the Kerbal engineer redux 1.0.9, the game is awfully lagging....As soon as I close the window it runs normal speed.
It's the vessel window that slow up very much the game...
Any feed back about that?
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
-
Woo, thanks! I wonder why it changed the size of the part though, all it appeared to be doing is fetching the resource amounts and their cost
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.
[1.3.0] Kerbal Engineer Redux 1.1.3.0 (2017-05-28)
in KSP1 Mod Releases
Posted
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