Should more functional blocks be limited working on static grids?

Deon Beauchamp shared this feedback 21 days ago
Not Enough Votes

Although I am a great fan of mobile bases, I wonder if gameplay would be improved by having some blocks limited to a stationary base.

In SE1 this applies to windmills, but where a heavy industrial process is taking place should that be limited to stationary locations too?

By imposing this it would mean putting in roots for things like mass resource production, or for difficult and delicate high value, high tech item production. It could be that some types of energy and power production would also be only available on static grids and as a further measure for the most unique items as others have suggested be limited by environmental necessity. Long range communication could be a good candidate too.


Most of standard survival processes would be business as usual, but I am sure that there will be many new things in SE2 where this idea may have a place.

My hope is this would create the need for more fixed installations, transit roots, more piracy, and resource disputes.

Replies (6)

photo
1

I see that there have been several proposals for end to end static jump gates.

Should this replace or add too jump drives?

End game explorer jump gates for moving between star systems with a small chance of jumping into an asteroid at the other end?

photo
1

I'd think add to; you could have the exact same performance, but the static gates aren't trying to move _themselves_, so they effectively have better performance and better access to power generation, given that a station doesn't care about weight.

photo
photo
1

I believe the idea of certain functional blocks being restricted to permanently static grids (no more flipping to be mobile) is compelling and could add a strategic layer to the optimization problems in SE2.


The change would drive players to establish more permanent bases, and it's just left up to game play balancing to determine what those blocks and restrictions are and how it fits into the progression system.


Perhaps basic refineries/assemblers or less efficient refineries could remain mobile, while advanced or significantly more efficient versions require a static foundation. Maybe a future farm block for food requires a permanently static grid. Restricting the most powerful defensive weaponry to static grids would naturally give defenders an advantage.

photo
1

limiting the upper-most tiers of production-blocks to static-construct-only would be fine as long as enough of the regular stuff could be done mobile and the non-mobile-materials could be reliably obtained through trade or raiding npc-faction stuff.

photo
1

The reason for restricting the use of some blocks to "static structures only" escapes me. What is the purpose of this?

What is the difference between a "ship" parked on the surface of a planet and the exact same "base" standing next to it?

The only difference is in the switch settings in the grid property settings. That's a bit small, I'd say...

I can understand if the block will have a "cannot operate in a gravitational field stronger than X" requirement for proper function, so it can't be built on a planet or moon. Or the block's functionality will be limited by the zero acceleration requirement - so it can't operate on a moving ship, or it will require a vibration-free environment, so it will have to be placed on a separate platform with only basic equipment - for example, no reactor and no moving solar panels, nor gyros...

photo
1

>>The reason for restricting the use of some blocks to "static structures only" escapes me. What is the purpose of this?

A game mechanics limitation that creates an optimization problem for the space engineer to solve. If the most efficient Refinery can only be used on a permanently static base (assume no flipping between station and static), we need to determine if it's worth creating that permanently static base and using it as a staging point for refining the ore in an area before moving refined ingots, is it worth it to "lose" some refinery efficiency to refine it on a larger mobile mothership, or it worth it to design a miner ship that can refine ore and then quickly move that ore through multiple jumps to a more efficient refinery. Is it worth it to engineer a small, compact, easy to construct static base that can serve as a highly efficient refinery for an area and then grind it down when the area has been mined out.

What's the optimization problem here? Time and resources. However, it's up to the space engineer to determine what they believe are the most valuable things to optimize.


>> What is the difference between a "ship" parked on the surface of a planet and the exact same "base" standing next to it?

Under SE1 game mechanics - nothing. Under the "what if" of future SE2 mechanics and the proposal that specific blocks only be possible on a permanently stationary base, the difference could be not having the most efficient refinery.

>> I can understand if the block will have a ...

Those too sound like compelling game mechanic changes that would create interesting problems for space engineers to solve and optimize. How would we be solve the problem of engineering a large mobile refinery ship if we can't use reactors for our power needs whenever it's moving? Do we add more cargo containers to create a buffer for ore that we then mine when we are stationary, or do we switch to hydrogen engines so we can refine ore while moving? If we're using hydrogen engines, how do we store and produce the hydrogen? As Ice on the ship, as a number of additional hydrogen tanks that we fill up from another grid? Do we just add more batteries?

There's doesn't have to be one "right" answer here to this optimization problem; it depends on our individual choices for what we value most to optimize. The proposed change creates the game mechanics that creates the problem to space engineer.

photo
1

I think the better approach to this is having more significant differences in regards to the type of processing that can and needs to be done for some components. None of the base ones, of course - you should be able to build a dinky ship that can fly around without any huge infrastructure, but stuff like "This needs to be produced at high pressures" (ae, ocean, deep underground), "this needs to be produced at low gravity" "this needs low pressures" etc encourages different outposts fairly well.


Different infrastructure could also benefit from this - you could have large scale dams be more effective than the usual ship side reactors, and have things that require significant power.

photo
1

I don't consider solving problems created by a nonsensical rule to be a “challenge”...


But you could try proposing a ban on nuclear reactors.

photo
1

I admit that I do not know how this will be improved in the future, but at present it does not look like it would go well on board a ship turning quickly.

photo_482953

As far as I know this process takes a little time to bake. Scale can be important for mass production and this is a small one. Metal printing does not give you all of the properties that you may require from the product.

photo
1

@Deon - The movement of liquid metal through pipelines was already solved in the pre-war (or just post-war) period. It works on the same principle as magnetohydrodynamic propulsion of ships - electrically conductive metal moves in an external magnetic field. It is not a very widespread technology (because it is expensive and energy intensive), but it is used in plants where metals sensitive to oxidation are processed.

But it also works well with base metals such as aluminium or iron/steel.

I worked for several years in a factory where molten primary aluminium was pumped from electrolyzers into transport vehicles using such equipment.

photo
photo
1

I think a better thought would be to add an _option_ to disable functional blocks (refineries, assemblers, ...) either en-masse or on a block-by-block basis, in a similar way that the wind turbine works (or doesn't woek); perhaps there's too much vibration from operation unless you're firmly anchored to something.

photo
1

No more than we have now because then you limit build freedom which is a core draw of SE to start with. Some blocks are limited to static grids only because of the nature of what those blocks are, such as windmills and safezones as prime examples. Their calculations couldn't possibly run on anything other than a static grid without causing massive lag or issues elsewhere. Restricting stuff to static grids only needs to be done on a block by block basis otherwise you get into the quagmire of people saying "well if they're restricting this block I think they need to also restrict (block here)" and it spirals really fast into a crappy situation.

If people want to restrict certain blocks to static grid only such as say refineries or assemblers instead of letting them be mobile, keen could easily let people add a command to certain blocks as simple as "RequiresStaticGrid=true" as a very rough example and let people further customize. Can even add a submenu to let people do it from in the game vs changing a file tag. Something like this means those who want things more restrictive can customize the options without it being forced on others who do not want such a restricted experience, thus both sides win. This of course assumes a technical approach is desired.

That said there is a completely free way that people can use right now that's already in the game which is DON'T BUILD CERTAIN BLOCKS ON MOBILE GRIDS. If someone thinks it's cheesy to build refineries and/or assemblers on mobile grids then don't do it. Being that this completely free option is available, I have to ask what the purpose of this proposition is to start with? What's stopping people from simply limiting themselves of their own volition without needing some kind of technical force behind it? The beautiful thing about a sandbox game is you're largely only as limited as you choose to be. You can mix and match the sand in various different ways using tons of different tools in the confines of the sandbox, or choose to leave some of the tools in the proverbial packaging. For myself I've yet to use pistons, rotors, or hinges in any builds of mine yet as I've not seen a need for them. Doesn't mean they're bad blocks, just that they're not really my thing where as others swear by them. By all means feel free to suggest things, but when the free solution exists already I do have to ask what the point of this would be.

photo
1

There are artist that can create from a blank piece of paper and come up with a masterpiece. It is more method to create with a rule set in mind. You can bring rules to the table, or choose a set that has already been created for you. Gaming is no different, rule sets can be shared so that the style of gameplay can become a consensus. Choosing self imposed rules is life building, but in a game shared with other players it is far too easy to cheat on an insubstantial agreement. This is not about taking away, but adding features that encourage play styles that will challenge the players thinking and decision making. Base building is a commitment, but like any, you still have a choice to up sticks and move on and start anew, after all it is a sandbox

photo
1

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”

― Antoine de Saint-Exupéry, Airman's Odyssey

photo
1

@Deon: My dude, your logic is oxymoronic and self defeating.

"Choosing self imposed rules is life building, but in a game shared with other players it is far too easy to cheat on an insubstantial agreement."

Then don't play with people you think will cheat. Have an admin verify that no one is using restricted blocks on their grids. Simple as that. Otherwise why should anyone else in the game have restrictions forced on them because a small handful don't like it?

"This is not about taking away, but adding features that encourage play styles that will challenge the players thinking and decision making."

No this absolutely steals build freedom from people. By restricting blocks that had no such restrictions before, you are absolutely reducing the number of build types that can be added. Such as assemblers and refineries as one example yet again. If folks don't like the idea of something like them being used on mobile grids, their solution is to simply not use them on mobile grids. Or they can ask Keen to allow admins to restrict certain blocks to static grids only in the world options. Beyond this, why should I or anyone else have block restrictions forced on us because a small handful don't like them? On several of my larger ships I keep a couple refineries and assemblers onboard for when emergency repairs are needed while away from base. I know I would be pissed if I logged in and magically my ships have had their functionality reduced by such a moronic change. If folks want to restrict certain blocks to static grid only, then they can either come to a "gentleman's agreement" to not use restricted blocks on their mobile grids, or ask for a world option to restrict it. Otherwise nah they don't get to demand that I be forced to play like them purely because they don't like certain stuff.

Which brings me to my final point. You say on one hand it's not about taking things, yet on the other hand say it's about adding things. Those 2 statements don't go together like that. If it's not about taking things away, then you will use a gentleman's agreement with trusted players and/or ask for world options you can implement for yourself without forcing it on others. If it's about adding things, then this is the wrong way to go about it as this is akin to adding a negative number to something then wondering why the sum is lower than before.

photo
1

@captainBladej52


My geezer, go back and read my comments more carefully.

Logic and humanity - Mr Spock!


Picking and choosing bits out of context can lead to a great deal of misinterpretation.

(I know, I am guilty too.)


So can thinking worst case most of the time.


But I will give you a 4 out of 10 for effort.

Well done - must try harder.

photo
Leave a Comment
 
Attach a file