Page 2 of 2 FirstFirst 12
Results 26 to 42 of 42

Thread: We need a shovel

  1. #26
    Member
    Join Date
    Jul 2017
    Location
    UK
    Posts
    184
    Post Thanks / Like
    Slightly necroposting here but it's still relevant. Currently I tend to end up digging out the ground by accident when building or removing constructions or removing constructions when trying to dig out the ground. It's quite frustrating sometimes, a way to separate the two actions would be valuable. That and being able to fill them back in and create flattened 'road' areas would be useful as the wheeled craft can get stuck in places unable to transverse the hilly landscape (prior to making Airblades etc.).

  2. #27
    Developer
    Join Date
    Feb 2016
    Posts
    352
    Post Thanks / Like
    We know about problems with welding/digging. There is a possibility to split the tool into two, one for welding/cutting and the other for digging. We just don't know if we will not bring even more confusion with tool switching. So we are still trying to figure out some way how to mix both and allow doing it all with one tool without mistakes.


    About terrain manipulation: I haven't consulted it with our terrain guru yet, but I think that we could relative easily modify our voxel engine to allow an undo function - that will put back terrain that was once removed, in reverse order. Think about it like CTRL+Z in text editor. Then we should also restore missing grass and trees etc.

    What we cannot easily achieve is adding a terrain - for two main reasons:

    1. We have a procedural terrain generator, that generates terrain consisting of different materials according to some mathematical functions. Then we have a database of spherical holes, that you created by digging. It's just spheres defined by center and radius. When we generate a terrain, we combine this two information together - compute terrain and for each voxel look if there exists at least one hole in database. Then we convert it to a 3D mesh which we can render or generate a collider from.

    If we want to add terrain, we should create new data structure containing terrain additions. There should be position, radius and type of the added material. No problem until there. But what happens if you have two overlapping spheres, one that subtracts terrain and the other that adds? You cannot tell which one was earlier. Doing modifications in wrong order would lead to wrong results. So this means that we would also need to store the order in which modifications happened and reproduce them all in given order. Maybe it will be doable, but we think it could lead to big slowdown of whole engine, as you cannot simply add/subtract whole sphere. You have to go through all relevant spheres again and again for each voxel.

    2. Even if we could handle addition of terrain according to previous paragraph, it will be adding of spheres made of dirt. It will be nearly impossible to create flat ground with this.

    We have also considered another approach, like moving mesh vertices to level but it will be even harder for player to use and for computer to work with. Something that trained 3d artists do with specialized modeling software. And even this will probably not be usable for creating flat ground in larger range.

    There was another solution proposed - to create a block, similar to base ground block, but with grass texture. You'll be able to cover the holes with this flat block, but this is something you could also do now, just not with the same look. But this added ground would have different behavior than the regular one.


    Generally speaking, we consider adding terrain as a lot of work with many issues and just small benefit.

  3. #28
    Senior Member
    Join Date
    Aug 2017
    Posts
    629
    Post Thanks / Like
    Quote Originally Posted by martinsustek View Post
    We know about problems with welding/digging. There is a possibility to split the tool into two, one for welding/cutting and the other for digging. We just don't know if we will not bring even more confusion with tool switching.[...]
    People are familiar using different tools form other games.
    You have to apply the principle of separation of concerns to this multi-tool too

  4. #29
    Kickstarter Alpha Nomad
    Join Date
    Jul 2016
    Location
    UK
    Posts
    73
    Post Thanks / Like
    What about a simple undo function to revert any accidental divots to the procedural mesh. Like a kind of ctrl Z, that is all I want, something to undo accidental potholes.

    Terrain flattening is a whole different ball game which is not necessary when you can use floor panels. But potholes can be a real nuisance, the drill can go surprisingly deep in one cycle and vehicles and avatar do not navigate them easily, in fact on one occasion I flipped a buggy in an accidental pothole made while building it. If you could just put the tool over a spot and press undo it could take away the modification made.

    The only problem with that is eternal renewable ore deposits but if you zero the ore value in the revert then it would be fine

  5. #30
    Member
    Join Date
    Feb 2018
    Posts
    11
    Post Thanks / Like
    Quote Originally Posted by martinsustek View Post
    We know about problems with welding/digging. There is a possibility to split the tool into two, one for welding/cutting and the other for digging. We just don't know if we will not bring even more confusion with tool switching. So we are still trying to figure out some way how to mix both and allow doing it all with one tool without mistakes.
    There doesn't necessarily need to be a whole new tool, just a way to toggle the alt-function, as already mentioned. Holding Shift while clicking is a simple solution that, with the proper tutorial, will be simple for people to pick up on since it's commonly used in general computer interfacing. That, or usage of a hard-toggle that changes the tool's function, which would honestly be the best way to prevent the majority of the accidental diggings. However, the most ideal way to handle this would be to add both options, so that you can be in "Welding" mode, but shift+click to temporarily use the "Digging" function should you need to clear out some terrain.

    This could easily be expanded on as well, for the Digging tool, to provide use with a means of "world-generator" level of smoothing the terrain, instead of this hard-angle approach we're currently faced with. Which in all honesty, wouldn't even be a problem if the movement engine could handle them better than how it does, because at the moment if you R-Click remove a big hole, then try to make a nice gradual slope (or even flattened) with L-Click, your vehicle and legs still have a tough time traversing it. It seems odd that a user-made flat terrain surface will result in a slowdown while walking over it, or for your vehicle to bounce off it/be slowed down, when it's really no different than any other flat terrain that was generated naturally. So, to provide a Ctrl+Click Digging function that invokes a "Smoothing Brush" that sort of re-generates the terrain would be not only nice in a practical sense, but also let us make our builds look nicer.

    Quote Originally Posted by martinsustek View Post
    About terrain manipulation: I haven't consulted it with our terrain guru yet, but I think that we could relative easily modify our voxel engine to allow an undo function - that will put back terrain that was once removed, in reverse order. Think about it like CTRL+Z in text editor. Then we should also restore missing grass and trees etc.
    I just want to mention that I don't see this as being a solution and will ultimately only cause more problems, unless you are able to code in that the "undo" will replace the terrain with dirt. Otherwise what's to stop someone from just "cheating" by mining, obtaining the resources, converting them into what they need, and then undoing? Though, I suppose a solution would be to have it kept in memory as a limited-time undo, where if say more than 10sec has elapsed it is no longer possible.

    Quote Originally Posted by martinsustek View Post
    What we cannot easily achieve is adding a terrain - for two main reasons:

    1. We have a procedural terrain generator, that generates terrain consisting of different materials according to some mathematical functions. Then we have a database of spherical holes, that you created by digging. It's just spheres defined by center and radius. When we generate a terrain, we combine this two information together - compute terrain and for each voxel look if there exists at least one hole in database. Then we convert it to a 3D mesh which we can render or generate a collider from.

    If we want to add terrain, we should create new data structure containing terrain additions. There should be position, radius and type of the added material. No problem until there. But what happens if you have two overlapping spheres, one that subtracts terrain and the other that adds? You cannot tell which one was earlier. Doing modifications in wrong order would lead to wrong results. So this means that we would also need to store the order in which modifications happened and reproduce them all in given order. Maybe it will be doable, but we think it could lead to big slowdown of whole engine, as you cannot simply add/subtract whole sphere. You have to go through all relevant spheres again and again for each voxel.

    2. Even if we could handle addition of terrain according to previous paragraph, it will be adding of spheres made of dirt. It will be nearly impossible to create flat ground with this.

    We have also considered another approach, like moving mesh vertices to level but it will be even harder for player to use and for computer to work with. Something that trained 3d artists do with specialized modeling software. And even this will probably not be usable for creating flat ground in larger range.

    There was another solution proposed - to create a block, similar to base ground block, but with grass texture. You'll be able to cover the holes with this flat block, but this is something you could also do now, just not with the same look. But this added ground would have different behavior than the regular one.


    Generally speaking, we consider adding terrain as a lot of work with many issues and just small benefit.
    As an owner of a Plugin-based Minecraft server, I have to point you in the direction of the plugins called CoreProtect and WorldEdit relating to the tasks you're speaking of.
    CoreProtect logs everything that happens on a server into an SQL database (either MySQL or SQL Lite, the latter obviously being faster), and I do mean everything. It logs chats, commands, block additions, block removals, container additions, container removals, entity deaths, just to name the big things. It logs this all per user and in general (for example an entity falling to its death off a cliff), which in addition to that it lets you view the logs in game (output is via your personal chat screen). But that's not even the biggest part... it also lets you rollback changes based on action, person, time, and range, as well as with specifiers like pertaining to specific blocks or to exclude certain things. THIS is all done through a plugin that, basically, is done by folk decompiling Minecraft and doing hacky things with that code, so imagine what developers could manage!! This is all done asynchronously to the main processing thread(s), and amazingly enough, doesn't lag the game. My server's database is an unheard of 60GB in size as it spans the course of over 3 years. In my reading of comments, a lot of users experience Db corruption way way earlier, and is why the plugin offers a configurable purge duration so it only keeps data on events up until a certain point (something I've not bothered to do). I felt this is quite relevant given Minecraft is also a "voxel" game with a proceduraly generated (seed-based) world, albeit not even close to the level terrain-wise as Planet Nomads, but still important given the vast amount of voxels in play. Similarly, because it also uses an SQL Db, which you already (curiously) use for game the saves, so all the groundwork is already there in that regard. Perhaps the developer of CoreProtect could be a worthwhile acquisiition of CraneBalls? ;) Or at the least, a resource to collaborate with.
    WorldEdit does all those "advanced terrain editing" things, giving access to brushes, smoothing, advanced generation of things via algorithms well beyond my understanding (an example of something I came up with I'll paste at the end, albeit with no idea why or how it accomplishes what it does...). It can manipulate terrain large and small, use one block or many, in all sorts of definable ways. Most importantly, it lets you utilize Masks, to only effect certain blocks, in certain ways, and nothing else, leaving the rest as it is. That seems to be the issue you're referring to as you wouldn't want the tool affecting some things while it does it task. It'd actually be something that could, plausibly, be worked into your story line. I won't pretend to know where you are going with it or how much of it is cemented so far, but from what little of the datapads I've gathered and read, it has given me the impression of worlds created by other beings (reminiscent of Stargate: Universe, with the planet they discover that also has a giant obelisk on it, with zero other signs of technology anywhere on the planet). Therefore, the player being able to learn and create technology based on this knowledge, to allow them the ability to manipulate the terrain as a small fraction of the alien's power... well to me that sounds not only cool, but fitting for this game. Nevertheless, something else it provides which I saw mention of on I think your Dev Blog, was the ability to make Schematics of whatever you have selected. WorldEdit has a primary tool (a "wand", which uses the Wooden Axe) that lets you select 2 points via L and R clicks, and anything that falls within that selection cube is what you can edit, or copy, or cut, or paste into. If copying/cutting, you can also then create a schematic of whatever was in the selection, and save it as an external file that can then be shared with anyone else (Minecraft now has a very crude, but similar ability now built in, but no where near as elegant or powerful). This would provide people with the capability of sharing vehicles and bases with others, so in this context we'd only want to harness the mask, copy and schematic, to make it only copy the building blocks, not terrain, flora or fauna.
    FastAsyncWorldEdit is a plugin all its own, by a different developer, but its primary goal is just taking all of the WorldEdit calls and making them asynchronous as to eliminate the huge caveat WorldEdit has: giant amounts of lag when making large changes to the world. Often times doing really large tasks with WorldEdit will flat out cause the server to crash, but fairly large ones can still cause a condition where nothing is responsive and players ultimately are kicked due to timing out (thus, prompting us to announce a large change and to brace for lag). However, with "FAWE" it offloads everything to another thread and now we can work lag and crash-free. Again relevant because of all of what is simultaneously happening in Minecraft, making things more thread aware will help alleviate the impact on systems, the main difference being that Minecraft is singlethreaded despite all the things it has to compute (entities, crop growth, player movements, terrain generation, terrain manipulation, etc). Which is why I find it strange that Unity games run like crap on my Ryzen 1700X (8C/16T) system with 16GB RAM and a Radeon R9 390 8GB. PN utilizes what seems to be, all threads combined, a single core, leaving me to believe it isn't very thread aware and that all the divvying up of processing power is just handle by Windows. My point being that it's not a matter of implementing the changes we're requesting as being more than what user's computer can handle, it's just that the game needs to be told how to properly utilize our computers to the fullest.

    All in all what I'm getting at is that there are many similarities that can be drawn between Planet Nomads and Minecraft, and while PN is arguably way more intense in many ways, a Minecraft "Spigot" server (to use plugins, aka server-side mods that vanilla clients can still connect to) are given enough additional things to put it on par with PN on the level of "what all is being computed at any given time" when you factor in dozens of players all on at the same time. The main benefit here though, again, is you are the developers, so these "plugins" will have native access to everything and not need to be executed through hacky means (and by that I mean things like making horses fly, or bows shoot fireworks), giving you the best possible performance opportunities. You just need to better utilize the performance our computers have and more will become possible in turn The average gaming computer, capable on the video-card front, these days are going to have 4 real-core CPUs and that's quite a bit of horsepower to throw around! With AMD getting Intel's ass in gear thanks to Ryzen, you're going to see that average become 6 cores real soon, with even more Threads being available in addition (6 core Ryzens have 12 threads, as my 8 core has 16 threads).

    Anyways, that's my longwinded post. Hopefully it helps some...
    And I apologize for it coming across patronizing, but it's best to explain everything in detail and let you take away what's of use, than leave it and you be left to draw conclusions that aren't what was intended ;)

    - - - Updated - - -

    Dang, I forgot I was going to also suggest that at the end of the day, if terrain edits, smoothing, or undoing isn't possible, then perhaps that replacement route with blocks is still better than nothing, but with a change... It's a combination of two ideas previously mentioned, one being the "roads" and the other being "cover over holes with Base blocks".

    My suggestion is a bit two fold...
    First, that there be a Roads ability, but that it isn't a block, so much as a conversion of terrain. Visually it'd be like painting the terrain, converting the top layer into like concrete, which will have the added benefit of increased traction and maybe some increased vehicle speed (due to less rolling friction).
    Second, would be that buildable road slab, which I think would need to ideally be rectangular-rhombus shaped to allow for the ability to create curves, while still being able to create straight lines (with a bit of annoying work, but perhaps could be mitigated via an auto-rotating script?). My thinking is that in order for this to actually work, we'd need for JUST THIS BLOCK to have the option to rotate in 5-degree increments, instead of the standard 90-degree. If not that, then a means for the block to snap to the terrain's own gradient in order for terrain-hugging roads to be made.

    This would provide us with functional means to make roads that are actually something we'd want to use.

  6. #31
    Developer
    Join Date
    Feb 2016
    Posts
    352
    Post Thanks / Like
    Yes, Undo is meant to be just for case of accidentally deleted terrain, not for reverting half of the game or cheating resources. We could maybe make it cost the sources you acquired, and limit it only for some time or last move. But as we are developing a single-player game, we do not care much about hackers, as they can only spoil their own experience. Of course if would be better to solve the main cause, that lies in controls.


    Speaking about multithreading and optimizations - Whole Unity engine is single-threaded, we use a Thread-Ninja, which is kind of multithreaded asynchronous coroutines. But the amount of work, that could be done in background threads, is very limited as it could not use any functions from Unity API. We use it mainly for database writes, animals terrain navigation, and few other things. The core of the Sandy terrain engine is written as a C++ plugin and this is multithreaded code. But synchronization between multi- and single- core as well as marshalling data between C++ plugin and C# scripts also takes some time.

    Moving slow operations to background thread can save some lags, in expense of more complex code and necessity to synchronize things. But the main problem in low overall performance in the game is currently rendering, especially that part held on CPU side, physics computations and then few our Update scripts, the most annoying of them already moved to background threads.


    Back to terrain manipulations - our terrain is much more complex than just voxel/cubes. There's not a square grid or 3D array of cube blocks, but math functions that define the terrain on sphere and much other operations involved. I cannot currently see a simple way how to easily create big and flat surfaces on terrain. Maybe instead of digging small spheres deeply into terrain from player position would be digging flat segments that just slightly touch the terrain from top-down direction.

  7. #32
    Senior Member
    Join Date
    Aug 2017
    Posts
    629
    Post Thanks / Like
    Quote Originally Posted by martinsustek View Post
    [...] I cannot currently see a simple way how to easily create big and flat surfaces on terrain. Maybe instead of digging small spheres deeply into terrain from player position would be digging flat segments that just slightly touch the terrain from top-down direction.
    I see many requests from players to have flat terrain or a tool which do that.
    Indeed changing the sphere shape to a cube shape could offer this capability.

    This feature could be added to a device meant to be installed onto a vehicle. This would help create roads and tunneling through mountains.

  8. #33
    Developer
    Join Date
    Feb 2016
    Posts
    352
    Post Thanks / Like
    Yes, some kind of tunelling drill for vehicles is possible with current engine, but just for removing not adding a terrain.

  9. #34
    Member
    Join Date
    Feb 2018
    Posts
    11
    Post Thanks / Like
    Quote Originally Posted by martinsustek View Post
    Yes, Undo is meant to be just for case of accidentally deleted terrain, not for reverting half of the game or cheating resources. We could maybe make it cost the sources you acquired, and limit it only for some time or last move. But as we are developing a single-player game, we do not care much about hackers, as they can only spoil their own experience. Of course if would be better to solve the main cause, that lies in controls.


    Speaking about multithreading and optimizations - Whole Unity engine is single-threaded, we use a Thread-Ninja, which is kind of multithreaded asynchronous coroutines. But the amount of work, that could be done in background threads, is very limited as it could not use any functions from Unity API. We use it mainly for database writes, animals terrain navigation, and few other things. The core of the Sandy terrain engine is written as a C++ plugin and this is multithreaded code. But synchronization between multi- and single- core as well as marshalling data between C++ plugin and C# scripts also takes some time.

    Moving slow operations to background thread can save some lags, in expense of more complex code and necessity to synchronize things. But the main problem in low overall performance in the game is currently rendering, especially that part held on CPU side, physics computations and then few our Update scripts, the most annoying of them already moved to background threads.


    Back to terrain manipulations - our terrain is much more complex than just voxel/cubes. There's not a square grid or 3D array of cube blocks, but math functions that define the terrain on sphere and much other operations involved. I cannot currently see a simple way how to easily create big and flat surfaces on terrain. Maybe instead of digging small spheres deeply into terrain from player position would be digging flat segments that just slightly touch the terrain from top-down direction.
    Oh man, I knew Unity was initially focused as a Mobile Device engine, but I was not aware that it was so utterly limited on the PC side... SURELY there had to have been other, equally as cheap, and better engines out there that were suitable for PN? That's a damn shame though... but at least you guys/gals have mad an attempt at mitigating it, even if in a crude way. (I was actually really concerned initially when I saw SandyBridge.dll as I thought it was relating to the Intel CPU code name for the early Core i7 chips heh). Are the things like the SQL Database unable to be handled on their own thread simultaneously while the game's thread is doing what it needs to do, to prevent that dreaded save-pause?
    Also, and this is only in an effort to help -- not that you all probably haven't also scoured the internet already --, but here are a few things I was able to dig up that may assist in some way...
    http://www.richardmeredith.net/2017/...ing-for-unity/
    A quote from this page: https://snowhydra.wordpress.com/2016...ding-in-unity/
    "You could always do your asynchronous calculations on that new thread, then set your transforms or what have you to the new values once you’re done calculating it. This of course would only be useful for more complex situations–there’s no use for the majority of circumstances."
    Also, it seems like the Unity 2017 engine may help to alleviate some of the single-threadedness of the main engine, provided I understood some of its features correctly. I don't recall which version of the engine PN runs on, but I seem to remember a mention of trying to move to a newer version and it not panning out, but like v5.2 stick in my mind for some reason. That unfortunately means that in all likelihood moving PN to the 2017 engine won't really be a possibility :(

    Nevertheless, is what is talked about with offloading tasks to another thread to compute their values before sending it back to the main game thread, not something that could be done? Physics, for example, seems like a prime candidate for that. That is, assuming it isn't already being offloaded in that way...

    Now assuming all of this is already being done on your end and we're already seeing the maximum performance we can get from Unity in this regard... Both the DirectX 12 and Vulkan (OpenGL) APIs are considered to be a 'close to the metal' API and could do away with some overhead, allowing for some addition performance to be had, so that being said, how possible then would it be to give PN support for DX12 and/or Vulkan?

    Similarly, if we're looking to squeeze out every bit of performance that we can, then perhaps utilizing OpenCL (aka Compute Shaders) for some of the computations would be a smart idea (again, providing Unity will allow GPGPU work to be used in this way.)


    As far as offering the option for either allowing the ability to snap a platform to the angle of the terrain, OR to give us finer rotation of them in order to build "roads" or some sort, where does CraneBalls stand on that currently?


    Regarding a tunnel boring rig for vehicles, that'd be cool. For a laugh I had once rotated the beacon and strapped it to the top of my big vehicles, which is exactly what came to my mind when I drove around with it "Man how great would it be if this actually punched a hole in terrain!". However, it'd definitely need to be something that is toggled On/Off, so that we don't, again, accidentally start boring through terrain that we didn't quite mean to. Similarly, we'd need some sort of cockpit control for aiming it. It'd probably work best if it could be asigned to the mouse, so that we had finer control over it. Yet, even if it could be bound to the steering keys, that MIGHT suffice. Only issue I see there then would be to do with pivoting it Up/Down, which again lends to why the mouse would be idea. Basically it'd be limited to the exact same range that we have now with the looking system, to prevent us from tunnel 90deg to the side. :P

  10. #35
    Developer
    Join Date
    Feb 2016
    Posts
    352
    Post Thanks / Like
    There are different PC configurations, and if performance is not enough, some of them might be CPU-bound and some GPU-bound, also depending on quality settings. Offloading things from the main tread should help in CPU-bound cases. But as I've seen it, most of the time spent on CPU is rendering, physics and some internal unity processes.

    We are using Unity 5.4 currently. I am not sure if Unity 2017 is any better now, but last time we switched to 2017 we expected free performance benefit, but instead it was overall approx. 10 FPS worse on our testing machines and was forced to revert our project back. Maybe switching should be conducted with some rework of our code to gain a better performance. But we did not have a time for this.

    Using multithreading is possible in Unity/C#, but not with Unity API calls, as stated in articles you've mentioned. We use asynchronous accesses to database, but switching between main and background thread costs a frame, so sometime it's better to do things in main thread instead of: getting values in main thread, waiting for background thread, computing something, waiting for main thread, using computed values in main thread. Also using asynchronous functions in interactive code is a little bit problematic. For example you call function to digg into terrain and never know, if modified terrain gets back in next frame or 5 frames later..

    I'll test if DX12 have some performance benefit.

  11. #36
    Developer
    Join Date
    Feb 2016
    Posts
    352
    Post Thanks / Like
    Quick test showed, that DX12 is the same FPS on low settings, and 15-30% worse on higher settings.

  12. #37
    Member
    Join Date
    Feb 2018
    Posts
    11
    Post Thanks / Like
    I appreciate taking the time to not just read my lengthy messages, but also to respond with detail!

    That being said, does Unity allow for a menu-item that would give the choice for which graphics API to utilize, so that we're able to pick ourselves? If so, then I think it'd be really beneficial to offer that choice...

    If not, if it is it possible to offer up an optional download of the files that have DX12, and/or simply include them with the Steam download alongside the current (DX11) compiled PN? I can't imagine it being too much more than just an EXE and a few DLLs, and so one could either put the EXE in its own folder, or just call it "PlanetNomads_DX12.exe" and have it sit right next to "PlanetNomads.exe". As far as Steam is concerned, launching it wouldn't change for the typical user. I'd personally be happy to test it and provide at least one true real-world end user data point

    If there is a genuine drop in performance on other's system, I can't help but wonder if that could come down to still using DX11 code, and if the same "calls" (I think they're called) in DX12 simply need a couple extra lines in each shader in order for DirectX to actually be able to utilize the DX12 features (instead of just falling back to "Legacy" DX11 routines).

    Also, is there a command line argument that I can run PN with in order to see FPS? I always prefer in-engine methods, as external ones like FRAPS or the ones in programs like MSI Afterburner, always result in a considerable hit to performance (sometimes up to 10FPS. I see that the Unity Builder apparently has one, but that doesn't do the players much good :P I did come across this, though it seems so simple that I can't help but think it is an "always displayed" counter, instead of being toggled...

    Anyways, thanks again!

  13. #38
    Developer
    Join Date
    Feb 2016
    Posts
    352
    Post Thanks / Like
    As I know, there is no possibility to change graphics API at runtime, but you can try using command line parameters -force-d3d9, -force-d3d11 or -force-d3d12 also -force-gles32 etc. I've tried it again on ultra settings and d3d9 didn't work at all (was ping screen), d3d11 had 24 FPS and d3d12 26 FPS. So maybe it could help you a little bit.

    To see FPS you can use our console (shift+f1) command "fps" (without quotes). It is averaged from update delta times, so it might show different values than other tools.

  14. #39
    Senior Member
    Join Date
    Aug 2017
    Posts
    629
    Post Thanks / Like
    Quote Originally Posted by Menzagitat View Post
    I see many requests from players to have flat terrain or a tool which do that.
    Indeed changing the sphere shape to a cube shape could offer this capability.

    This feature could be added to a device meant to be installed onto a vehicle. This would help create roads and tunneling through mountains.
    Quote Originally Posted by martinsustek View Post
    Yes, some kind of tunelling drill for vehicles is possible with current engine, but just for removing not adding a terrain.
    One more thread from Steam:
    http://steamcommunity.com/app/504050...3255129985656/

    - - - Updated - - -

    Quote Originally Posted by martinsustek View Post
    Yes, Undo is meant to be just for case of accidentally deleted terrain, not for reverting half of the game or cheating resources. We could maybe make it cost the sources you acquired, and limit it only for some time or last move. But as we are developing a single-player game, we do not care much about hackers, as they can only spoil their own experience. Of course if would be better to solve the main cause, that lies in controls.
    ...
    The undo of the last hole would improve the "quality of life" of players. I made such a hole too by accident this weekend :(

  15. #40
    Senior Member Vrmithrax's Avatar
    Join Date
    Sep 2016
    Location
    Oregon
    Posts
    465
    Post Thanks / Like
    I would actually love to see a physical toggle required to switch between build mode and dig mode. That way you could never accidentally miss a block and make a hole, or miss when digging and deconstruct a block instead. Won't solve all of the hole issues, but it would certainly help reduce how many times we need a shovel!

  16. #41
    Member
    Join Date
    Mar 2018
    Posts
    1
    Post Thanks / Like
    Just shooting out a thought, but as a simple mechanism, couldn't you just have an auto-increment value on each sphere, along with an indication of add/remove, as a form of simple timestamp. Then all you need to do is process them in numeric order and your order of adding/removing will be done properly. And as an optimization, if the newer sphere completely envelopes another, you remove the previous one.

    -System Error

  17. #42
    Member
    Join Date
    Aug 2017
    Posts
    101
    Post Thanks / Like
    Wow this thread has grown since I was here last. I've started playing again as time permits.

    I've been over to Steam, posting there.
    https://steamcommunity.com/app/50405...scn=1540415778

    I had to add my 2 cents in here.
    SysErr, I was thinking the same thing on the auto increment, but I think it would take too long to roll through all the changes. The last change in should override the rest.
    And it could have the potential to get huge.

    martinsustek, thank you for your replies and allowing us to have some insight on what you guys have accomplished. You mentioned the undo function allowing the player to cheat resources. If it does, then it does. This is not (sadly) a multiplayer game, so if the person cheats, he only cheats himself/herself. That said I don't play MMP's but a co-op version would be a neat way to get your friends to buy the game.

    Vrmithrax, not this is a cool idea. I'd get behind having a no terrain mod switch in a second. I build everything on a platform just for the purpose of not having my front yard fill of holes. Empyrion has a different tool for drilling then welding so that could work too. Or you could replace that useless gun with it. That gun really lacks, I'm so sorry developers... I had to say it. One of the neat things about PN is it's not a shoot-em-up.

    Formula350, Unity is not limited on the PC side by any means. (No, I'm not a Unity fanboy, I'm a old developer) Go look at some of the things other developers have been able to pull off with Unity. It's amazing.
    The trouble with PN is in the current implementation of Unity. This is not a bad thing, i.e. I'm not saying the developers are wrong. Not in the least. What they accomplished in this game in the short amount of time is truly cool.

    I'm saying things like optimization is not built into the game. We used to do it by limiting the area the engine could see. I haven't looked into this in a few years.
    Unity has a built in terrain generator, that while good for a quick game, it's not designed for lone term use. I'm glad to see the developers wrote their own.

    I don't know how the Empyrion team did their terrain editing but it's the best I've played. (next to Astroneer, which is a totally different animal).

    I've done a lot of work with the Unreal engine way back.. never-mind, but Unity is truly a cool project. The team has been keeping it up to date. Heck, the demo army game that you get when you download the engine (it's free by the way) is great. You get to see in the editor, how much it takes to create a first/third person camera and player. For the animation alone, I'd never make a third player game lol, too much animation work.

    I've stopped making games on the side and started web development full time. It's a nice way to end your career, but I miss the cool stuff. I don't make websites, I make widgets to display data from SQL Server.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •