rextable
-
Posts
109 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by rextable
-
-
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
-
On 12/22/2021 at 7:46 PM, Aaron VFX said:
-
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
-
18 hours ago, Lisias said:
Well, so I believe that fellow Kerbonaut is not going to help.
Nope.
18 hours ago, Lisias said:Well, so I believe that fellow Kerbonaut is not going to help.
The link you provided on the earlier post provides a "skin" to be used on a spherical mesh. But the SkyBox is made with 6 flats surfaces, forming a cube (since the name, SkyBox).
This is going to need some serious math, as we will need to transform each pixel from a spherical coordinate into a flat one. Or, simplifying things, we need to "render" the sphere with the universe's skin and then render 6 projections using raycast, each projection being one if the sides if the cube used by the SkyBox. It's like a raytracing rendered photo, but the raycast is fired from inside the sphere to the pixel of interest, instead from the pixel into INF of its normal.
This problem was already solved uncountable times, including by me 20 years ago when I studied raytrace and radiosity (when this thing was still a novelty). Problem is… It was 20 years ago, I don't remember a thing!!!
Let's keep this cooking on vapour some time, this is getting interesting...
...erm... I think your problem has just been solved for you - check your PMs
-
-
5 hours ago, Lisias said:
Since 5.4 Unity has support for HDR. So it's feasible, but this would probably need to reimplement the GalaxyCubeControl. What perhaps would not be that hard, but replacing the stock one without breaking everything may be a bit harder.
But there's a draw back on this approach: I would need someone to rework the skybox. My approach above would reuse whatever is the skybox in use at the moment, and this is way more flexible IMHO.
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?
-
-
4 hours ago, jefferyharrell said:
Yeah. HDR images can have pixels that are brighter than the maximum brightness of SDR images. Like if 255 in 8-bit RGB corresponds to 1.0 in 32-bit float, you can have pixels with values above 1.0 — 2.0, 10.0, whatever. That means if you take an HDR image and bring the exposure down (as per sky dimming) the brighter-than-bright pixels will stay bright as the rest of the image darkens. But I don't even know if KSP supports HDR skyboxes. If it were possible somebody probably would've done it by now.
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 
.
-
1 hour ago, jefferyharrell said:
What you really need is a high-dynamic-range skybox. But I can't imagine a way to implement that.
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.
-
10 hours ago, Lisias said:
I tried.
https://github.com/net-lisias-ksp/DistantObject/issues/7
But now I have a problem: I have other tasks and duties, and diverting man-hours from these tasks to it now sounds counter-productive on the big picture.
The
nasty motherf…. uh…the project manager in me tells me to carry on these other tasks, as they are way more needed than this one.
And there're also the bugs. Just fixed another one on an add'on I was using while testing this one..
- bug fixing always come first, as these ones propagates as rabbits on the code as time goes by.
Kerbal proposes, Kraken disposes...
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.
On 10/2/2021 at 11:32 PM, K^2 said:Parsing of the part configs takes shockingly long, and that can definitely be fixed.
But yeah, given the way KSP2 is being built, there is a lot of data that will have to be streamed already. They might as well recycle some of that tech for the mods.
By "streaming" do you mean 'loaded on demand' sorta thang or something else entirely?
9 hours ago, Staticalliam7 said:the advantage of loading everything is that it's all there and loading after the load screen is much faster than it would be
Agreed :-)
-
17 hours ago, Lisias said:
THIS is what I'm talking about!
Thanks for the feedback! I can't say when I will try to tackled these down (and once I try it, if I will be able to effectively fix it), but I will not forget your suggestions: https://github.com/net-lisias-ksp/DistantObject/issues
Right now, I'm inclined to close this development cycle and make a release, as I already have a nice feature set to be published - and I have some others urging issues on TweakScale I want to tackled down yet this week.
But I can assure you I will go back to DOE soon enough - I have some interesting ideas to implement too, and they are itching on my brain on sleep time…
Cheers!
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
-
1 hour ago, geostationary_coffee said:
Just wanted to pop in here and say I managed to fix this! @rextable was mostly right, I deleted /GameData/Spectra/Spectra_scatterer/Planets/Duna and atmospheric dust levels went back up again (it also made Duna's Auroras a lot more noticeable).
@HafCoJoe If I remember correctly this is similar to a bug on the previous version that gave Duna a white atmosphere. That bug looked like it was being caused by a conflict between Spectra and Scatterer and the solution was to delete Spectra_scatterer. Looks like the conflict might still be there.
(entirely unrelated sidenote: can someone point me in the right direction to independently install KSPRC city lights? Installing CKAN seems like a hassle and I haven't been able to find this individual mod.)
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.
-
44 minutes ago, geostationary_coffee said:
It appears that the "dustiness" of Duna has gone down in the new version:
I'm on Linux. Any fix?
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 :-)
-
4 hours ago, jastrone said:
as far i can tell there are abouut 15 planets and moons in ksp 1 in ksp 2 we have seen a few planets but they wont spoil everything of course so i expect something around 4 solar systems and about 15 planetary bodies but atleast 10. then there will have to be 60 songs and that is just one song per each celestial body if we want some variety we would probably need 3 songs on each planet and that is 180 songs in total. im not saying this is entirerly correct but it could be
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.
-
2 hours ago, jastrone said:
well it is a game too. it has to be fun. that is what I think is unique to ksp compared to other similar games. and without financial limitations there is less reward to going somewhere
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.
7 hours ago, shdwlrd said:Ok, I snorted when I first read this. Intercept please let us break out of our pens and allow us to become moguls of our kerbin population without learning spreadsheets of data.
An exploration and discovery based progression is the way I would prefer how to unlock new tech. It would be more in the original flavor of KSP before the career and science modes were added. The wonder of self exploration and the awe of finding something that peeked your interest. Granted the veteran KSP players may get bored with that type of game play but it seems that Intercept is changing things just enough get that wonder and awe back.
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.
-
12 hours ago, Firebird989 said:
I had the same problem sometime ago and what I did was to delete the "Sunflares" folder in "Spectra_scatterer" and manage the sunflares directly from the scatterer directory.
Thank you for the suggestion. I'll give it a try and report back. :-)
[in silly French accent] "A Few Moments Lateeerrrrrr"
So, I have discovered that the sunflares are in-fact working..... kind of. They just don't look anything like they do in the official Spectra pics. The issue appears to be the intensity setting in the Spectra sun config file. However, HalCoJoe's flare intensity settings are in fact identical to the original Sunflares of Maar mod. So the difference in appearance must be due to a change in how Scatterer renders the flares.
The solution: up the intensity in the Spectra sun config file.
-
Hello
Me again.
I've just downloaded and installed Spectra 1.5 on a fresh install of KSP. Guess what. The sunflares still don't work
. I've just have the stock ones.
I have no other mods installed except for the Spectra dependencies. all of which are the latest and greatest.
Any ideas chaps?
.
. I reckon a lot can be achieved in the 8bit realm. I'm talking about modest improvement, not glorious perfection here 
. It wouldn't 'fix' the shortcomings of the existing skybox dimming but it might mitigate them.
[WIP] [1.12.5, 1.8.1] ASET Consolidated- Part Packs
in KSP1 Mod Development
Posted
What's happened to all the links?