Results 1 to 23 of 23

Thread: Some suggestions

  1. #1
    Member Gabiz's Avatar
    Join Date
    Mar 2018
    Location
    Riga, Latvia
    Posts
    4
    Post Thanks / Like

    Some suggestions

    Hi, some my suggestions for game improvement.


    Containers.

    In the following image we can see size and capacity dissonance:

    current_container_sizes.jpg

    We have Compact Container (12 slots) and Large Container (120 slots). If we compare dimensions of Large Container and 10 Compact Containers difference dimension with the same capacity is about 10 times. If we use Compact Containers in proportions of Large Container we are getting ~2100 slots capacity.
    So, what if we had a balanced (relative to Compact Container) and various sizes of containers e.g. 12 (200kg), 60 (1000kg), 120 (2000kg), 360 (6000kg), x-count of slots?

    container_sizes.jpg

    And what if we leave in the past slots/stacks idea and change containers capacity to weight or units and nice lists?
    As an example Compact Containers capacity is 12 slots x 90 items in the stack = 1080 units, let`s round it to1000.. No stacks, just items list + count ordered and customizable. Drag and Shift Click to moves items between containers, Ctrl Click pops up dialog, e.g. 10>100>ALL. Something like that.


    Next suggestion is a complex of:

    • remove "built-in" containers from all devices which have Conveyor connectors (of cause Compacts without changes) - easer to organize containers view, less to show, less to compute;
    • add one way Conveyor (with >>> sign on it) which passes items in one direction - since devices have two conveyor connectors this will help to split storage for resources>end products, e.g. miner>container (resources)>printer>container (end or mid product)>other printer/refinery>container (end product). At the moment 'conveyed' storage management is ^@%$;
    • not so important but would be nice to add feature to show connected containers/devices (production pipeline) by clicking on the conveyor or under "Setup[C]" - debugging, planning production network;
    • not sure if this is very usable but maybe - items filters/routers, route different items into the different containers/devices;




    Greenhouses.

    First of all change production for greenhouses (Medium Greenhouse) - produce (at least) 2 seeds from fruitage/herbs. Now 1:1 seed<>fruitage/herb is pointless.

    One of the ways to make greenhouses "usable":

    Medium Greenhouse produces fruitage/herb to (at least) 2 seeds and one seed to fruitage/herb >> requires seed, water, biomass (since this is a small ecosystem) will produce fruitage or herb.

    Large Greenhouse << remove fruitage/herb to seed(s) to force need for Medium Greenhouse and leave only >> plant seed once then continuously (it`s a large greenhouse) produce Fruitage or Herb, or Biomass (this would be nice to create closed circle production) - requirements (to make it more expensive maybe Cleaned) Water. Changing production requires replant new seed.
    Add biomass as crafting requirements for both greenhouses to somehow compensate biomass production.


    Maps:

    • Change showing POIs on the Map from switchable (one type or all) to togglable for each type (linked to compass);
    • Add togglable for My POIs types (A,B,C,D,E,F,G) - e.g. am using A for waypoints and while traveling I want to see only "A" POIs..;
    • Add My POIs icons;
    • Add coloring for biomes to the (scanned) Map;
    • Add minimap. 2km coverage turned to movement direction (showed POIs linked to Map settings);

    [added]
    Add posibility to add temporary markers/waypoints on the map which appears in compass to make a traveling to the unexplored areas easer..



    Radar:

    • Powered Radar on the moving transport scans/updates map continuously (otherwise why it is turning);
    • Radar scans also in the already scanned location and updates scanned radius (if am on the edge of the scanned location why I can`t scan?);


    [added]
    Make resources weins not so common and add to the Radar feature to scan for resource weins, separate (not saved) map in Radar (2km or less)..


    Transport.

    Add some speed boost by pressing Shift.


    Energy.

    At the moment for me Uranium Generator seems not very useful...
    What if make Uranium Generator (maybe add one more, bigger) much heavier and more productive (dedicate for bases) but Deuterium leave for transports (add Medium one then we will have: Small > Medium > and simple one or rename it to Advanced/Huge/Big...)?


    Gameplay.

    Maybe add some wondering around packs of animals which eventually attacks bases/transports... maybe some disasters. We have a rain and storm, what is storm will damage buildings etc...?


    Producers.

    Change values of producing items count icons: < / > = 10, << / >> = 100, and please add infinite button.
    Last edited by Gabiz; 20-03-2018 at 11:25 AM.

  2. #2
    Senior Member DaFuzz's Avatar
    Join Date
    Jun 2017
    Posts
    251
    Post Thanks / Like
    Hi Gabiz.

    That was quite a read and love the way you are thinking.
    I'm not the expert on Planet nomads, but I am very active siince the may 2017, so I hope I can contribute to your suggestions.

    Containers

    I agree completely with you that the large container looks like a big metal box with very thick walls if you compare it with the small container.
    This could be solved with your suggestion with the 4 containers you have drawn, so I would love to see this implemented or adjusted.
    Right now, the large containers are primarily interesting for bases and to create a large amount of storage space real fast.
    But for vehicles it is indeed a lot more interesting to create 10 small containers instead of 1 large container to achieve the same amount of storage space.

    Not sure how Craneballs will respond to that, but definitely worth mentioning, because the logic's seem to be missing on this part.

    Greenhouses

    I like your idea to make all the machine necessary by removing the products from the bigger counter parts.
    This does not only apply to the green houses, but also to the armory (compact and medium)
    Because once I'm capable of building a medium armory or green house, I don't ever build the smaller counterparts any more, since they became obsolete.
    Nice thinking

    Maps

    There are already a lot of suggestions for the map and most of your suggestions have already been posted before.
    The tomtom part was already suggested by myself and it is in consideration, so this will probably just take time to be implemented.
    I'm not sure how the POI's filtering would improve my game play, since I'm not that bothered with the small amount of information that hovers around me in the radar within 2K from me.
    I do think that the coloring for the different biomes will help nomads to find what they need somewhat easier.
    I also think that the map would start to look more impressive and colorful with different biomes highlighted on the map.
    the minimap was also suggested by me in another thread, where I suggested to implement the minimap on one of the monitors in a vehicle.
    It could be made so that it needs a radar to work properly and maybe some other device that links the radar to the screen in the vehicle to make it work.

    So good point

    Radar

    I haven't been playing around with the radar much, but I must admit that it's not very practical that the radar cannot be set to active scanning.
    Neither is it very practical that you really have to place the center of the radar outside a scanned area to be able to scan again.
    So it would be nice if this could be adjusted.

    Just a little extra brainstorming.
    Maybe it is possible to create two different kinds of radars, one for the map and one for the resources.
    The map radar could be build on a vehicle to scout the planet, while the resource radar would be a stationary radar and scans only for minerals.
    So the resource radar has to be build on a base, otherwise it would not give the correct information or no information at all.
    Not sure how difficult this is to implement though.

    I'm not so sure what you mean with the speed boost under transport and I'm not doing much with energy, because I'm building lots and lots of solar panels and batteries, so I'm not going to comment on these two topics.

    Gameplay

    the wondering packs of animals that may attack bases when aggravated are already in the pipeline to be implemented.
    I can only assume that this part of gameplay reveals some very annoying issues for craneballs and that's why it's probably taking somewhat longer then planned.
    However Craneballs themselves admit that the game is currently way to easy to play and the danger they had in mind is not yet implemented as they would like to see.
    So only tip I have here is to be patient and keep an eye on the roadmap 2018

    https://www.planet-nomads.com/2018/0...dmap-for-2018/

    the same applies to the weather, be prepared that the weather conditions will become very hostile in the near future and that there will be times that you will have to run for cover in case of extreme weather.

    I hope this gives you some answers on some of your topics and the other topics, nice thinking
    Why on earth would someone spent all his time in life being a little bit creative, when you can go all the way?

  3. #3
    Senior Member
    Join Date
    Jul 2017
    Location
    USA
    Posts
    407
    Post Thanks / Like
    I hoping the Large Container extra size will make sense when they figure out how to make it a smart container, with auto-sorting and such. I would love it if could have one for ore only and another for parts, and/or fuel.


    Seeds should not be grown, instead we should get seeds when we dry fruit or eat fruit.


    Producers.
    I would like,
    >> = 900 (10-stacks)
    CTRL+>> = 10
    Alt+>> = 90 (1-stack)

  4. #4
    Senior Member Vrmithrax's Avatar
    Join Date
    Sep 2016
    Location
    Oregon
    Posts
    465
    Post Thanks / Like
    The large container volume has always sort of baffled me. Yes, it can be more convenient to build one big container sometimes, but for the actual physical volume when compared to the smaller containers, the large container should hold far more than an identical volume of small containers, in theory. Looking at it logically, for each small container you have the physical structure and hardened casing that takes up a specific amount of the total volume of the total container size, which could be substantial (up to 20% I'd guess). That's up to 20% of the volume per small container that is unusable. The large container will also have a set amount of volume taken up by internal structure and the external plating, but it would be a much smaller fraction of the overall volume to achieve the same external plating thickness. Even if it's roughly double the thickness of plating on the large container, it's still a much smaller overall percentage of the geometric volume of the total container. So it seems weird that the large container holds so much less than a comparable sized array of small containers.

  5. #5
    Senior Member
    Join Date
    Jul 2017
    Location
    USA
    Posts
    407
    Post Thanks / Like

  6. #6
    Member Gabiz's Avatar
    Join Date
    Mar 2018
    Location
    Riga, Latvia
    Posts
    4
    Post Thanks / Like
    Update.

    Containers - maybe it will make more sense if hard connected (connector to connector not with conveyor) containers would showed (pooled, calculated) as one. In this case containers become modular.
    P.S. For me is a pain to open container in conveyored system, each devices built-in containers, small, big, all is pooled, calculated, items stacked and this action is always lagging.

    Radar - for now I can travel around, place radar, scan, destroy and repeat this every 2km or do the same with the "mobile" version of radar and the scaned map will be saved. One radar can "cover" whole planet.
    More logically woud be if scaned map will be showed only where radar is placed, powered and turned on. If radar goes offline map won`t be shown. I woud suggest that the all POI`s also must be discoverable and seenable only with radar (maybe except of personal beacons).
    With such radar behavior if we want to see a map we must build radars around the planet, power them and keep them runing. This will definitely make the radar more desirable.

  7. #7
    Member Cypher091's Avatar
    Join Date
    Feb 2018
    Posts
    27
    Post Thanks / Like
    I saw it as large container was less slots but less weight, good for flying vehicles.
    small container had more slot but a lot more weight so good for base building.

    removing the 'builtin' storage on machines, I'd say not a fan. Early game i can make a machine have use it and have a tiny amount of storage, and late game i can go to said machine and open it with no lag and craft up what parts i need and get those parts from the machine instead of opening my storage system which lags like trying to play online with dial-up XD. With a check box to continuously produce a selected item could make a nice little factory, but with the use of shift and alt for the item production count selectors i don't think they need the be changed.

    One way conveyor oh yes please. But would like to see the option added to it to actively pull items through it, so when i come back from a mining haul i can connect my rover to the base and have all the ore pulled out auto-magically.

    Greenhouse yes, would give me a reason to use the large green house. :\

    Radar, really i don't see the point to the radar as it is, if it showed ore deposits or something then maybe, but as is just showing the map. Just remove it and show the whole map. I just been using it as a decoration item watch the dish spin and spin @.@.

    Energy once you get deuterium other form of power are kind of pointless, though admittedly I had the tech tree done already so not sure how the tech path would play out. Also I tend to have WAY more uranium then I do deuterium fuel cells so for me i make a few uranium generator just as a fuel dump spot. :P
    Last edited by Cypher091; 24-03-2018 at 12:33 AM.

  8. #8
    Member
    Join Date
    Nov 2017
    Posts
    68
    Post Thanks / Like
    Either the large container should be much lighter or it should offer three times more storage, I of course would like the former, but only after the 90 unit stacks are only used with the backpack and the machines. All connected storage containers on the same grid should just refer to the same table as that would minimize the background processing to a minimum when machines try to figure out where to get raw materials and where to output the produced goods.

  9. #9
    Member bigdadda06's Avatar
    Join Date
    Feb 2018
    Location
    Australia
    Posts
    119
    Post Thanks / Like
    there is a usually a delay in opening a container with a large amount of other containers attached.

    Has anyone done any testing to see if there is any speed difference between using the large container and the compact containers with the same amount of slots?
    It probably doesn't make a difference, but you never know.

  10. #10
    Senior Member DaFuzz's Avatar
    Join Date
    Jun 2017
    Posts
    251
    Post Thanks / Like
    Quote Originally Posted by bigdadda06 View Post
    there is a usually a delay in opening a container with a large amount of other containers attached.

    Has anyone done any testing to see if there is any speed difference between using the large container and the compact containers with the same amount of slots?
    It probably doesn't make a difference, but you never know.
    Yeah, I notice this as well.
    In my main base, I have 3 large containers connected to a bunch of medium printers, medium armories, and miners.
    All connected to with conveyors and once I open a large container, my computer goes in overtime to see what's in them.

    But I think it's best to complain about the performance of the containers and conveyors in the alpha bug thread.
    This thread is about ideas and new input
    Why on earth would someone spent all his time in life being a little bit creative, when you can go all the way?

  11. #11
    Member
    Join Date
    Nov 2017
    Posts
    68
    Post Thanks / Like
    One possible reason for the delays may come from having multiple loops with the conveyor ports, so by merging connected containers to a single array the conveyor connections between storage containers would only need to be verified when a conveyor or container is added or removed, otherwise all interactions with the connected containers would just link to the same array.

    Also there would be no need to waste processing time for selecting from what container and which slot a resource is taken or added as the different resource types are indexed in the array, so a machine connected to a such storage system would only need to check if the field for index number x is not empty or if the array is not full.

    Of course the new conveyor connector would allow chaining multiple arrays, but even then adding or taking a certain resource would just check the same index number on each array instead of checking each slot on every container.

  12. #12
    Member
    Join Date
    Feb 2018
    Posts
    138
    Post Thanks / Like
    Regarding Containers .... I agree, the huge size increase of the Large container, without a commensurate increase in storage capacity, just makes no sense.

    My suggestion, though, doesn't just change the Large container - it also changes the Compact container. Because, storing TWELVE stacks of ninety in the Compact container just .... it doesn't make sense. Seriously, consider that you can pack 1,080 sleeping bags into something the size of a SMALL footlocker.

    So, I'd like to see three tiers of storage:

    COMPACT container, 1x1x2 (volume: 2), 100kg, stores 4 stacks (2 per unit of volume);
    MEDIUM container, 2x2x4 (volume: 16), 350kg, stores 36 stacks (2.5 per unit of volume);
    LARGE container, 4x4x8 (volume: 128), 1300kg, stores 384 stacks (3 per unit of volume).


    Alternately, the storage could be bumped to 5, 50, and 500 - for nice round numbers.

    I could see the Medium unit being very useful for "bulk hauler" type vehicles, and the Large being more used for bases (Mobile and otherwise), though some "freight truck" applications might use that Large unit.

    Note, the main thing is: as you build the bigger and more-expensive (in terms of needing more advanced materials) containers, the efficiency of Storage per blockof volume, and the effficiency of eight-per-stack-stored, both improve at a modest but appreciable rate. This gives us a reason to build those bigger containers other than "less tedious".

    Because, yeah .... if I just want the storage space, and not the volume, I'd rather build ten Compact Containers (occupying 20 blocks of volume) than one Large Container (which is 5x5x10, occupying 250 blocks of volume). I can even build the Compact ones so they're linked, and compressed into a 2x2x5 space (every second pair is rotated ninety degrees, cross-linking all those Conveyor ports).
    Last edited by _Pax_; 22-03-2018 at 10:26 PM. Reason: Corrected math error.

  13. #13
    Member Cypher091's Avatar
    Join Date
    Feb 2018
    Posts
    27
    Post Thanks / Like
    I did some BASIC testing of the opening containers and let the devs know about it in another thread.

    Quote:
    "From what testing I did, seems that after about 3-4 large container it takes longer and longer for the GUI to load even with empty containers.
    for testing I made one large container opened the GUI, close make a second and see if it take longer or not and after 3-4 I noticed it getting slower
    it also occurs with small container but I needed 15-20 small containers to see the similar results."

  14. #14
    Member Gabiz's Avatar
    Join Date
    Mar 2018
    Location
    Riga, Latvia
    Posts
    4
    Post Thanks / Like
    I have checked - CPU isn`t a bottleneck for this action.
    I suspect that the problem is in the way of storing containers/items slots data and way of geting connected containers -> containerID, slotID, itemID, count * 120 (Large container) * connected containers count + some calculations to determine conected containers = lag..
    As I wrote before - if built-in containers will be removed from devices that reduses data poolings/calculations and if container data will be stored not per each slot/stack but per item+count even better.

  15. #15
    Member
    Join Date
    Feb 2018
    Location
    Germany, Nuernberg
    Posts
    60
    Post Thanks / Like
    Quote Originally Posted by _Pax_ View Post
    Regarding Containers .... I agree, the huge size increase of the Large container, without a commensurate increase in storage capacity, just makes no sense.

    My suggestion, though, doesn't just change the Large container - it also changes the Compact container. Because, storing TWELVE stacks of ninety in the Compact container just .... it doesn't make sense. Seriously, consider that you can pack 1,080 sleeping bags into something the size of a SMALL footlocker.

    So, I'd like to see three tiers of storage:

    COMPACT container, 1x1x2 (volume: 2), 100kg, stores 4 stacks (2 per unit of volume);
    MEDIUM container, 2x2x4 (volume: 16), 350kg, stores 36 stacks (2.5 per unit of volume);
    LARGE container, 4x4x8 (volume: 128), 1300kg, stores 384 stacks (3 per unit of volume).


    Alternately, the storage could be bumped to 5, 50, and 500 - for nice round numbers.

    I could see the Medium unit being very useful for "bulk hauler" type vehicles, and the Large being more used for bases (Mobile and otherwise), though some "freight truck" applications might use that Large unit.

    Note, the main thing is: as you build the bigger and more-expensive (in terms of needing more advanced materials) containers, the efficiency of Storage per blockof volume, and the effficiency of eight-per-stack-stored, both improve at a modest but appreciable rate. This gives us a reason to build those bigger containers other than "less tedious".

    Because, yeah .... if I just want the storage space, and not the volume, I'd rather build ten Compact Containers (occupying 20 blocks of volume) than one Large Container (which is 5x5x10, occupying 250 blocks of volume). I can even build the Compact ones so they're linked, and compressed into a 2x2x5 space (every second pair is rotated ninety degrees, cross-linking all those Conveyor ports).
    1+ absoult like your Idea

  16. #16
    Member bigdadda06's Avatar
    Join Date
    Feb 2018
    Location
    Australia
    Posts
    119
    Post Thanks / Like
    I kinda wish there was something in between the compact and the large containers.
    Say a medium container? :-)

    I know you can connect a bunch of compact for the same effect.....

  17. #17
    Senior Member
    Join Date
    Aug 2017
    Posts
    629
    Post Thanks / Like
    I see that from the many improvements idea posted initially, the containers mentioned first (and supported by images) dominate the thread.
    Having all ideas in one thread makes it harder to discuss each of them separately. :(
    Also is more difficult to get an answer from developers as they might not have the time to read the post in one go, and then to write an answer to each idea.

    But because we talk about containers, I noticed an answer some time ago:
    Quote Originally Posted by CitizenK3N
    ... It would be even more awesome if we could "move" a cargo container (or printer, etc) without unloading it (but perhaps I ask too much )
    Quote Originally Posted by Craneballs
    We want to make this - you'll be able to move a block with all settings / container contents.
    http://steamcommunity.com/app/504050...19962086383625

    So this answer hints to the future of game. An overhaul of the way how the items are handled is needed before we get a meaningful use of containers.
    In the near future, when animals will damage our vehicles, the big container might have some advantages, IF it will act as an "armored" version of the smaller ones.

  18. #18
    Senior Member DaFuzz's Avatar
    Join Date
    Jun 2017
    Posts
    251
    Post Thanks / Like
    Quote Originally Posted by _Pax_ View Post
    So, I'd like to see three tiers of storage:

    COMPACT container, 1x1x2 (volume: 2), 100kg, stores 4 stacks (2 per unit of volume);
    MEDIUM container, 2x2x4 (volume: 16), 350kg, stores 36 stacks (2.5 per unit of volume);
    LARGE container, 4x4x8 (volume: 128), 1300kg, stores 384 stacks (3 per unit of volume).


    Alternately, the storage could be bumped to 5, 50, and 500 - for nice round numbers.
    That would make perfect sense, I agree.
    Why on earth would someone spent all his time in life being a little bit creative, when you can go all the way?

  19. #19
    Member
    Join Date
    Feb 2018
    Location
    Germany, Nuernberg
    Posts
    60
    Post Thanks / Like
    also a flush container button would be nice, so all storage of the contaier would be transferd over the connected convey to other container if possbile.
    would love to have this feature to unload the my transporter when docked to mainbase with convey connector.

  20. #20
    Senior Member DaFuzz's Avatar
    Join Date
    Jun 2017
    Posts
    251
    Post Thanks / Like
    Quote Originally Posted by Xaver View Post
    also a flush container button would be nice, so all storage of the contaier would be transferd over the connected convey to other container if possbile.
    would love to have this feature to unload the my transporter when docked to mainbase with convey connector.
    That might actually be a good idea.
    If I'm looking in my 3 large containers right now, they are all filled somewhat with all sorts of stuff that is scattered throughout my containers.
    All that stuff could easily fit in one container, but I just don't feel like doing the RSI practice to place them all in one container.
    But then again, filtering in common would be much appreciated in the containers, because it's utter chaos right now
    Why on earth would someone spent all his time in life being a little bit creative, when you can go all the way?

  21. #21
    Member
    Join Date
    Feb 2018
    Location
    Germany, Nuernberg
    Posts
    60
    Post Thanks / Like
    I think containers need to more options at least, the "flush all via convey button" (only avabile if convey are connected) and a "don't except incoming / oneway - checkbox" if this is marked the game will deal with this container as it woud handle a full one, so it will pull stuff out but nothing in.

    and all active machines like the autominer and printer and greenhouse need the "on overflow put new finished stuff via convey to next container - checkbox" (automines have this already), the "one way checkbox" and the "flush now button" in case you need to move the machine so not all stored stuff gets moved to avatar inventory or droppt on the floor.

    all this should possible to set /change via the terminal,
    so on my transporter:
    -after it is docked to base inventory via convey connector,
    -I open the terminal,
    -filter for container,
    -mark all as oneway,
    -flush one after another
    -and set them back to normal

    transporter is empty and ready to move to next spot

  22. #22
    Member Krookward's Avatar
    Join Date
    May 2018
    Posts
    54
    Post Thanks / Like
    Quote Originally Posted by Gabiz View Post
    • Powered Radar on the moving transport scans/updates map continuously (otherwise why it is turning);
    • Radar scans also in the already scanned location and updates scanned radius (if am on the edge of the scanned location why I can`t scan?);
    Oh, yes, please, active scanning while you fly :P

    - - - Updated - - -

    Quote Originally Posted by Krookward View Post
    Oh, yes, please, active scanning while you fly :P
    As the radar rotates while it is on, the area that is uncovered in the map could be the cone that the radar is facing at a given moment. As it needs a few seconds to complete a rotation, it needs more time instead of being instantaneous.

  23. #23
    Senior Member
    Join Date
    Apr 2018
    Posts
    303
    Post Thanks / Like
    While I agree with the apparent difference in storage capacities in the same volume of space, you might find your neat stacks of compact containers to be a little wanting in connectivity without some very creative container placement - from what I can see, at most you get 5 intraconnected compact containers (60 units of storage per row), whereas the single large container has 120 units of storage in a single container.

    With creative placement it is possible to interconnect all your compact containers, or through the use of connective conveyors, link all the containers into one "super-container".

    Mid to late game, this usually isn't much of an issue, save perhaps one of aesthetics - all that plumbing starts to look a bit ugly. There is also the matter of weight - the weight of 80 compact containers vs. the weight of a single large container - not really an issue for stationary containers, but mobile ones this becomes a big factor.

    But I do not disagree either - that more containers - more of anything really, is always welcome.

    Greenhouses - I don't mind the way they are, however Seeds...

    Since these are the seeds of indigenous plants, they should be capable of being planted, in the ground, where they grow into some species of native plant, which can be regularly harvested like the plants where we harvest these seeds in the first place.

    Mapping - passive mapping of the area in which we currently are located would be sensible. Active scanning (using the Radar) to scan a larger area than just around our immediate area makes sense - however I think an Active Radar scan should also enable us to locate things we can't otherwise see - wrecks, monoliths, alien craft, other things not yet implemented. Passive radar scanning done by a mobile radar should only reveal the map itself, unless some detectable item is actually in visual range.

    Smaller radar would also be welcome - half the size, half the active scanning area.

    I find the Uranium Generator incredibly useful. Fuel is generally abundant, it lasts quite a long while even under heavy load, and is a single-step process to turn raw Uranium into fuel. Deuterium, on the other hand, is a two-step process - 20 Dirty Water must be converted via FAD into 20 Clean Water (20 Dirty Water + 20 Carbon), and then 20 Clean Water converted into 1 Deuterium fuel, which does not seem to last nearly as long as Uranium fuel.

    I regularly build Deuterium processing plants consisting of water pumps, FADs and Mining Rigs to collect the required water and carbon to produce Deuterium. It generally takes an exceptionally long time before they actually start producing excess Deuterium, especially if I power them with Deuterium reactors. Powered by Solar Power and Batteries, or a Uranium reactor is much more efficient.

    Transport - I'd love to see those random "Thrusters" we find become craftable blocks that could be attached to a vehicle horizontally to provide a speed-boost, vertically to provide lift, or both to allow us to produce high-speed air transports and other fun things. They would, of course, require a fuel supply, which should burn rather quickly.

    Gameplay - being early access as it is, I'm fine if they take their time on the actual game play and story and get the engine, game mechanics and things we can build working like a well-oiled machine first. Got to have foundations before roofs.

    Changing item counts is actually quite easy - < / > -1/+1, Shift < / > -100/+100, CTRL < / > -10/+10 already there. Infinite construct mode... that I'd like, especially for my Deuterium Processing Plants.

Posting Permissions

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