Jump to content

rextable

Members
  • Posts

    109
  • Joined

  • Last visited

Reputation

59 Excellent

1 Follower

Profile Information

  • About me
    Terror Pigeon

Recent Profile Visitors

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

  1. Very very very exciting!!! I'll definitely be a day-one purchaser. I truly cannot wait to try this out and participate in the feedback process :oD Roll on February
  2. :::::::::::::::::::::::Moderators please delete this thread if it has already been discussed constructively and in-depth elsewhere:::::::::::::::::: Erm.... Yes. Catchy title eh? I bring this up here after the concept of 'mod support in KSP II' came up in the Exhaust Plume Dev Diary. The question of how exactly and what exactly could/should be left exposed by the developers for modders to play with. This made me wonder if that conversation has been had and those questions asked about modding in general for KSPII. I've seen plenty of discussion about what game features people would like to see in KSP2 but nothing specific about what mod authors would like to see. KSPII devs have made very clear their commitment to the modding community for KSP - which is great! A logical and surely useful question would therefore be: What do the mod authors want? Additionally, one could ask: what lessons can be learned from KSP1 modding? What roadblocks did modders find in KSP1 that could have been avoided if the original devs had done things a little differently? What hooks would mod authors like to see left exposed in KSP2 that were not in KSP1? What would mod authors like to be able to do in KSPII that is not possible - for whatever reason - in KSP1? How could KSP2 modding be more powerful, flexible and manageable for authors and users alike? I hope people will understand the spirit if what I'm asking. Please don't misinterpret this topic as "how did the devs screw up KSP1" or that I'm somehow demanding/expecting infinite modability of KSP2. I just thought it was a pertinent topic that might be beneficial for everyone to discuss. Some examples of specific things that might be useful to the KSP2 devs to know for example could be: When developing Scatterer, what things did Blackrack discover that could have made his/hers (????) life easier or Scatterer even better than it already is? When developing Kopernicus, what did R-T-B learn that might benefit the KSP2 team? What could Lisius say about developing nightmare mods like Tweakscale that could make it easier? What could Serbian share that would make indispensable tools like Module Manager better? Do you see what I'm getting at? Just to clarify what I mean by 'mod author.' I mean people who create entirely new entities and functionalities for the game - the Lisius', Blackracks, R-T-Bs and Neateas of the world; the tool creators; the hardcore code-writing most bodacious modding mofos from outer space. I do not mean people like me who tinker with Scatterer's parameters (for example) or create Module Manager config files here and there and pat ourselves on the back for a job well done. In summery, what constructive feedback can the KSP1 modding community give the KSP2 dev team that would make KSP2's modding experience more betterer? DISCUSS
  3. Scansat.... Definitely Scansat! ..... Did I mention Scansat? :-) Seriously though, Scansat's scanning mechanics is a fantastic and satisfying mini game in it's own right IMHO.
  4. I just had a thought that no one has mentioned yet: plume modability. The community clearly has some very knowledgeable and talented people with eyes for detail. However, no one will hold anything against the Intercept team for not implementing each and every suggestion from community members. As you have already stated - you only have so much time. We all understand that. Instead, may I suggest that solid provision be made for modders to tinker with and further build on your work after release. If you don't have time to fully develop insanely detailed heat haze or relative brightness and exposure effects (as per HB Stratos' fascinating post) for example, leave the hooks exposed that would allow us lot to have a go.
  5. On the topic of landing site choice as alluded to by Pthigrivi's diagram: How many times have people picked a landing site for their new base in the KSP1 map view, only to plop down and realise the site is totally inappropriate in one way or another for the given mission? Maybe it's too steep and your habitation module is on the wonk. Maybe you're too deep into the atmosphere and you can't get back into orbit? We've all been there..... right..... chaps....??? Anyway... The Scansat mod - as we all know and love - has various planetary overlays that help mitigate the potential for frustration in landing site selection. Variables - terrain/slope, biome, resources, etc - can all be collected and displayed on their own map projections. Aside from being incredibly useful, these maps are also a feast for the eyes. They transform the experience of choosing a landing site from a potentially tedious and frustrating one into an almost-fun and visually appealing game mechanic in its own right. I say 'almost-fun' because there are serious limitations and omission in functionality to the ScanSat mod and the stock game as they currently stand. Like Star Trek's Data - who just luuuves scanning for life forms - I personally really enjoy the whole scanning/landing-site-reconnaissance concept that ScanSat kind-of-almost-but-not-quite achieves. It's almost there but just doesn't go far enough. The KSP2 devs could (imho) very easily build on what Scansat has demonstrated to be potentially a visually stunning, engaging, educational and fun aspect of real-life ISRU. Currently (with or without Scansat installed), one selects one's landing site by a mixture of blind guesswork, peering at one overlay at a time and memorising where the good spots are for each one. I've always thought that surely it'd be easy and worthwhile to add a further layer of functionality - an automatic detection function that displays potential landing sites or POI (Point Of Interest) in the map view based on the data available and within player's specified requirements. EG "Show me POI within this slope range, between that elevation range, within x & y biome, with a, b & c resources and within x radius of z anomaly." If the player has yet to scan for a particular data type, that data isn't taken into account. With all those factors involved, there will likely be only a very small - thus manageable - number of suitable locations on any one body. The player can then select one or more of these POI, name and store them to be recalled at any point as targets/waypoints/landing-sites for future missions. In real life, this is more or less what NASA does. They don't just rock up to a planet and say "right nerds - where shall we plop down?" Obviously NASA takes months, nay years to analyse the recon data they collect and make decisions on potential sites based on the information available to them. But in gameymcgamegame land we don't need to wait this long. The comparatively tiny number of variables and volume of data a Scansat-type of game mechanic would collect would be computationally very easy to whittle down to a handful of POI that your average gamer - and their PC - can handle. One could go even further and gamify the POI generation process if the magic-do-all-the-work-for-me button doesn't appeal. For example: in the tracking centre (or some other asyettobebroughtintoexistence science processing building), POI could be represented graphically as Pthigrivi's diagram illustrates; as layers of overlapping circles on a planet's surface. The player could draw them photoshop-shape-tool-style on a body's surface by surveying the various terrain/biome/resource maps they've collected. From there, the player can ascertain a handful of locations, create an X-marks-the-spot type target (as Mechjeb kind of does already) that can be saved and recalled as described earlier. This could be just one of a load of 'science minigames' within the game.... but I'm getting off topic now.... I'll stop typing now. That is all.... carry on x
  6. Nope. ...erm... I think your problem has just been solved for you - check your PMs
  7. Hey Poodmund

    I was wondering if you might be interested in chiming in on a conversation I'm having with Lisius about improving KSP's skybox situation. We're talking about improving Distant Object Enhancement's skydimming feature.

    Basically, Lisius reckons he would need a 32bit HDR skybox to make the skybox dim and brighten realistically. I located some HDR files of the real life night sky over at NASA but they're not projected as we would need them for a KSP skybox. As someone who's created amazing skyboxes for KSP in the past I thought you might be able to share your experience with this.

    Come and have a look if you have time :-)

    1. Poodmund

      Poodmund

      The less I have to deal with Lisias the better, sorry.

    2. rextable

      rextable

      Okay cool.

      My apologies - I didn't realise you two weren't friendly.

      x

  8. Okay. I found what appears to a high dynamic range star over at NASA. If you visit the page, scroll down, you'll see various different projections in various different resolutions - all the way up to.... 20K? They're in EXR format which CS6 or newer versions of Adobe softwarez can handle, although there is a free plugin with more control called ProEXR by FNord. The trouble with these maps is they're not quite ready for use right off the bat - they need to be re-projected. My skill set starts and ends with portrait/documentary photography and the associated processing workflow. There's not much cause for spherical projection conversion in that arena . Does anyone know how to do this?
  9. I reckon It's safe to assume KSP does not support HDR anything. Yes - a 32bit pipeline would be the 'ideal' solution. But we're talking about modding someone else's mod of a 12 year old game .... and Lisius's sanity should probably at least be considered . I reckon a lot can be achieved in the 8bit realm. I'm talking about modest improvement, not glorious perfection here .
  10. By 'high dynamic range' you mean greater than 0 - 255 as per RGB? The trouble is that the real life starry sky isn't exactly high dynamic range. Mostly it's dark and, really dark . I know the stock skybox is really grey. Have you looked at Rareden's Real Skybox? It is properly dark - as in RGB values of 0,0,0, - and the stars very bright. It's the closest thing - readymade - that you're looking for. Without DEO it looks ridiculous cuz the stars are waaaaay to bright, but with DEO's maximum brightness set to about 20 it looks very not-too-bad indeed.
  11. Hairymuff :-) re your guithub comments: I agree the current method looks pretty good most of the time and is "good enough." I've got all the graphics mods in the universe (including DOE) going on my latest playthrough and I keep marveling at how great the game can look. As for the effort required to improve DEO's skydimming; it comes down to whether you think it'd be an enjoyable project or not. Only you can answer that question. ...... Oooooh.... .... I Just had a brainwave about a 4th possible way: What about the existing DOE flares???? They're already integrated to respond to skydimming aren't they? Couldn't you create a handful of ghost flares and dot them around the sky to simulate nearby stars? you wouldn't need that many, nor would it matter if they didn't match the exact location of pixels on any one skybox. This method would save having to create an entirely new system from scratch. you just have to repurpose an existing one. . It wouldn't 'fix' the shortcomings of the existing skybox dimming but it might mitigate them.
×
×
  • Create New...