Jump to content

HarvesteR

Members
  • Posts

    3,542
  • Joined

  • Last visited

Everything posted by HarvesteR

  1. It ocurred to me that there is little to no documentation at this point about the new ScenarioModules and how to add them to your game. With that in mind, I've written this brief guide as to how they are used. I'm assuming you already have some experience writing PartModules, in which case it should be relatively straightforward to learn how ScenarioModules operate. If not, I strongly suggest reading through the available PartModule coding tutorials and (admittedly very incomplete) documentation first. Let's get started then: Scenario Modules, just like PartModules, are compiled into dlls that go in the Plugins folder. In fact, nothing stops you from having ScenarioModules sharing dlls with PartModules. The dlls in Plugins simply add their classes to the game assembly. Once added, a ScenarioModule is loaded into the game through SFS files. In very much the same way you set up a PartModule in a part.cfg, you set up a ScenarioModule in an .sfs file: GAME { version = 0.17.0 Title = Orbiting 101 Description = This training scenario covers the basics of flying a blablabla.... // mode 0: Sandbox - mode 1: Career (not available yet), mode 2: Scenario, mode 3: Non-Resumable Scenario Mode = 3 // scene to load when starting this save. scene = 7 PARAMETERS { // flight parameter stuff } FLIGHTSTATE { // flight state data (in 0.16 this was your entire sfs file) } SCENARIO { // the name of the ScenarioModule class to spawn name = TutorialOrbit101 // the scene in which the module gets spawned (7 = flight) scene = 7 } } The only limitation at the moment is that to add a scenario module to your ongoing sandbox game, you'll need to manually add the module config to your persistent.sfs. Once added, it gets loaded into the persistence data structure and will remain in your sfs file even as it gets resaved and rewritten. ScenarioModules have one main difference from PartModules though. Because they are made to run on any scene, you must specify a target scene in which your module will run. Currently, modules can only run on one scene at a time. When a scene starts, the scenario module runner attaches all ScenarioModules that target that scene as a MonoBehaviour on an empty game object in the scene. You can use all MonoBehaviour events (except Awake), and code it in very much the same way you code part modules... Of course, there is no reference to vessel or part, since the module isn't attached to one. Hope this helps. Cheers
  2. Scenario Modules, just like PartModules, are compiled into dlls that go in the Plugins folder. In fact, nothing stops you from having ScenarioModules sharing dlls with PartModules. The dlls in Plugins simply add their classes to the game assembly. Once added, a ScenarioModule is loaded into the game through SFS files. In very much the same way you set up a PartModule in a part.cfg, you set up a ScenarioModule in an .sfs file: GAME { version = 0.17.0 Title = Orbiting 101 Description = This training scenario covers the basics of flying a blablabla.... // mode 0: Sandbox - mode 1: Career (not available yet), mode 2: Scenario, mode 3: Non-Resumable Scenario Mode = 3 // scene to load when starting this save. scene = 7 PARAMETERS { // flight parameter stuff } FLIGHTSTATE { // flight state data (in 0.16 this was your entire sfs file) } SCENARIO { // the name of the ScenarioModule class to spawn name = TutorialOrbit101 // the scene in which the module gets spawned (7 = flight) scene = 7 } } The only limitation at the moment is that to add a scenario module to your ongoing sandbox game, you'll need to manually add the module config to your persistent.sfs. Once added, it gets loaded into the persistence data structure and will remain in your sfs file even as it gets resaved and rewritten. ScenarioModules have one main difference from PartModules though. Because they are made to run on any scene, you must specify a target scene in which your module will run. Currently, modules can only run on one scene at a time. When a scene starts, the scenario module runner attaches all ScenarioModules that target that scene as a MonoBehaviour on an empty game object in the scene. You can use all MonoBehaviour events (except Awake), and code it in very much the same way you code part modules... Of course, there is no reference to vessel or part, since the module isn't attached to one. Hope this helps. Cheers
  3. Hi, I've created thread prefixes now, which are VBulletin's "official" way of tagging threads. You can now choose a tag from a list when posting, and your thread will get a colored tag along with the title. The only drawback is that it seems you can't have multiple prefixes... It should be worth the tradeoff though. Cheers
  4. Yes, this is the place for all those "not exactly about KSP but not entirely off-topic either" type posts. Cheers
  5. Hi, Welcome to Science & Spaceflight, a place to discuss all things pertaining to science and general geekdom. This is much like The Lounge, except there is a bit of a topic of sorts. KSP talk is allowed, as long as it's founded in geeky and/or scientific notions... Otherwise, it probably goes in General Discussion. Goes without saying, no spam and postcount-padding allowed here, or anywhere for that matter. All usual forum rules apply. So, that's about it I think. Come on in and let loose your inner nerd! Cheers
  6. Welcome to the Forums, hope you enjoy your stay! Happy launchings!! Cheers
  7. The difference between aerobraking and aerobreaking is a couple thousand meters on your periapsis altitude. Cheers
  8. The center of lift indicator is a bit of an oversimplification of a more complex problem actually. It is calculated by assuming the ship is flying forward at a set speed, and querying all lift-producing parts to find their lift forces given that same velocity. The thing is, those forces will vary depending on the angle of the wing surfaces to the airflow, so the information you get from that single node doesn't really tell the whole story. The best way to use the CoL indicator is to grab the entire ship by the command pod, and use the Shift+WSADQE keys to rotate it around. That way, you'll be able to see the CoL changing to indicate the position and direction of the net force acting on the ship, for any orientation. Think of it like holding a paper airplane against the wind at different angles, to feel how it reacts. If your vessel has the CoL passing directly through the center of mass at some orientation or another, well done. Your ship is very stable. If not, there is another way to test for stability: If by pitching the ship up and down you find a point where the CoL changes direction, that means that there is an angle of attack where the lift forces balance out, and you are also stable. When I was writing the code for these indicators, this "problem" became apparent. We realized here that the ideal way to visualize the aerodynamics of a vessel would be to not have a CoL indicator at the construction facilities, but to have a proper dedicated wind tunnel facility, where you load in a vessel to test against simulated airflow. It's not only a better solution for testing, it's also a lot more fun too. Although as you can imagine, it's by no means a small feature. We decided to add the CoL indicator on the VAB and SPH now as they are, and keep the wind tunnel on our feature wishlist for now. Cheers
  9. Hi, welcome to the forums! You can find most mods in the Addon boards on this forum. They should work equally well for the Mac version. Cheers
  10. The reason we haven't included that tool is because it causes trouble more often than it works... It's a very hacky thing we threw together here. Granted, it is very useful for testing and such, but the potential for destruction is just too high. We do want to clean it up a bit, and make it available through the cheat toolbar. So, it's possible it will be included on a future update. Cheers
  11. Because that saves bandwidth. Cheers
  12. Hi, I'm happy to announce that we have just officially released the 0.17 Update for KSP. As you all probably know already, this update was about adding many small (and some not-so-small) features, to improve the overall playing experience, and make the game feel more complete. Here are the main features: Several new Planets and Moons, for a total of 14 Celestial Bodies. Multiple game saves support. Tutorials and Scenarios. Several new Parts, including a NERVA Engine. Internal Cockpit Views on several cockpits. Center of mass, thrust, lift and drag visual cues on the construction scenes. Physics Warp: An alternate time-warp mode where you can accelerate time to 2x, 3x and 4x without putting the sim on rails. Much improved visuals in space. And a lot more! The update is available through the (greatly improved) Patcher tool, as well as a full download from the KSP Store. Happy Launchings! Cheers
  13. For now, they use the same liquid fuel as normal engines, but with vastly improved Isp in a vacuum. (they're pretty inefficient in an atmosphere). We are thinking about other fuel types for it, but that is something for later updates. About the voice-overs, we almost got them ready, but they actually sounded pretty weird without a proper audio ambience base for the game's scenes. We're going to add those soon, and the voices should follow. Cheers
  14. I still sometimes play games that are too old to run on current hardware and OSes. Games like Full Throttle or Fragile Allegiance, they need to be run with emulators like ScummVM or DosBox. Many years from now, it's not at all impossible that tech from today like the Unity player becomes too old to be supported by the hardware and OSes of the time, so you'd probably have to do the same thing we do now to play DOS games. KSP has a somewhat greater-than-average chance of being playable on unsupportive systems in the future though, because it is a unity game, it's much more likely someone in the future will create a UnityPlayerVM or something, to run all unity games. If we were using a proprietary or obscure game engine, chances would be a lot worse. Cheers
  15. This is on a level of awesomeness right up there with the Curiosity team shout-out. Or even more so actually, I've been following xkcd for far longer than Curiosity. Randall Munroe is one of my idols. I can't describe how awesome this feels! Thanks for posting this! Cheers
  16. Up to 4x warp, to be more precise Any more than that wouldn't be very useful in any case. Cheers
  17. People have asked for it, so I thought it would be a good idea to promote this post I made a while back into a forum article. Hooray for VB! When I was little, I used to build model balsa-wood airplanes, and I learned some useful rules of thumb that might be worth sharing: One, if it looks like a plane, it will probably fly like a plane. Try a very conventional design before you go for the successor to the SR-71. The KRJ-100. Looks very much like a plane. It will glide without input. Two, the center of mass should be at the first third of the wings. Mentally divide your wing into three sections. The plane should be balanced at the first division threshold. (landing gear can be just aft of that, to provide a nice fulcrum) The KRJ-400 JetLiner, it\'s as heavy as it looks like. Three, vertical stabilizers should actually be pushing down, not up. Use the rotation feature in the SPH to pitch your elevators down a notch or two before placing. The wings alone will make the plane pitch down, while the stabilizers keep the nose up. Planes are stable when those forces even out. The Annihilator Mk1, the V tail acts as both rudder and elevator, and they\'re pitched down 10 degrees. Four, canards are like pushing on a rope. See rule 1. The Ravenspear Mk1 is much trickier to fly than the Annihilator. Pitch too aggressively, and it will tumble out of control. That\'s about it for now, hope this helps. Cheers
  18. Jeje, no hay problema. Soy Licenciado en Diseño de Videojuegos, por la Universidad Anhembi Morumbi, de Brasil. Saludos!
  19. Just to make it clear though, KSP will be available on Steam in the near future. How much integration with the API, Workshop or Greenlight there will be is still to be decided, though. Also, KSP will remain available through the KSP Store. Going on Steam will just open another method to getting the game. That's about all the facts we have for now. Just wanted to set the record straight, as there is a lot of speculation going around about this, and speculation will turn into misinformation very easily. Cheers
  20. Yes, but the old (buggy) fuel code is still there, so mods could still work. I said plugins would possibly need a revision because authors will probably want to use the improved system instead of the old one, which is now deprecated. But as everyone said, there are never any guarantess for backwards compatibility. If we can avoid breaking old saves, all the better, but we don't go out of our way to preserve it... At this point in development, that would be a huge waste of effort. As the game reaches scope-completion, though, chances are that there will be less and less changes to the file formats, and these compatibility breaks will become less common. Cheers
  21. HarvesteR

    Riddles :D

    Ok, I've been thinking this over for an inordinate amount of time now, so I'm going to hazard a guess here: An Address. The reasoning behind it is as follows: * An address can be given (left behind) to guide or to stray * An address consists of symbols and patterns * An address can be etched in stone, or written on any (unmarked) surface. * The address' host is whatever material it is written on, and unless the etching itself fades, it will last as long as the host does ("until" implies "not any longer"). * The address itself is meaningless save for those who know what it represents (its lord) * For those, it will lead them into finding something of interest. * While it is readable, the address itself is overlooked, over what it represents (yeah, kind of a stretch this one) * But lose it, and you lose your way. Cheers
  22. Ah, thanks for pointing that out. I set the permissions so all members can now view blog posts. Cheers
  23. Hi, Now that we have forum blogs up, I figured it'd be good to post links to our dev blogs here, so you can find them easily. Here they are: HarvesteR C7Studios NovaSilisko danRosas N3X15 I'll add the other ones as we set them up. Cheers
  24. Interesting topic this one... Completely unofficially, here's my take on it: Kerbin: Kerbal Mun: Munar Minmus: Minmusi Eve: Even Char: Charian Gilly: Gillian Bop: Bopee These are just suggestions tho... There's no 'canon' for this yet. Cheers
×
×
  • Create New...