Thank you for the great work when it counted my dude!

Cheers.

well, I had a blast with this mod but now tiles are dead. Thank you @AlphaAsh for this simple yet oh so nice mod and good luck in future ventures!

Oh man. Thanks :L

https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=1392776810

Use. The. Updated. Version.

Hey, not sure why but this mod is causing systems with no stars to appear and the system can't outposted

LOL here i was, feeling like an achiever, hunting down the giant red stars bug and got it down to this mod and boom alpha ash already fixed the issue. Meh, i should have paid more attention.

Thanks for the hard work man.

Small correction to the below: Class M Red Giant stars are bugged. Glad to hear there's an update for 2.1! :)

Nice, thanks AlphaAsh.

https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=1392776810

Which is why it was re-released for 2.1.

After research it seems that this mod currently is the cause of the bug I encountered on my Distant Stars/2.1 games. When it is activated all the Giant M class star are not added/drawn during the initial map generation and as a consequence all system that contains this star class becomes unclaimable (no sun = no claim).

An update would be nice since those custom titlesets are really cool ! Thanks in advance :)

I'm aware.

The file overwrite needs to be updated for the new planet classes in Niven

will this work fine if i do not have the utopia dlc?

Well, I think I finally got it!
Here it is: https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=1372838545

It had a compatablility issue with Planetary Diversity....
That was the cause of the desert tiles...

Have you commented the tile_set pointer back out? It should then default by the planet_class type.

I ended up using the exact txt your mod has, and used the exact names as your mod, but it still shows desert ...

pc_ringworld_habitable. So rename your tiles, and then let it default.

That was it. The planet_class name isn't actually pc_ringworld. It's pc_ringworld_habitat or something like that.

I recall having that issue. I'm not at my PC atm to check how to fix that.

So, I'm now having an issue with tilesets...
I made 4 new tilesets, and named them "pc_ringworld_1", "..._2", etc.
In planet_classes.txt, I removed the # before "tile_set = pc_ringworld", and it resulted in the tiles being changed to desert...

You're quite welcome. Also, moar stuffs for me too.

I knew from the moment I seen vanilla using Gaia tilesets that I would probably have to overwrite the file (killing almost any chance of compatability), so I think I am likely going to release the mod itself, then make a collection with compatability patches for other tileset mods.
More work, but someone will likely make use of it!
Again, thank you for all the help with this!

You got it.

So, if I do that, then someone comes along and downloads both my mod and this one, then they will get all of your tilesets besides that for RingWorlds, which mine will overwrite (well, if I use the same planet_classes)?

Alas planet_classes.txt is all or nothing. But if you plan to publish, put an ! in front of your mod name and it'll over-ride any content in here that has content in yours.

So, I noticed that during all of this, I have been basing it off of your planet_classes.txt file, as the vanilla one has RingWorlds use pc_gaia tilesets, while this one uses purpose-built pc_ringworld (if I remember the name correctly). My mod will do the same, as I don't want to have this interfere with Gaia worlds... Would that mean that my mod would require this one, or would I make a new planet_classes file, only including RingWorld's section?

Yup. That's looks lurvly. Well done.

I...Feel...STUPID!
The issue this entire time?
I had the files named in OPPOSITE order!
l04 was actually supposed to be l01!
I went into each file and compared the sizes to names, and it was immediately obvious!
Thank you so much for taking a look and helpings, and sorry to bother you with such a stupid mistake!
It all works now!
https://i.imgur.com/lhxF9YO.png

Your l01 is bigger than the vanilla one. It's about anchors for placement. Those anchors only work if the image size is as expected.

Your l04 isn't even the same size as the vanilla one.

You don't determine the placement of your images. The game does. Hence your images must match the placement of the vanilla images.

Because you're making assumptions about how the game will place your images. Those assumptions are wrong. If the vanilla sky has no transparency and fills the entire image, then so should yours.

I did. Here is an example: https://i.imgur.com/BGhKJfj.png

What's wrong with the sky? The bottom line of it is the exact same as the bottom line of the vanilla sky, and has the exact same image size at 560x180. The only difference is that the top part of mine is transparent, which doesn't really matter as that part is never seen due to the UI of planets.

Compare your sky image to the vanilla one. Notice you've got transparency at the top. The vanilla one does not. That's an example.

Yup, it's the x/y placement and image size. It's esoteric. Use each individual vanilla layer as a guide for each of your layers.

I'm having a look at the files to see if anything jumps out at me.

Aye, sticking your image over, using the layer below as a guide.

What do you mean by "super-impose"? If you mean to cover them up, I have (practically).
Like I said, I went layer-by-layer, covering them with the corresponding part of my own image.

Looking at those screeenshots, I think it is your methodology for divying up the images. Open up the 4 vanilla files and super-impose over those. Delete the underlying layer. Save off. I suspect it is just the x/y placement and image size expectation that is biting you in the bum.

I made a post about it over on the Paradox Forums, if you care to go take a poke at it (I uploaded the image files in a zip, and showed an image from in-game)
https://forum.paradoxplaza.com/forum/index.php?threads/need-help-making-tilesets-environments.1091444/#post-24161907

My images aren't exactly like vanilla, as I am going for a flat terrain, so I had to clip the hills out from the original images.

No A8R8G8B8 is right.

What format of DDS is used anyway? Someone on Discord reccomended A8R8G8B8. I have them all saved lime this, and the game loads l04 and sky. Perhaps DDS3 or DDS5 would be better?

If it's ignoring _l01, l02 and l03 check the DDS format. You may have a discrepancy and the game is ignoring them.

Try super-imposing over existing images, then deleting the under-lying layer. What you describe would be the way it should work. IIRC it doesn't actually though.

When I put it in-game, the planet shows the sky layer correctly, but then uses the layer just above it (pc_ringowlrd_l04" 4 times...
I have went to two different modding groups on Discord, but none of them seem to know how to do environments.

Yeah, I seen all those. I actually reverse-engineered this mod to figure out what files to mess with. My mod is a rework of RingWorlds. I made my image file as a single image, then opened all of the RingWorld images, which were named (if I remember correctly) "pc_ringworld_l01", "..._l02", "..._l03", "..._l04", and "..._sky". I then copied them all into seperate layers on a single image, aligned them to exactly match the outcome in-game, the made 5 more empty layers and copied my image onto each. I then seleceted all empty pixels of each layer, one-by-one, and deleted the secelction from the corresponding layer of my images. I repeated this until I had my five layers at the exact same size as the vanilla layers. I then split them up into their own images and saved them with the exact same names as the vanilla images.

And the gaia entry as well.