katateochi

Members
  • Content Count

    3,214
  • Joined

  • Last visited

Community Reputation

3,469 Excellent

About katateochi

  • Rank
    KerbalX.com dev

Contact Methods

  • Website URL Array

Profile Information

  • Location Array
  • Interests Array

Recent Profile Visitors

14,662 profile views
  1. The reason that I once added Xenon to the ISRU's cfg wasn't because I wanted to power ion engines, it was because (somewhat Cowboy Bebop inspired) I wanted to setup a space trucking program. I wanted to have a reusable process for mining something out there [gestures vaguely] and bringing it back to Kerbin and recovering it back at KSC...for profit. I wanted a system of reusable canisters that could be hitched up in a train and hauled by a rig (designed around the ones from that ep in Cowboy Bebop), taking the empty canisters out to be filled and bringing them back. Doing it with fuel just wasn't worth it from a returns point of view, mono-prop being the most valuable per ton, but that needed huge containers. Xenon was far more valuable per ton and more dense, so it fitted the idea better. Ideally what I want is some sort of precious metal/gem resource that could be mined on certain planets and brought back to Kerbin, to give some reason for having craft capable of hauling cargo back to Kerbin rather than always away from it.
  2. If you ever see errors that reference "CloudFlare" then that means that for some reason (there's a few things that cause this) you're not able to reach the KerbalX server. Usually it means the KX server has crashed, in which case it will bring itself back up in a few minutes. Sometimes it can mean an issue with the CloudFlare network in your geographical area (and that's out of my control, only thing to do is wait, but usually not too long). All looks ok now!
  3. The first error might suggest that it's something to do with my attempts at making it so you can drag the main craft list up and down with the mouse, as well as regular scrolling. And that other error, is typical of having an open group without a close. But the way I built it should mean that it's not possible to not have a close....so maybe it somehow exists that block before closing...? At least the mouse drag error gives me some idea where to look. But I've not been able to repeat this error on my end so tricky to debug. What happens in game as a consequence of the error, does the Craft Manager UI stop working when that happens?
  4. I've submitted a pull request to update the CKAN info, but the good fellas at CKAN have to review all pull requests before they get merged and then the CKAN bot has to do it's thing. So give it a day or so and then it should show up (assuming I didn't bork my pull request!).
  5. New release is out (1.2.0) for KSP 1.8.x Recompile and fixes issues with some textures not appearing correctly, and a couple other minor fixes Don't forget, you need to update the KXAPI dependency too. Use KXAPI 1.2.0 for KSP 1.8.x Links to both on KerbalX
  6. The current version, while it does (mostly) work in 1.8, will have some issues. I'm currently working on (almost ready) a recompile for 1.8.x with a few fixes for 1.8 specific issues. Should have that release out in the next day or two. Hopefully that will take care of that issue.
  7. Given this: I'd definitely say it's worse! isn't KSP 2 supposed to be an almost from the ground up rebuild?
  8. while light from engines would be natural, I think it's lack just provides for another thing to design around. Either simply just put some spot lights on the underside, or have "depth probes" which you drop as you descend and watch for when they hit the ground (and/or put lamps on them too). It also kinda makes for a requirement to send small (easy to land) probes to a location before attempting to bring your larger craft. That way you'll have something to aim for. Oh and in recent KSP, you can switch the altimeter to terrain mode and go hardcore and land just by your instruments. no, very few mods (if any) would require starting a new save.
  9. I feel this thread isn't long for this world, but before it gets locked.... From a developer point of view, analytics are really important. Users are almost completely useless at submitting meaningful bug reports and far far worse at reporting about things that they don't even see (obviously!). Analytics are essential for understanding how your software performs under real world usage. Just submitting crash reports when it completely fails is far from adequate (that's like waiting for a postmortem result before deciding on treatment). Most (half competently built) software shouldn't crash over minor issues, it should error handle and carry on, but the user doesn't know that's happened so they can't report it. But that info can provide devs with an insight into where design flaws are or where the system fails to scale. Knowing how fast users move through a particular part of the interface can help identify unknown bottle necks and shows you how your users actually use the program (which honestly is something that never fails to surprise me), which leads you to know what areas to enhance. That's info that no amount of QA/testing can ever reveal. I feel that by saying "No" to all analytics starves the developers of useful info and disconnects them from their project once it's out in the world. In the end blocking all analytics doesn't benefit the community. We want a well optimised program, well, then we need to allow the developers to collect data. However, the behaviour of companies in recent years has resulted in a loss of trust, which is understandable. So do we actually know what data KSP is reporting? I've been trying to look into what files get touched as a result of running KSP. This is on Linux, so.....it's not windows, it'll be different there (someone else can run traces in windows). I used strace like this to see what files are hit strace -f -t -e trace=%file -o ksp.trace ./KSP.x86_64 That returns a lot of info, so to condense it I stripped out all other data apart from file paths and removed duplicate references. What I was really interested to see was which files where touched in my home directory (excluding those that are inside the KSP directory). here's what I saw: Nothing there causes me concern. It's certainly not rampaging around in my home folder trying to "gathering everything [it] can". What about outside of the home folder? Well, that's a much longer list (few thousand lines, so not going to post that here) and I gotta admit I'm somewhat out of my depth in understanding what all of it is. But over half of the files touched where all within /usr/share/fonts (it touches everything in there, somewhat wft) and the majority of the rest of the activity was in /sys/devices/ and /usr/lib. well, it's gotta find out how to talk to your computer! The only place where it does seem to be a bit overzealous is in the /tmp folder, but for all that I know, it's simply listing the files in there. Again, I don't see anything that causes me alarm. Now that's just files that are touched. NOT what's being reported. That I don't know, will need to find a way to inspect traffic and I'm not familiar with how to do that. But from what I can see, it's not doing anything unruly like rummaging around in places it has no business being in. A couple points raised earlier about consuming bandwidth. Now I've got a terrible internet connection (I'd bet it's one of the worst in this community; 6mb down, 0.2 up, if I'm lucky). But worrying about bandwidth consumed by analytics, just seems a little over the top. It'll be kbs of data being transmitted, we're talking 10-20ms to make the request. Is that really worth the effort in locking it down? Honestly, there's probably a greater penalty in game as it waits for a response that never returns and has to timeout. The other point about 'the opt out should be client side'. consider this; You start playing KSP, all enthusiastic and you just click through the initial dialogs, 'yeah whatever, lemme at them boosters'. But sometime later you come across this thread and think hmm, maybe I'll disable analytics. Now if that's done client side, at best you have to trust that as you hit disable, the last thing it does is send a request to the server saying please delete everything for this unique id, or at worst you are now completely cut off from whatever data has already been collected and now have no reference to ever request it's deletion. Which ever way it's done, you still have to trust that at the server side your request to be forgotten is honoured. I 'm not sure about this, but being done server side should mean that once set, all your KSP instances follow that rule, at least on that machine. Done client side, you'd need to remember to set that option in every KSP install you have. Have a look at the docs for Unity Analytics -https://docs.unity3d.com/Manual/UnityAnalytics.html specifically https://docs.unity3d.com/Manual/UnityAnalyticsEvents.html The 'core' and 'standard' events are exactly the kind of thing that are of great value to developers looking to understand how their users use the software. They don't include anything unpleasant and it's not marketing data. KSP's developers can define 'custom' and 'transaction' events; we can't know what those are....however looking at the docs for them, I'd be surprised if KSP makes any use of transaction events (as there are no monetary transactions/ads in game) and there is probably little use for custom events (*speculation). https://docs.unity3d.com/Manual/UnityAnalyticsUserAttributes.html Overall, I'm happy with what I've found. And because I feel that providing info to the developers is important, I'll be leaving analytics switched on.
  10. curse my dyslexia! nope not noted before! I'll change that in the next release. note: When that release comes out, and you update CM, it won't fix it in existing saves (as it becomes a setting in your save folder). But (and you can do this right away), you can right click on that tag and rename it. For now you can rename that tag in your existing saves (either via the UI or edit the craft.tags file in your save folder). You can also go into the CraftManager folder in GameData and edit default.tags file and change it in there too, then any new saves won't inherit the misspelled tag.
  11. Are you using ContractPacks? I've seen markers like that around vessels that are involved in a ContractPack contract before (specifically Tourism Plus).
  12. yeah, finding my spaceplanes are failing to reenter now. LKO reentries are ok, but a return from Mun and even just skimming the atmo (approach Pe at 60km) and wings are burning up....oddly it seems to always the starboard wings, even if I hit the atmo perfectly level.
  13. The current version of Craft Manager seems to be functionally OK in KSP 1.8.0, but there are some issues with missing textures on menus and lists. So you can use Craft Manager (and the dependency KXAPI) in 1.8.0, but menus are transparent. I will get working on a fix for that soon. Sorry to those who've asked Qs and reported issues. I've been out of action this last month and before that work was killing me, so I'm quite behind with KSP things! I'll try to catch up!
  14. Somewhat surprisingly, the current version (1.1.0) works in KSP 1.8.0. (Craft Manager is also working but has some missing textures on menus/lists, will fix and update soon)