rextable

Now that KSP2 is dead, what are the implications for modders to plunder KSP2's assets for import to KSP1? Discuss

What's happened to all the links?

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

:::::::::::::::::::::::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

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.

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.

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

Nope. ...erm... I think your problem has just been solved for you - check your PMs

DELETED

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?

That video looks like something out of a Voidz music video .

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 .

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.

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.

Dude I just had a fanciful idea! It's probably well beyond the scope of simply modifying DOE but I thought I'd mention it anyway. Ya never know - it might inspire you. It occurred to me that currently, DOE dims the entire skybox uniformly and it does so by changing the gamma or opacity values... right? Meaning that all objects on the skybox textures - regardless of their perceived brightness - are dimmed informally. The result being that the brightest/largest objects appear dark grey rather than shrinking to tiny points before disappearing entirely. In the real world, other stars, nebula and galaxies (or parts thereof) are brighter than others and so some stars would remain visible longer than others as light levels in the FOV increase. Look up at the night sky from a city and one might see the Orion constellation. Look up from a field in the countryside and you'll see Orion and the Milky Way galaxy. Look up from atop a mountain in Chile and you will see Orion, the Milky Way galaxy and much else besides.... You get my point. The long and the short of it is: everything on the skybox texture is dimmed by the same amount, everywhere! Possible Methods to improve this could be....???? (1) A multilayered Skybox with objects distributed per layer depending on their relative brightness. Three or four layers would probably do. Skydimming is then applied to each layer thus making the dimmest stars and objects disappear first and the brightest last by differing amounts as light levels increase and decrease in the players FOV. While I reckon this would be the ideal approach (short of rendering the entire fkin universe in 3D ) It would require a lot of photoshop work to create the texture files, not to mention the requirement of making the current skybox system able to handle multiple layers. This will also be incompatible with all other skyboxes... which would be somewhat antisocial and limit user uptake. The following option would be more doable.... I reckon . (2) The judicious application of filtering/blending/feathering in edition to or instead of overall gamma and/or opacity (as per currently in DEO). In other words, if dimming could be applied to the skybox on a per-pixel basis rather than globally, a slightly more 'realistic' dimming effect could be achieved. This would be a little more CPU intensive but no more so than applying a blend layer in photoshop because the KSP skybox is just a static image. This approach would also be compatible with existing skyboxes provided some tweakable parameters were accessible to dial in correct values to cope with varying RGB ranges. The stock skybox background is actually quite grey. Currently I'm using Rareden's skybox which has a far greater range of RGB values than stock. So as a user in switching between these two skyboxes, I need to be able to change some parameters to cope with these variations if you see what I mean. ....... Anyway.... probably pie-in-the-sky fanciful nonsense but there it is. Feel free to ignore me :-) ::::::::::::::::::::::::EDIT::::::::::::::::::::::: If by some incredible miracle you were inspired to tinker with this, I'd love to help you test and can bring my not inconsiderable photoshop skills (from having been a professional photographer IRL) to bare if needed.

Very interdasting. I didn't realise it was the modability of KSP that made it slow to load. Well, I think slow loading is well worth the price of amazing mods and modding community. By "streaming" do you mean 'loaded on demand' sorta thang or something else entirely? Agreed :-)

Ha. And there I thought I was being too demanding. I'm glad you met my ideas with enthusiasm. The issues I mentioned really are very minor though, so please don't loose sleep over it . Yes - go for the release - I look forward to testing it

Glad to see Mr Lisias is maintaining/updating this mod :-) I don't suppoooooooose..... while you're making improvements to the mod good sir, you might consider looking at a couple of longstanding minor shortcomings would you? (1) Flares don't play nicely with Scatterer atmospheres. I don't know if it's a blending or layering thing or what. The 'problem' is particularly noticeable when orbiting Jool. cilestial body flares look very weird as they rise and set through the scatterer atmosphere. Try it - you'll see what I mean. It's a very minor thing but it'd be great if was sorted out. I did mention this to Blackrack long ago but his give-a-s@%t-o-meter didn't even twitch . It might be something that you can address. (2) Finesse of the skydimming feature. I luuuve this feature! However it would be great to have some more control other than just the skybox maximum brightness. Maybe a sensitivity and/or radius + feather controls??? This is only really required when Scatterer is installed because it makes celestial bodies with atmospheres and Kerbol appear much brighter to the player. The brightness added by Scatterer (and be extension Sunflares of Maar) is seen by the player but presumably not by the skydimming algorithm. This very noticeable when orbiting Kerbin. Kerbol can be fully on screen and the skybox will still be visible. It's only when you aim the camera directly at Kerbol that the skybox dims completely. This same phenomena occurs with any atmospheric body that isn't dead center of the screen (while in high orbit or during transfer). As already stated, with the Stock Kerbol, this phenomena is far less pronounced. It's only when Scatterer + Sunflares of Maar are installed that is becomes a noticeable shortcoming. If there was radius and feather controls for how sky dimming algorithm interprets bright object on the screen, players (with their infinitely varied mod installs, tastes and preferences) could tailor when and by how much the skybox is dimmed to their liking. If you have the time and are so inclined to investigate these things, I for one would be most appreciative of it

Being "mostly right" is something I guess

Apologies if this has already been reported (looked at previous pages but there's 57 of them) but... There is a very nasty transition on Minmus as you go from a very high orbit to a low orbit. It's being caused by the Minmus' Scatterer teal glow. It looks fine from far away and lovely close up, it's just that middle part.... ya know... as you approach . The quick and dirty fix is to set the the 4th column in the colour row of the MinmusGlowTeal object in the EVE_atmoMain Spectra config file to zero. Doing so effectively makes the glow invisible. I reckon the problem could be solved properly with the Scatterer configuration tool, but it's beyond me and I haven't the patience. Soz.

I reckon that "dustiness" is actually Scatterer's atmosphere. Unfortunately I know nothing about Scatterer's settings or what they do so I can't help you tweak them to your liking. However Scatterer does have a user guide linked in its download folder. Why not have a look there :-)

It's totally doable in a reasonable timescale dude . As I've already said, one dude with a decent PC and some sample and instrument libraries can be very productive indeed. 'Adaptive music' = layered parts ( i.e. instruments, sounds etc.) and musical passages (eg passage A, passage B, interlude A, interlude B etc.) that come and go in response to the unfolding action. All totally, totally doable from a technical point of view. Easy even! Dark Forces II did it with a CD in the drive 25 years ago . Years ago I studied game audio at university and a visiting industry professional told me that: the only limiting factor for a game's audio (music and otherwise) is the CPU budget allocated - which is entirely based on how much the dev team care about game audio. Typically, developers care very little about sound and music because it ain't sexy graphics that sell the game. The projects and experiments we came up with as students was far superior in terms of its adaptivity, layering and complexity to even modern games today. Why? Because we weren't constrained by a developer saying "you can only have 4 audio channels" or "you can only have one effect send" or "convolution reverb?!?!? Forget it" etc. The tools for creating amazing dynamic soundtracks and environments was there 15 years ago. To this day, those tools remain very underutilized because they're just too expensive computationally.

I totally agree - KSP is a game, not a hardcore simulator. My Horse Economy III gag was my derpy way of making that point. KSP1 is difficult (and thus entertaining) enough without the limiting factor of cashmoneyz in the bonk account. In real life there is nothing but pigeons in my bonk account - which is definitely preventing me from going to space in the fashion I would prefer . In the KSP1 career mode, the money and prestige mechanics always stifled my creativity and made playing the game into a chore, so I only ever play in science mode. Getting that sweet sweet science is challenge enough for me personally. Agreed. To elaborate on what you've said: exploration and discovery as a primary means of progression is not only in the spirit of the original game, but also in the spirit of human scientific endeavor in general.