Theres no folder structure for it in scenarios, and there needs to be so that every client to join the server gets a copy of all of the changes in the XML folder. There is no XML folder yet for servers to share the data with clients. If your just running co-op with mates at home or family whatever, you could use it there because you can load it onto both PCs, the server and client manually. But yes there should be folder structure to do this soon we hope and the reason is really really simple, more diversity in the default game. Allowing this gives the devs access to potentially hundreds of custom made planets, a thing we will need if we want a Galaxy with thousands of different planets. This is part of what makes Steam great, its sharing ability with BPs, eventually I think we might see planets and XML files all be uploadable to workshop, this takes away the issues of copyright and gives the devs the chance to do something special, and there are plenty of us players willing to help build maps for nothing more than our entertainment value.
What @piddlefoot says here..... On the other hand the splatmaps also changed this all a bit as they are different and are not created using seed generation. But in any case the planed updates to turn the planets into real round space bodies removing the barriers and making them a lot bigger in the process is bound to change also the way maps are generated That may be one of the reasons devs didn't fully implemented yet the map functionalities
Improved CPU benchmark for xml planets Got me thinking: The auto-creation of the ingame planetary map is done after all that terrain deco has been placed. And the size of the map image is always the same... - So this could make for a more precise benchmark than my previous 'laptop heat rises that much faster into heat shutdown territory'* Now I count the time from session start until that map appears. Errors trough a pre-heated mainboard and tightly packed RAM notwithstanding, this yields some interesting results: ... There seem to be other major factors that drain in-game performance of worlds. That 'Battered Beauty' got the pole position and Moon Sekmet ended up even worse than Alpinia - I could travel on that moon with my (uncooled) laptop, but Alpinia drove it close to shutdown. And the moon is full of Voronoi modules, probably the worst of them all. Swiss multi was designed to keep loading times short, so there is less decoration due to prohibiting slopes. >Maybe atmosphere and lush decoration weight much more than the terrain? The Beauty is a temperate planet, with flat lowlands of tropical tree giants, and it performed as 'heavy'....I really would be interested how all this stuff does act while on stress settings (...like, you know, in Multiplayer...). The original libnoise example planet has 100+ modules...- That would be fun --- *Someone - sadly I forgot to write down his/her name - mentioned here in the forums a 'laptop cooling pad'. Best investment since buying this game! - So much thanks!!! ---- Edit: 07.01.'18: Typo right at the start. Arrgh.
Six Days Of Summer Spoiler: More pics! (Please disregard the odd game version number. For building this planet I used the latest experimental one. - My main version seems to be acting somewhat strange atm.) A young dwarf planet, travelling on a highly eccentric path around a dim star: Most of it's existence locked in flash-frozen oceans, and exposed to the asteroids of the outer regions... But once in a couple of hundred earth years, for some short, strange days, it's appearance will be dramatically altered - To become a veiled, boiling mess, and drawing a sparkling sash of ice. This is a very unstable world, that maybe some desperate empire would claim as a bridgehead, or a curious and/or thrill seeking culture wants to settle. The terrain is mostly flat, but with a very prominent mountain chain. + Large ice plains with complex trench systems. (Focus on orbit view) + Very diverse mountains: From flat and billowing to sharply ridged towers + Meteorite craters on mountain foothills Made as a test in terrain for using large 'Selector' edge falloff ranges as some kind of 'Blend' module. Stats: 26 modules used (real count) In-game map generation time: About 21 seconds (EGS 6.5.3) (Classic Omicron: ~1 s, MoonSekmet ~70 s) >Maybe not that suited for temperate planets. Spoiler: xml control points Mountain shapes: Ridged 8, Billow9 Mountain height: Select 12; input0 scale and bias sliders. Ice ridges zone width: Select 5; upbound/lowbound, edge falloff Ice ridges shape: Billow1 Crater size & distribution: Voronoi 16; freq, seed Activate before saving: Clamp 17 – I'm a little bit in a bind here: Xml planets are so small, that it seems you can either make the surface appealing, or the orbit view. – Sadly, rarely both. This planet would have great potential for SV trench races... If it could be scaled bigger. But just to widen the trench would cut the planet into half. - Well, maybe in EGS v. 8.0 ...? Also, since the deco distribution change, grass doesn't spawn correctly on .xml worlds. It's buried on altitude 0, limiting design choices to hostile worlds: Barren, icy, molten. -But then again, on those worlds there's more CPU power left for the terrain. How to apply custom terrain: >Please see first post of this thread; it has been updated.
Hi! Thanks! - It's very old tech.. Frankly, I don't know. Part of the code to use them should still be there in EGS. But the biome placement has changed a lot... and with it, the world's splat map- - -And testing this out, they now really seem to demand a splatmap... and throw a CoQ if they aren't there. (xml usually had generated those splats on the fly, so this is new) Copying in a dummy splat still gives a CoQ, even when using an old EGS legacy playfield. - Something in the formatting could have changed, too. Don't know if these worlds can be salvaged. (I'm missing a bit that kind-of puzzle, of building such worlds)
So i added a new planet like so: (In sector.yaml) Code: Coordinates: [150, 300, -45] SectorMapType: Planet Playfields: - ['0, 0, 0', Alpinia Planet, Alpinia, 'Human:1'] I created a new folder called "Alpinia Planet" in "template" folder and placed the downloaded playfield.yaml (no terrain.ecf?) I moved _Alpinia.xml to "Content/Terrain" folder When i load the saved game, i get this warning: And inmediatly after a NullReferenceException: Since TerrainGenerator tool isn't able to 'save as' dll i don't know what else i can do. Have they disabled custom terrain in alpha10?
For xml / dll terrain: Yes, very likely, that doesn't work anymore. -Sorry... Xml and dll terrain was computed by the CPU. Since the planets are all generated by heightmap now, it seems that at least the xml don't load properly. ... No. There are still ample ways to generate your own terrain. But not with xml modules anymore. Using 'stamps' now, with a much more fine-tuned way to place biomes. Basically, you start with a 'base terrain', and then modify that by defining where your biomes are, and then printing mountains and valleys on that.
Ok, thank you, could you answer one last question?: I've tried with the "Terrain:" property in playfield: Code: #Terrain: Name: <heightMapName?> PoleLevel: 9 PerlinCol: 2 ColorChange: YFadeCenter: 65 YFadeRange: 65 YFadeMin: -0.12 YFadeMax: -0.25 wich, how i understand it, enables to compute the following lines of "terrain.ecf": Code: Material Name: <heightMapName> SplatMap_1: <splatMap_1> SplatMap_2: <splatMap_2> SplatMap_3: <splatMap_3> ClusterScale: "20" It loads the custom heightMap correctly but when i try to land on the planet I have the "AllIsAbysm bug" (i can share a pic if you dont understand what i mean). I thinks it's because my splatmaps, wich i dont fully understand,are incorrectly made. what are each splatmap for?why in Alpha10 i need a third splatmap?
I can only guess. Please, show me! (Since I can't make any new xml terrain, this thread could be used for trying to reactivate them ) That's somewhat difficult to explain in a sentence... I'll try it as short as possible: - During the old xml days, terrain shape was calculated on the fly by your computers' CPU, using a complex formula. Such a CPU-generated world had a sub-program, a 'terrain shader', that determines the placement of surface textures, and generates e.g. the 'roughness' and gloss of a surface. That old shader could have a large number of terrain textures for the planet surface, since texture distribution was only defined by playfield height. - Then came the 'handcrafted', static heightmap planets. A heightmap is basically a greyscale picture - White is 'high terrain', and black is 'low terrain'. With that, the 'terrain shader' got changed, too. Now it could place textures regardless of height, but only a limted amount of textures, overall. Those heightmap planets had only 8? texture slots, that could be used for the planet surface. E.g. 'Stone', 'Sand', 'Grass'... The surface texture was basically 'painted' on top of the heightmap shape in a 3D program, and saved as a special kind of 'other' picture. That is, where those splatmaps come from. A splatmap is a picture with 4 colour channels: Red-Green-Blue-Transparency. Each channel of that picture describes the position of a surface texture 'pixel' on the planet, seen directly form above. 8 texture channels mean 2 splatmaps are needed. 12 tex channels mean 3 splatmaps. - The current procedural planets still use a heightmap: Made by a static base terrain, with randomly placed heightmap 'stamps'- static terrain snippets, merged together. The surface texture placement is now automated, too - -But since it is still heightmap terrain, the whole planets still uses only 12 possible textures for the surface. It's all what that terrain shader can take. As far as I can guess, EGS fails to connect those splatmaps to the 'CPU generated' xml terrain - Since the shader thinks that it should be at least a static, handcrafted terrain heightmap.
Yes. It 's what i mean: <If i move, "the abism" is expanded> I will share also the playfield.yaml and terrain.ecf. I can't understand this, if you can only have up to 12 textures with 3 splatmaps, why there are more than 12 textures declarated in terrain.ecf?
Thank you very much, i'm finally understanding eveything. I think my problem it's because i dont find any documentation about terrain.ecf. For example: Code: { Child 2 # SandBrown03 Name: "SandBrown03" Name2: "AlienGreen04" Brightness: "0.5" Saturation: "1" RGB: "(0.74, 1.02, 2.05)" AddCol: "0.24" Smoothness: "-0.39" ReliefStrength: "0.7" NormalStrength: "1.17" Interpolation: "0" GeoStrength: "0.18" DistanceResample: "0.45" NearScale: "0" DistantScale: "0" HeightOffset: "1" HeightContrast: "1" TerrainId: "37" TerrainId2: "11" UnderTerrainId: "66" } how do i know wich one of the three available splatMaps is he reading to apply this texture? the first one ?(and i guess so because it's child nº 2, is it correct?)
I did my own findings and yes, it's like so: Child 0 for red channel splatmap_1 Child 1 for green channed spatmap_1 Child 2 for blue channel splatmap_1 child 3 for alpha channael splatmap_1? child 4 for red channel splatmap_2 . . . And so on. I still cant fix the "AllIsAbysm" bug, even if i'm using heightmap and splatmaps already present in folder, are you sure custom terrain support have not been disabled for A10? It seems i will have to work with stamps if i want a working "custom" map.
I've had such holes, 1) when they changed the terrain engine for the distant terrain at some time in the past, and doing then the 'pf' command to reload the playfield, and 2) when I messed up my playfield somehow, and the terrain engine stumbled. (Sorry, can't remember what I did at that moment. Maybe a stamp was missing?) Not sure with this, either. Tried to import a heightmap into the SolarSystemGenerator a while ago, but that didn't work out, too. The game still has all 'old' data from the handpainted worlds. (in the \content\playfields\legacyPlayfields -folder are the playfields, and in content\terrains are the .raw terrain heightmaps and the .tga splatmaps. Maybe, heightmap terrain has to mimic the folder structure? At least that is data, that could still work. From that you edit in your own worlds.) 'Handpainted' Heightmap terrain could be limited to planet size: It has to be a 'size class: 2', probably? That was the only size class, at that time. - Stamp terrain works, but isn't handpainted, of course. A crazy, maybe-possible workaround would be to define your handpainted terrain as a huge stamp, and place that manually as a single special biome stamp. But all terrain of that can only go' up', not cut into the base terrain or water (that's a bug there).
I have been trying with size class 5. I assume it's the only possible size since SSG told me so. Since all heightMaps are 8192 x 4096 and SSG told me fixed terraisn only works on size class 5, i guess it is limited to planet size 5
Thanks - Was an interesting way to build worlds with... Sometimes I even miss it. It was more surprising and diverse, what you got as end result. (But by that, also much much harder to use, build a style with. And no way to create things like e.g. erosion.) (It was no code as shown in the video, 'just' connecting modules, within an editor)
