Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
5 
Report this post
Do you plan to add even more features?
Yes. The feature I want the most is something to merge Grids - it will take some time until I figure out how to do it, but it's doable once you understand how a "Machine" is defined on the database!
Thanks!
https://steamcommunity.com/app/504050/discussions/0/2646361461398130957/
Have fun :)
When hope is lost...
https://steamcommunity.com/app/504050/discussions/0/1644292549029298560/
... somebody found me on the planet
https://steamcommunity.com/app/504050/discussions/0/1644292549034604500/
The hope was that maybe the developers change their mind and add the feature.
I tried to convince them even before they started to create the blueprint system but they decided against it. And initially was their own idea to do that :(
https://www.planet-nomads.com/2017/12/21/last-dispatch-of-2017-whats-coming-in-2018/
But without limitation, a huge grid could be created fast, which would also render it useless. I've seen very large ships which due to their size would reduce the FPS to 1.
I think they should have limited the grid size instead of not adding the feature.
Ah, so you are the one! Kudos, man! You are one of my sources of inspiration!
Having the tool monitoring the savegames and applying it automatically is a hell of a good idea, by the way…
Found this one on youtube, but not the thread - now things are way more clearer to me! Nice hack!
I was wondering how you managed to inject code on the game in order to make a "follow me" vessel, but now I see you was way more smart than that. (I'm a programmer, I always think in terms of code first!!).
Yep, I agree. Having some kind of "copy & paste" would had made my life way easier. It's essentially what drove me to look for a tool to do that, found yours, then found black-silence's Savegame Editor, and now we are where we are.
2019 was a tough year for them, I think… I have the feeling that the game was somewhat hurried up and then kicked trough the doors, and they had to do their best with the (scarce) resources at hand. Well, we all know the history…
I glad they didn't limited anything, because here are my dirtiest secret: most of the limitations of Unity games are due Unity's stupidity, not due the programmer's code or hardware limitations.
Try this stunt: the a environment variable called "MONO_THREADS_PER_CPU" to "1" and then run Planet Nomads. You will notice a slightly better framerate (more noticeable on potatoes lime my MacMini 6,2), as well you will be able to build way larger machines now.
A long, detailed and gory explanation for this can be found here[ksp.lisias.net] where I explain why this MONO_THREADS_PER_CPU stunt works.
I was trying to tell people that the physics problems are caused by the PhysX made by Nvidia not by Unity but eventually I did a small test on Trailmakers and I've seen they solved some problems in a more robust way. I have not played much that game so maybe they limited the grid sizes too?
I'll try MONO_THREADS_PER_CPU later during the year if I start the game.
I was myself surprised too watching my video, to see that I even have a UI.
I stopped working on that in that stage (after I had to reinstall my windows) and I do not know what problems I meant there are still needed to be solved.
So if you want to have fun and discover things and make a nice tool, keep doing it!
What I was hoping to make if I continue was
- the ability to dig a tunnel using the large beacon as if the laser did it.
- to place player made blueprints on the surface of the planet, maybe randomly, from the list of blueprints the player made or subscribed to.
I've seen only one modder contacting Craneballs but they kept the distance not knowing what advantage it would bring to them to keep him around.
I had my share of blaming developers when in fact I should had blamed Unity at first place, but then I saw the Light and, well… l learnt enough about Unity to avoid it as it was the plague. I will not tell you I'm boycotting it because there're good games made on it around, but, dude, I think the game industry should start to fight back and collect some damages. Developers are losing money because of it.
I didn't knew about Trailmakers. I'm unsure I will have time to try it int he short future, but I will add it to my wish list.
The tunnel digging is already work in progress!! Do you read minds???
What I thought is not exactly as what you are describing, I'm planning to implement it using "commands" instead. You place a "command beacon" where you want to start the tunnel, another one where you want it to end, and then use the tool. It's pretty simple once you understand how holes are dug - essentially drawing a Bresenham's line but doing inserts into the database instead of plotting pixels on framebuffer!
Your approach is less "hackish", however. But I would need to understand how the multi-tool modules work, then learn how to remotely activate a Beacon (as you can't equip them), find a way to limit the extension of the digging (otherwise you would dig a hole trough the center of the planet… hum…. ideas…), etc.
About the blueprints… Dude, nice idea! I'm thinking about creating commands to "plant" trees and to relocate nests too. My problem is finding a way to do that without "cheating"…
Undigging holes can be abused to infinitely mine resources with the MultiTool - you dig the hole, collect the ore, then refill the hole and start again. When I screw up my digging while building my subterranean bases, I throw away any "illegal" resource I collect after using the tool, but I would like to avoid the hassle by just eliminating the ore form the refilled holes. Places exhausted by the Mining Machine are not affected by the tool, by the way,
In a way or another, I opened the issue tracking[github.com]. Thanks for the tips!
I don't care about the engine wars. :)
But yes, it is outrageous to work on an "engine" and not be reliant and optimized.
Was the same idea, but having just one block, the laser pointing the direction.
Your way is easier by having both coordinates provided by two small beacons.
Definitely I was not thinking to anything related to the multi-tool.
The plants and nests are world seed related. I've seen no coordinates related to them.
Humm… So removing a tree is another "modification"? Being so, I can only restore the gone ones, but would never be allowed to instantiate new ones without modding the code itself with Reflection or something…
The game must store somewhere such "modifications". Some research time is on the way...
Nope, harvesting trees are not terrain neither grass modifications. They are something else…
The reason why this happens is that the grass is a generic asset used everywhere while the trees look each of them unique and biome dependent. They optimized them for some reason. The placement is definitely random so that seed calculates the coordinates as you load chunks instead of loading them from the database.
Players complained forever that loading the vegetation the vegetation is slow.
They even had/have the behavior that the far low detail vegetation is shown and only after you approach, the database state of being cut is taken into account.
Maybe was an optimization of performance reason rather than database size. Or a hack if the algorithm was implemented by a different developer than the original one who created the "sandy" engine in C++, as they called it. Anyway, the vegetation was present when they came to Steam in Early Access so I assume the original developer was still around. Later they were afraid to fix rare crashes related to that code.
Is the vegetation loading better with MONO_THREADS_PER_CPU=1?
Yes, I just found it. "detail_chunk" is the one. At least some objects in game, as the animal's nest and trees, "live" on a chunk as you said, and has an idObject inside that chunk.
When the game loads, everything is generated using the seed, and so the generation is deterministic every game load, so everything is instantiated exactly equal as the last time.
The "terrain_modifications" table is a list of destructions on the terrain.
The "grass_modifications" table is a list of destructions on the grass.
The "detail_chunk" is a list of modifications (not only destruction) for some objects, I had confirmed animal's nests and trees until this moment.
When you change an object, it earns an entry on the "detail_chunk" using its idChunk (where it lives) and its idObject (its internal identifier on that chunk). These modifications have three attributes: "isDestroyed", "modifier" and "stringData".
"modifier" was never used on my savegames, and "stringData" is some opaque data serialized. We will never decrypt it without reverse engineering the code, but these stringData appears to be always the same for some situations, so it's feasible to make a lookup table with some black box testing and monitoring the database after each change. sqlite3's dump and kdiff to the rescue!
The interesting attribute is "isDestroyed" and it's exactly what it says - it tells the engine to delete the object after the chunk is loaded into memory. However, blindly setting this attribute to 0 would not be enough, because some objects also has a state stored on the "stringData". Tree stumps have "0-0_0;" on it. Anima's nests have something starting with "NestDataStart". All the other values are still unknown at this moment.
On a new game, the "detail_chunk" has some deleted objects by default. The game removes animal's nests near the Escape Pod, and some other things I still didn't identified.
Interesting, when you cut down a tree, it's idChunk and idObject are inserted on the "detail_chunk" table with the stringData "0-0_0;" and "isDestroyed" as 0. The fallen tree is still a GameObject, but it's not persisted - if you save the game and reload it, you will have the stump, but the fallen tree will be gone. This suggests that it's feasible to inject code on the game to keep a separate table for "custom" trees, once someone incepts a modding library for PN.
Interesting enough, I can think on a new "game mode" that I'm calling "Suicidal"
And then apply the "Unlock all recipes" cheat, as well some stacks of basic resources as water, food and medicines.
It will be you, your mk1 multitool and whatever you have on your pockets against a pristine, absolutely tech-less world. There will be no way to do any quest, as there will be no containers with datapads - but staying alive will be the challenge, as you will not have the Escape Pod (or anything else!) around.
Yep, it's annoying. If you are flying at 70 KM/h, you will be travelling faster than the game is able to load the chunk you are transitioning into. I think that nowadays, where computers with 16GB ram is becoming the norm, the game should preload at least 2 chunks ahead and keep them in memory, so any load will happen with chunks still not visible to the Camera. This would solve the problem with the engine at it is now.
I'm betting the sluggish is due using SQL as storage. Doing queries on a database (even a light db as sqlite) will always be some orders of magnitude slower than just looking from HashMap in memory. I'm meaning… thousands of times slower, it's really that bad.
Or both. And yeah, I agree that whoever did the chunk transitioning, was not the C++ dude. He would not have made the (apparent) mistake of doing SQL queries while transitioning between chunks.
No. The MONO_* stunt will make the whole machine to behave better. You will get slightly more consistent and faster framerates on Potatoes, you will be able to build more and bigger machines, things like that. But the main benefit will be that the game will not clog the CPU, allowing the C# runtime to do proper garbage collection and even allowing you to watch youtube on a second monitor while playing PN.
The sluggish vegetation loading is due I/O being done over a SQL connector when transitioning between chunks. Even with the database in memory, you will have to compile and execute queries to access the data.