• Content count

  • Joined

  • Last visited

Everything posted by Alshain

  1. However, when this does happens, you can't stop it. Cancelling the execution, even with signal delay off, doesn't work. Is that a known problem? The best you can do is shut down the engine quickly, delete the maneuver, and go back to the space center and sometimes when you return RT will have deleted the execution finally.
  2. @taterOk, well barring an entire overhaul of KSP as we know it then, Life support won't work and any colonization effort would have to be for off world manufacturing.
  3. In your play style maybe, but I'm not going to Jool in real time and I seriously think you are in the minority there. Most people timewarp to jool.
  4. Space stations don't need propellant. So that isn't tedious at all. Unless they implement N-body it will remain that way. Constant life support resupply missions are tedious. The only way to curb that would be multiple payers working on the same station. So without multiplayer, LS is tedious and a lot more tedious than bringing enough propellant (which is none at all). If LS is required for a meaningful colonization then I say no to colonization. However, I think it can be made meaningful with just off-world manufacturing as the end goal, so even that isn't true.
  5. Lol, it was the planet of fog when it first came out. It looked awful. It's reaally good now.
  6. Life Support just isn't a good fit for KSP as long as it's single player and has timewarp. Its just tedious micro management. As for colonization, I've been trying to figure out MKS with EL lately, but it's so overcomplicated, ReadPanda (the only current tutorial vid I could find) had to explain it with powerpoint. It's so overwhelming I just can't even figure out where to start. A stock system would have to be a lot more intuitive.
  7. Yeah sorry, the forum showed it in bold and with the little blue dot and I just assumed the last post was new. I don't know why the forum decided it had unread posts, I know I've read this thread in the last few months.
  8. Problem 1: Squad would have to predict where the developer wants to show emphasis. They could design a set of emphasis styles but some developers use several degrees of emphasis. Problem 2: Some developers enjoy designing GUI, I'm one of them. Though I just did my first Unity/KSP GUI (well, redesign), I've been doing .NET GUI for a long time. If you remove what I enjoy I might not be inclined to continue doing it. It isn't like I'm getting paid, I do it because it is fun. They could make it optional and have settings for the user to choose, but it should remain up to the developer how to use it. Which brings us to: Side Note 3: This exists, just without the user control. Of course, I'm new to this so I just discovered how it all works last week. However, in Unity there are Skins and Styles and KSP has a default skin, which the developer can modify (I found that out by accident, the current release of AGM currently screws up KER's design, I spent yesterday fixing it... I regret nothing!) So a mod could do this, make the user control that is. However, if the mod changed the default style it would only apply to mods who are using the default style exclusively. The GUI I made for AGM uses almost entirely custom text styles, largely because I hate all green text... it makes my eyes hurt. I did however carefully choose colors already used by KSP, so it does match. Unity 5 also has Asset bundles which also adds another problem as I don't think those use the styles. (Don't quote me on that though, I'm not 100% certain) Oh and another issue is images. If you force text colors, you are likely to end up with colors that don't compliment the images being used.
  9. Well, at least some of the extra volume is in structure, the brackets needed to hold the upper part of the module, but yes I think there would be more space than even that needed.
  10. I would think there would be at least a little volume difference. A stack chute would have to be designed to structurally hold whatever is above it. A nose chute would have the external shroud which would be the structural part and that would add volume to the model we see now. It's a pyramid fitting into a cylinder after all, a lot of left over space.
  11. I agree, but there could be a cost/benefit balance situation. If the stack chutes were more costly or have more mass for their container's structural rigidity, it could balance them.
  12. I think his idea is to discard the shroud before deploying, and you wouldn't be able to deploy until you did decouple from it. That's fine, but I would like stack chutes too so I don't have to discard half my craft landing on Duna, and I don't have to have radial chutes getting in the way.
  13. The best they can do for console modding is integrate Module Manager/Contract Configurator/etc. into the stock game.
  14. @katateochi Use the Unreadifying event to unload the AppLauncher. Example: As for the other problem, I'm not sure. None of my mods load as early as the Space Center. EDIT: I just realized how old that post was, for some reason the forum was showing me the thread had new replies. Ah well, I'll leave it there in case anyone needs it.
  15. When you say "modding enviroment" do you mean a modded KSP client, a plugin development environment (changing the way the game works), a unity modeling environment (parts and more)? For the first one, what @tater said. For the second (and third) you can go there too, but this is more specific: Second one: Third one:
  16. Right, as I understood it it was if the enumerator was a class or interface. But, as you say, it's simpler to keep track of if you don't use them. But if it's the fault of the Mono compiler, I use VS so sounds like I don't really need to worry about it.
  17. I see, I was not actually certain of the reason why, I've just been avoiding them because it's not like they have to be used and there was that whole discussion over not using them.
  18. It has no cargo and only one crew. It's just a really really big, really draggy plane to carry one Kerbal. I could fix it but it would be redesigning it from the ground up. I mean, I hate to discourage, but this design isn't going to work.
  19. You have way too much drag. I can't push it much further over mach 1 even in a dive, even switching the center engine for a Whiplash wasn't enough. I got to 10,000m and pushed into a 15 degree dive with full engines (whiplash configuration) and still couldn't breach 350 m/s. That is your max velocity. Mk2 parts are notoriously draggy and you have a bunch of em all clipped together. On top of that, you have a lot of unused nodes hiding in there. The way stock drag mechanics work, unused node are drag, even at the back. You have the bicouplers clipped together where the center engine is and as far as I can tell, nothing on them. EDIT: Actually you have an unused node at the front because you clipped the cockpit inside an adapter. That counts as a flat front as far as KSP is concerned.
  20. I don't know how it is now, but Astromer's pack between Edge of Oblivion and Interstellar practically removed all the clouds. If you like clouds, like Earth, Stock Visual Enhancements is probably what you want. Skybox Replacements are actually TextureReplacer. The only thing about that kind of skybox is it isn't real. It's what Hubble sees, not what your eyes would ever see. I use a Skybox that @Galileo gave me here which is basically a high-def version of what is in stock. (I got tired of looking at blurry stars) But hey, if that is what you like, it isn't wrong to use it. It's your game, play it how you like it
  21. Oh btw @Boson Higgs. Set your target to .NET 3.5 for Unity mods.
  22. Well I wasn't because he didn't say anything about Java. I didn't want to muddy the water, so to speak.
  23. @linuxgurugamer Java is derived from C++, and C# is derived from Java so C# is derived from C++.... but they are all derived from ANSI C. You are derived from your Grandmother and Grandfather
  24. No, in a nutshell the differences between C# and C++ are not incredibly large, it's more about practices. The basics are the same. Now of course C# does have some advanced stuff in it and a few keyword differences here and there. It's not hard to learn them though, it is derived from C++ after all. The biggest thing C++ developers tend to do is declare at the lowest scope possible. (I remember back in college they used to drill that into us, declare as low as possible!) That is advantageous in C++, but because C# is a memory managed/garbage collected language and the world we live in memory is cheap, you should declare high when a variable or object can be reused or worse, falls within a loop. Just be careful not to forget where you are using it before you reuse it. That reduces garbage collection, which is CPU intensive. CPU is more important than memory. Anytime you use the "new" keyword inside a loop, you are probably creating a lot of garbage to be collected. To provide an example for(int i = 0; i < Something.Count; i++) for(int j = 0; i < SomethingElse.Count; j++) //Do Something In this case you are creating a new j every time you iterate through i. If that loop goes 600 times, you've created 600 j's that have to be collected as garbage. On the other hand... int j; for(int i = 0; i < Something.Count; i++) for(j = 0; i < SomethingElse.Count; j++) //Do Something In this case, j is only created once and re-used for each i. That's one object going to gc. Now int probably aren't the biggest cause of garbage, it's really the objects that kill but it's an example and they do create some garbage. Specific to Unity Only: Avoid foreach loops and LINQ.
  25. Active Tweakables Button v1.0.3 is now available Changes: * Add Toolbar Support * Add version file for KSP-AVC users (MiniAVC not included) * Add Changelog * Change to MIT License * Reorganize file folders