Jump to content

Garek

Members
  • Posts

    257
  • Joined

  • Last visited

Reputation

11 Good

Profile Information

  • About me
    Sr. Spacecraft Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm excited about the new UI and the work that's being put into UX, and I'm interested how that (and the whole game) will develop with community feedback. Also, things like warping through burns and multiple assemblies in the VAB seem to imply a lot better foundations both for the roadmap features and possibly mods.
  2. Awesome! Don't worry, this is "just" a hobby for all of us Yeah, I expected that to be a bit more complicated, thank you for considering it for the future!
  3. So... this is all awesome. But may I ask what happened to the ProbeCore you showed earlier? Still WIP? What would also be awesome would be larger diameter cores (there are some 3.75m capsules in Near Future Spacecraft for example, also think avionics/RCS/Power package for larger boosters) and adapter fairings for the remaining size transitions, but I understand that would be a lot of modelling work away, even if you want to do that
  4. So I'm trying to extend the PartVariant Sytem to IVAs via EXTRA_INFO and my own PartModule. So far I managed to grab that EXTRA_INFO when changing variants in the editor and persisting it to flight. I also manged to get rid of the regular IVA when spawning in flight by doing: part.internalModel.gameObject.DestroyGameObject(); part.internalModel = null; What I'm still stuck on is how to set the new IVA? part.internalModelName seems to be ignored, regardless of when I set it part.AddInternalPart(<ConfigNode>)... even if that were the right option, what kind of ConfigNode would I feed it? how to make that IVA then appear. I tried some combinations of CreateInternalModel, SpawnIVA and internalModel.Initialize, but that didn't seem to do anything. Might be related to 1., but I don't see KSP complaining about not finding the IVA in the log. Anyone got any ideas?
  5. Something I just realised, you can actually do OOP in kerboscript: set foo_a to list(). set foo_index to -1. function foo_new { parameter a. foo_a:add(a). set foo_index to foo_index + 1. return foo_index. } function foo_geta { parameter this. return foo_a[this]. } function foo_seta { parameter this. parameter a. set foo_a[this] to a. } This is a script implementing a class foo which has a single field a and access methods for it. Of course, compared to languages actually designed for OOP it looks horrible, but the semantics are there! EDIT: fixed stuff. Still, this is off the top of my head, without actual testing.
  6. You are wrong there. Yes, CKAN is the most accepted mod managing tool. But not every mod author actually manages the CKAN entry for his/her mod. This leads to CKAN not installing the mod how it's supposed to be installed and messing things up. Which doesn't exactly increase it's popularity with people like Ferram who understandably would prefer other people to not mess up their work and cause unnessecary error reports. Yes, manually managing 50-200 mods is a PITA, but it is the most reliable method of modding KSP, since there actually is no universally accepted mod manager. Also, most of the time, you just need to copy the mod directory to KSP/GameData and maybe delete the old one if you're updating, which is not that hard. I personally have made my GameData a git repository, with a lot of branches and a bit of scripting. I don't recommend this unless you have experience with git and shell scripting, but if you do, it's pretty nice for mod management.
  7. If you stack a lot of structural panels on alternating edges like /\/\/\/\/\/\/\/, they could propably act as a spring. I think I saw this in some ksp video and it worked surprisingly well. Of course, that's a lot of parts per spring, you need TweakScale to get springs with other diameters than 1 and 2 m. Also it won't stop at fully compressed because there is no self-collision, and instead compress further through itself until the connections break.
  8. I also had KSP crash on me, output_log.txt said it crashed while 'compiling' the 1.25m heatshield. But after I removed DRC, it crashed on another Part, somthing from HGR, so I'm still investigating. Oh, with HGR removed and DRC 5.2, it crashes on the .625m heatshield. Hmm. I will continue removing/adding mods until I'm reasonably sure which causes the crashes and post my findings. EDIT: should propably have mentioned, I'm running the windows x64 build with a ton of other mods. EDIT2: It appears to be this: http://forum.kerbalspaceprogram.com/threads/87049-x64-crashing-due-to-access-violation-error
  9. Yesterday I installed KSP again (after a break because of...stuff) and started reinstalling Mods. Then 24.2 hit and broke some stuff _again_. So I went to sleep and when I got up this morning, I had e-mail updates from Kerbal Stuff that FAR had updated and DebRefund is compatible. Thank you so much just for that feature! EDIT: "You must spread some Reputation around before giving it to SirCmpwn again."
  10. If you actually would manage to install all dependencies for your mods, and their dependencies, IN THE CORRECT VERSIONS, IN THE CORRECT FOLDERS, I think you are equally capable to open the downloaded archive, and look at it's content to determine which dependencies are packed in. Also: Module manager can't be overwritten by older versions because the dlls have the version in their filename. If by accident, multiple versions are present, the newest one is used. KSPAPIExtensions has a similar mechanism afaik the whole point of mm cfgs is that one mod may modify another, and there was a lot of work invested to make them as compatible as possible with each other Keep in mind, a Mod is not a regular application. In fact, if it were, it would always bring it's dependencies with it in some form or another. A Mod is a MODIFICATION of the game created by a community member. This always implies: It's a free piece of difficult work. Critisism may be necessary, but don't demand a technicality to be implemented in a certain way just for your convienience It may break things. KSP's API is insufficiently documented, it has bugs, and most Mods have no proper Q&A (again, because they are free). Stacking mods is even more likely to break things. Software even has bugs if all people working on it work within 20m of each other. With multiple mods, you have Squad providing the base and every modder building a bit on top of that - and often, on other mods. If you don't understand what modding actually does to your game, you have equally little right to demand stuff from modders, who offer a piece of hard work for free. And the more you understand, the more reasonable suggestions you are able to make - and you are also more likely to just fix stuff yourself. Also, about bug reports. About every author wants the output_log.txt alongside a bug report, and yet, people have to be always reminded of that. It's not like professional, sold software were there is first level support paid to walk everyone through the basics again. You are talking directly to developers here, and they can fix a bug a lot faster, if you find out as much as possible about it, and provide all the information. I work as a software developer, it was a long day, I'm sorry if this became a bit of a rant.
  11. I wrote two rebutals of this, but they rapidly devolved into rants. Now I will just say that I would like to understand how you got that opinion, if you would care to explain? (As long as this doesn't get us into trouble because it would be too political)
  12. I think this could use some kind of car jack to make the wheel deployment less...wobbly-springy?
  13. I knew that thread, but as I read only the first few posts I thought it was meant for the RftS mission reports, and not RftS mod discussion. All the info I wanted and even more For future reference (and new guys) it would maybe be helpful to add this link, and the one for the real engines stats, to the OP. That's exactly my point, so I will use RftS in the future. Interesting concept, I might implement that with some scripting. (No, not kOS, at least not until it gets proper functions. Maybe kRPC or something like that.) Good to know. Thank you both for your helpful replies!
  14. I'm reposting this since it apparently got buried in people arguing over MechJeb data (I'm sorry if this isn't okay): So with Real Engines, the LMDE is the only engine good for landers bigger than probes, and if one wants to have a greater variety of lander engines, RftS is recommended? e.g. for bigger stuff/higher gravity, atmospheric landings, ... (is Mars atmosphere relevant for ISP?). Or would that be the point where it's recommended to do a little research and 'build' (-> create .cfg) appropriate engines myself? By the way, is there a engine list for RftS similar to the one for RE you posted there? That would be helpful for deciding which pack to use.
×
×
  • Create New...