Jump to content

iamaphazael

Members
  • Posts

    270
  • Joined

  • Last visited

Posts posted by iamaphazael

  1. I posted this on askreddit today, but it got buried quickly. I figured I'd see what you folks thought:

    Despite the fact that we've switched (at least in academia) from the BC/AD designation to the BCE/CE designation in an attempt to make it seem like our calendar is not based on a mythological event, the fact remains that the calendar in use for most of the Western world is based around the central premise of a religion that not all of us subscribe to.

    Ideally, our calendar would be centered around something that was more universal, or at least something less divisive. However, it would probably be too much effort/confusion/resistance for something with limited tangible benefit.

    If we were to re-center the calendar, what would a good start date be? I'm a computer science guy, so my choice would be the "Unix epoch": Jan 1, 1970. It is pretty much the standard as far as timekeeping in computing goes (ie, the date in your computer is stored internally as the number of seconds since then), so there's a practical reason for adopting it.

    Additionally, it roughly marks the beginning of the Space Age, which looking ahead to the distant future seems like a good point to measure from. So, Yuri Gagarin's first spaceflight would have happened in year -9, and Apollo 11 in year -1.

  2. I'd make one suggestion regarding the Apollo parts. I would incorporate the docking rings into the command pods rather than having them be separate parts. When you have the LM mated to a CSM, it's hard to find a spot to mouse over the docking ring part to undock. (Yes, I know they can be action grouped, but we all forget sometimes). It seems to me that there's no benefit to having them as distinct parts

  3. Using an SRB would be a bad choice. Consider that once it's lit, it will burn all of its fuel until there's none left, generating thrust the whole time. As the speeds and conditions (eg the weight of occupants/cargo in the car at the time) of emergency situations are highly variable, an SRB charge might either not provide enough impulse, or provide too much and cause the car to end up moving in reverse, which could be bad. If you want a rocket-propelled safety device, a throttleable liquid fuel setup is the way to go.

  4. Bear in mind that "what not to suggest" is not the same as "never going to happen". There are a lot of ideas out there that are really good ideas, and the devs know they are really good ideas, and are probably already thinking about how to make happen, that keep getting suggested over and over again. In fact, looking over the list, there are at least a couple of things that are planned features (or have at least been planned features at some point in the past), as well as some things that have been explicitly stated as "will not happen".

  5. I just want to jump in and say I support this idea. I expressed some concerns a while ago about the current system, and the response I got was basically "Shhh! Hackers search forums looking for people talking about vulnerabilitoes. Just don't mention it and hopefully no one will try to use KSP as an attack vector", which of course is absolutely stupid.

    Considering the (well-deserved) attention that KSP is getting these days and will undoubtably continue to get, it's only a matter of time before some malicious actor finds a way around the safeguard that are in place and distributes a plugin that does something nefarious. I think Majir is absolutely right that the time to put a system in place to try to prevent that kind of thing is now, before an attack forces us/Squad to do something about it.

    I don't have a lot to add to the conversation right now that hasn't been said, but I'm going to continue to watch this thread, although I'm not on the forums much these days, and try to chime in when I have something helpful to add.

  6. If the problem is that OP's planes don't lift off until they drive off the edge of the runway, why would putting a ramp at the end of the runway make any difference? You'd still have to taxi all the way to the end of the runway before getting airborne. Making the runway longer also isn't the solution (the scaling question being entirely irrelevant). Most craft I've seen get up to their max speed after about 1/4 the length of the current runway. Making it longer won't make it easier to take off, it'll just increase the distance you need to roll before you get to the edge of it and end up in the air.

    If the OP wants to be able to take off from the middle of the runway instead of the end, all they need to do is move their aft landing gear forward so they're closer to the center of mass of the craft

  7. Seret is kind of correct, in that most elevators have a mechanical safety device on them that if the car starts moving too quickly, it applies a brake to the cable, slowing it down.

    Now, assuming the cable has snapped, all possible safeties have failed, and the elevator is free-falling to the ground, your best bet would be to lie flat against the floor of the car, to maximize the surface area that the impact force will be distributed over, and thus reducing your injuries as much as possible

  8. I started to use this mod again but I have a problem. I added the reaction wheels and redone everything needed for .22 but the LM pod is unable to use it's engines. in the VAB it doesn't show that it contains any fuel. It's just like any other command pod. Does anybody know how to solve this?

    Hi Reddragon. I just loaded up the pack in .22 and the LM Pod is working fine for me in it's "out of the box" state. Is it possible that you clobbered something in the cfg file when you were making changes? If you want to post your work here I'll take a look at it and see if I can identify the problem.

    Also, Komatozz, those textures look really, really nice. I'm almost inspired to start messing around with the pack again, but I have so little free mental capacity these days. I may drop you a message sometime over the next couple of weeks though if you're still around, and if I find a little time to sit back down with Unity and see if I still remember how to do anything.

  9. As was said, you cannot escape Kerbol, but you can get arbitrarily far from it on an "escape trajectory". It will not crash the game, but it can cause ships that are in orbits around other planets or moons (especially moons, it seems) to simply disappear after you return from being focused on the escaping object. Probably has something to do with how floating point numbers have larger and larger rounding errors the larger they get, since the game measures all distances from the focused object

  10. This common issue is now fixed in client v0.1.1.1 available on SpacePort

    I was having the same issue today. I think I was running 0.1.1, though. I guess I'll try again tomorrow with the new client (or maybe I'll just wait for 0.1.1.1.1 to come out ;) )

    Also, while I understand that you are just getting this thing started, and in the "just make it work" phase, I would like to make a feature request for down the line. I'd love to see a setting to turn off timewarp entirely, so that it would be possible to run a completely real-time server.

    Oh, and fantastic work, by the way. This is truly amazing, and I can't wait to see where it goes from here.

  11. There is another consideration: IVA viewing. Interior modeling is possible of course, but I think the ability to view active instrumentation (inc. the nav ball) would require some kind of code.

    Nope. There are pre-built "props" that are included with the PartTools scripts that are used to export projects from Unity into KSP. All one needs to do is set up their interior model, and create an interior space config file that spells out which components you want to have in your cockpit, and where to put them

  12. Someone would (might) be able to create a mod vehicle with multiple .cfg file values; essentially allowing a 3D model of a lifting body to possess the attributes of command pod, fuel tank, lifting surface and engine; all in one .cfg file. I do not know if it would need some code (.dll) files as well. I'm only capable with modeling, texturing and .cfg files. For all I know, there might already be such a mod available from the Space Port. More knowledgable forum members will probably have useful information about that to post in this thread.

    Can be done fairly simply with a .cfg edit and a custom model. No plugin required.

  13. Well, I hate to eat my words, but unfortunately I just don't have the time right now to devote to this project.* Real life can be a cruel mistress sometimes. Maybe I'll pick this back up again someday, but I feel like by then someone more skilled than me will have done it better. This guy (http://kerbalspaceprogram.com/0-21-x-world-space-0-3b/) has a whole pack of real-world parts, and he includes the Saturn V and says he wants to do the lunar module eventually. His models look really good, so hopefully he'll complete his project. In addition, if anybody wants to pick up development on AMP, I'll happily provide any source files I've got.

    Thanks for all the support and encouragement along the way.

    *I'm also going to be spending a lit less time on the forums moving forward. I'm getting really sick of seeing people whine and bitch and complain every time Squad does anything. This whole uproar over the tech tree, which no one has even seen yet, has really soured my opinion of the level of discourse around here. I'll check in now and again, but I'll be keeping my mouth shut for the most part.

    Good luck and happy landings!

×
×
  • Create New...