Experimental Mode Improvements

Gwindalmir ●

I finally read the blog post today, and there's a phrase in there that's very concerning:

These were the features that we added to the game throughout its early-access development, but are now not considered to be officially part of the game. However, we don’t want to remove them from the game because many players are used to them.

It sounds like, for the most part, anything in experimental is considered dead. I read as "this is unsupported and may or may not break in the future, so don't rely on it."

Keen says this isn't necessarily so, and things can move out of Experimental, however I think we can all agree mods and the PB will never be moved out of that category.

What I think needs to happen, as what Digi said: they need to be split apart, and their purpose better described.

What Keen has done for this MP update is take literally everything and block it off behind the same wall until they pull selective things back piecemeal.

It makes sense to have *known* features that are both bad for performance, and cannot be solved, in a separate category from standard game features that can.

Examples:

Not recommended, but likely salvageable:

Airtightness/pressurization (and realistic sounds with it)
Most game options (such as spiders/wolves, tool shake)
Pirates (this is fully under Keen's control, and they could do something)

Not recommended, cannot be controlled/solved:

Mods
Programmable Block
Physics Iterations (apparently that's a thing that can be changed)
System specs

However, here's another idea instead: Move all this experimental junk to servers only. Leave the clients alone, just add a performance warning tooltip or something.

It seems like at this point, if the goal is better servers, it would be better to incentivize server owners/admins that if they want a Keen "recommended" star on the server list, they adhere to keen's "experimental" rules.

It's much easier to indicate to new players that a server with a Star will give you the best experience. As long as their system is close to the recommended specs, single player experiences are less likely to have issues, at least across the same timeframe that servers start having issues.

I finally read the blog post today, and there's a phrase in there that's very concerning:

These were the features that we added to the game throughout its early-access development, but are now not considered to be officially part of the game. However, we don’t want to remove them from the game because many players are used to them.

It sounds like, for the most part, anything in experimental is considered dead. I read as "this is unsupported and may or may not break in the future, so don't rely on it."

Keen says this isn't necessarily so, and things can move out of Experimental, however I think we can all agree mods and the PB will never be moved out of that category.

What I think needs to happen, as what Digi said: they need to be split apart, and their purpose better described.

What Keen has done for this MP update is take literally everything and block it off behind the same wall until they pull selective things back piecemeal.

It makes sense to have *known* features that are both bad for performance, and cannot be solved, in a separate category from standard game features that can.

Examples:

Not recommended, but likely salvageable:

Airtightness/pressurization (and realistic sounds with it)
Most game options (such as spiders/wolves, tool shake)
Pirates (this is fully under Keen's control, and they could do something)

Not recommended, cannot be controlled/solved:

Mods
Programmable Block
Physics Iterations (apparently that's a thing that can be changed)
System specs

However, here's another idea instead: Move all this experimental junk to servers only. Leave the clients alone, just add a performance warning tooltip or something.

It seems like at this point, if the goal is better servers, it would be better to incentivize server owners/admins that if they want a Keen "recommended" star on the server list, they adhere to keen's "experimental" rules.

It's much easier to indicate to new players that a server with a Star will give you the best experience. As long as their system is close to the recommended specs, single player experiences are less likely to have issues, at least across the same timeframe that servers start having issues.

3

Damien Hannaford ●

Agreed. Have been playing this game since it first came out. Quite concerning that they have deemed certain features to not be important to them

Reply URL

3

Digi ●

Experimental seems like a mix of unfinished features and default values... they should be 2 different things.

Have a "Custom Server" tag for servers that veer off from recommended settings, with a color change and tooltip for settings that are outside of the recommended values + an explanation to why.

Then experimental toggle on client and DS should be completely removed.

And the features that are experimental be marked in their respective settings window with a red font when they're set "badly" (just like force/torque in pistons/rotors), this being also in client and DS UI, because currently it's really vague which settings are experimental and which are not.

Reply URL

3

Mark McCorkle ●

I totally agree with Jimmacle here. I'm also hoping that there is eventually an official method for taking features (and mods) from experimental into "stable". With profiling and PCU measuring, I'm hoping this becomes a thing.

Reply URL

4

Digi ●

Also a server performance thing (colored bar, percent, number, whatever) in the server browser so you can see the server's average sim speed.

Reply URL

1

Mark McCorkle ●

@digi what if the game browser just gave current sim speed as score which you could sort on like ping?

URL

1

Digi ●

Well that's exactly what I'm suggesting, but current sim might be bad as there's always spikes, both up and down; an average or median or something from the past N time would be better suited.

And not really as a score, it needs to be a value we can relate to, either some bars that we can guesstimate the sim % or actual numbers.

URL

1

Mark McCorkle ●

Keeping a avg in the server's head would require some smarter code than just a ping / pong which responds with current sim speed. I could imagine it being easy to add current simspeed, but considerably more work to store & calculate a rolling average (with min / max) of simspeed for a server. I'm not a server dev though, so I could be wrong on that. I'll let the team at Keen address that when they review this thread.

URL

1

Gwindalmir ●

You could do a simple counter with an array. Just add the current sim speed to the array at a specific index, and increase the index. When you reach the end loop back around.If you have an array of 60 items, you could save the value every second and have a minute average.

To keep startup valid, have a counter indicating how many indices have been used, and divide by that instead of the array size.

I mean, it wouldn't be the most elegant solution, but it's also a solution you could write up in 30 minutes, and it would be good enough I think.

URL

4

Jimmacle ●

Keeping a rolling average of sim speed would be pretty trivial, I think that the average sim speed over the past 5-10 minutes would be a good enough metric for server performance. It could then be used along with other factors like ping to come up with an overall server "health" rating. I would actually suggest against using instantaneous sim speed because occasional 1-tick lag spikes wouldn't be a good representation of the general performance.

URL

1

Kazeshinu ●

A rolling average could be easy to add and should not add much strain to the server an example of calculating the average could be this

double avgSimspeed(double avg, double value)
{
  return avg+((value-avg)/30);
}

where you can explain the 30 as how much impact each value has. if you change the 30 to a 1 it will just be instantaneous sim speed

A rolling average could be easy to add and should not add much strain to the server an example of calculating the average could be this

double avgSimspeed(double avg, double value)
{
  return avg+((value-avg)/30);
}

where you can explain the 30 as how much impact each value has. if you change the 30 to a 1 it will just be instantaneous sim speed

URL

6

Gwindalmir ● ●

I finally read the blog post today, and there's a phrase in there that's very concerning:

These were the features that we added to the game throughout its early-access development, but are now not considered to be officially part of the game. However, we don’t want to remove them from the game because many players are used to them.

It sounds like, for the most part, anything in experimental is considered dead. I read as "this is unsupported and may or may not break in the future, so don't rely on it."

Keen says this isn't necessarily so, and things can move out of Experimental, however I think we can all agree mods and the PB will never be moved out of that category.

What I think needs to happen, as what Digi said: they need to be split apart, and their purpose better described.

What Keen has done for this MP update is take literally everything and block it off behind the same wall until they pull selective things back piecemeal.

It makes sense to have *known* features that are both bad for performance, and cannot be solved, in a separate category from standard game features that can.

Examples:

Not recommended, but likely salvageable:

Airtightness/pressurization (and realistic sounds with it)
Most game options (such as spiders/wolves, tool shake)
Pirates (this is fully under Keen's control, and they could do something)

Not recommended, cannot be controlled/solved:

Mods
Programmable Block
Physics Iterations (apparently that's a thing that can be changed)
System specs

However, here's another idea instead: Move all this experimental junk to servers only. Leave the clients alone, just add a performance warning tooltip or something.

It seems like at this point, if the goal is better servers, it would be better to incentivize server owners/admins that if they want a Keen "recommended" star on the server list, they adhere to keen's "experimental" rules.

It's much easier to indicate to new players that a server with a Star will give you the best experience. As long as their system is close to the recommended specs, single player experiences are less likely to have issues, at least across the same timeframe that servers start having issues.

I finally read the blog post today, and there's a phrase in there that's very concerning:

These were the features that we added to the game throughout its early-access development, but are now not considered to be officially part of the game. However, we don’t want to remove them from the game because many players are used to them.

It sounds like, for the most part, anything in experimental is considered dead. I read as "this is unsupported and may or may not break in the future, so don't rely on it."

Keen says this isn't necessarily so, and things can move out of Experimental, however I think we can all agree mods and the PB will never be moved out of that category.

What I think needs to happen, as what Digi said: they need to be split apart, and their purpose better described.

What Keen has done for this MP update is take literally everything and block it off behind the same wall until they pull selective things back piecemeal.

It makes sense to have *known* features that are both bad for performance, and cannot be solved, in a separate category from standard game features that can.

Examples:

Not recommended, but likely salvageable:

Airtightness/pressurization (and realistic sounds with it)
Most game options (such as spiders/wolves, tool shake)
Pirates (this is fully under Keen's control, and they could do something)

Not recommended, cannot be controlled/solved:

Mods
Programmable Block
Physics Iterations (apparently that's a thing that can be changed)
System specs

However, here's another idea instead: Move all this experimental junk to servers only. Leave the clients alone, just add a performance warning tooltip or something.

It seems like at this point, if the goal is better servers, it would be better to incentivize server owners/admins that if they want a Keen "recommended" star on the server list, they adhere to keen's "experimental" rules.

It's much easier to indicate to new players that a server with a Star will give you the best experience. As long as their system is close to the recommended specs, single player experiences are less likely to have issues, at least across the same timeframe that servers start having issues.

Reply URL

11

Geneticus0 ●

"Not recommended, cannot be controlled/solved:

Mods

Programmable Block"

I take issue with this. I was only a few hours in when I first started editing game files. If I hadn't had the ability to do so I would have never made it past 10 hours in SE.

(The use of "you" is directed at KSH/Marek from here on out.)

Pushing out mods, as well as this entire confusing, poorly planned and even more poorly executed "Experimental Mode" for whatever shortsighted justifications you may have decided in a fevered game performance and financial panic ritual dance about SE's release schedule, is analogous other games/brands trash talking and alienating their customers. You are forgetting where you came from.

If It wasn't for mods, this game would have probably died a silent death on Steam a few years ago or be sitting at <$9.99 at launch. Mods kept this game a float when you abandoned it. That's not a hyperbolic statement, either... We watched you go off on your GoodAI sabbatical and completely disappear for so long, that when you came back to stream with Xocliw, you couldn't even remember how to move around; using the same controls you personally created for character movement! ( yes, while some keys had been reassigned, those had not.)

Then you started confusing your team, acting as if you were a cloned imposter, by asking why the game was so complicated. You went on to say and that it should just have one generic "ore" and just make "components" because having 8(12?) was too complex. You literally had to be reminded by the dev who co-designed the ore/ingot/component system, how many hours you personally put into the design of how that system would work. Who forgets basics about a project like this?

When I watched that stream, I was so disappointed, because even back then I could see that this (generally speaking) is where we would end up over and over again. Experimental mode is another exploding dog. No one wants it. It gets in the way obtrusively. No one in the community was consulted as to how to explain it effectively or how to make it intuitive both to new and existing players. It's a confusing mess of unexplained change sets and qualifications that are not easily predictable in the UI. Why is turning off tool shake even an experimental option? What is more frustrating than anything is that it doesn't have to be this way, each and every time there are major changes.

I'm not sure the term sandbox applies to SE anymore if all of the options are hidden; when you can't bring tools and shovels into the sandbox to build a sandcastle. It's definitely not a game when all of the fun/immersive elements are removed so that they don't cause problems for what is probably best classified now as a Multi-User Newtonian Physics Simulation. Yes people wanted MP fixed, badly. What about the other basic things we've been asking for that are low hanging fruit? Like a dedicated hack tool so that we can capture O2/H2 tanks and take possession of them without losing all of the gas in the process? How many car thieves do you think carry angle grinders with them to hotwire and steal cars? How hard is it to go search howstuffworks before you add something in that makes no technical sense?

There are other approaches than what you've done with this. First would be to take a step back, count to ten, and run this stuff by your focus group/testers/people that don't get paid by you and aren't afraid to argue with you. You are stressing a whole lot of people out by releasing confusing, contradictory, incomplete, and obviously flawed policy. The game is supposed to be beta, your corporate structure and policy should not. You have PR people who are supposed to be the ones delivering information to to a world wide customer base in a clear and understandable manner. Why are you circumventing them and causing more drama?

If you could, step back you would see that:

"Mods" aren't the issue here because most mods don't cause problems to be solved. The majority of mods that can cause overall game degradation are already separated by whether or not they contain scripts. There is a workshop tag for those and you could also filter script mods out or just plain detect scripts in them and skip them if an "enable" setting isn't toggled. You could also look at the methods and interfaces people use that cause performance problems and create a list that would trigger a performance condition dynamically. You could profile them and dynamically send game logic hogs to keen for dynamic flagging in the mod list as known to cause performance issues. Color all mods older than X date in Red, Performance hogs in Orange and show mods dependencies in shades of a single color.

A much less problem creating method for players and modders and your developers to approach the issue is to put "Allow Scripted mods" and "Allow Programmable Block Scripts" in their own settings area that is supported as being functional, but not as a "performance" issue. This means you still do whitelisting, and any other resources you'd give to support any other game system, but you make clear; enabling it can cause problems in your game and is enabled "at your own risk." Why go through all of the trouble of showing and hiding half of the UI, poorly, when you can group "Use at your own risk' settings in the existing UI structure? How does it even make sense to wrap all of these things into a hidden area when to change a setting that isn't performance impacting or buggy, requires hiding all of it? How does it make a lick of sense to have an immersion breaking big red box in game because I turned off toolshake?

I get that you have some irrational hate of a wall of options, but for a sandbox, that's really what we need. We want to be able to customize the game's rules if we don't have a lot of time and want to speed things up, or if we want to invest the time into adding complexity so that the "game" is geared toward strategy and thinking your way through resource problems. Believe it or not: some people think it's fun to figure out how to balance Solar availability with a single battery in a base and can spend several hours getting it to work. You can still break them into smaller groups and put them into their own smaller windows.

PBs are also the only way to provide certain automation because you rejected our calls for Boolean Logic Programmable Blocks in favor of the message: "SE can teach people to become software engineers, so nothing else can be considered."

I realize you fill many roles in a small business. The thing is we are generally smart people. We can tell when you have each hat on because when you are in engineer mode, you try to solve everything with code, and when you are in businessman mode you make business decisions that make no engineering sense. Personally I wish you'd spend more time in Gamer and Modder mode working with only the tools we have, and see how much sense any of this makes....

"Not recommended, cannot be controlled/solved:

Mods

Programmable Block"