Experimental Mode Improvements

Jimmacle shared this feedback 10 months ago
Completed

Much to the disappointment of many players, a significant number of options have been deemed unofficial in the eyes of Keen and hidden in experimental mode. This is causing a lot of problems because existing players suddenly can't find the options that they're used to and even new players get confused by the lack of customization with the mode disabled.

I'd like to suggest rethinking how options are marked as experimental so that it's more user friendly. Instead of hiding the options, could they simply be marked with a different font color, tooltip, and/or "experimental" section in the options menus? This way the message that they are unofficial is still conveyed without purposely making them difficult to find and confusing new and old players alike.

Best Answer
photo

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.

Comments (28)

photo
3

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

photo
3

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.

photo
3

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.

photo
4

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

photo
1

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

photo
1

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.

photo
1

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.

photo
1

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.

photo
4

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.

photo
1

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

photo
photo
6

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.

photo
11

"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....

photo
2

Well said - I honestly couldn't agree with this post more. Program blocks were the most game-changing concept in any video game, and as a professional C# developer, it opened an entire world for me in this silly little sandbox game about space ship blocks. Please solve "engineering challenges" like programming blocks, ladders, pressurization, and economy - don't just label them as problems and sweep them under a rug.

photo
1

Lots of well thought out arguments -- I'll add a few comments from my brief time as a modder:


"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."


Mods can contain all sorts of performance impacting things. For example -- if I have an armor replacer mod, but I don't (or can't) create LOD (level of detail) model states, then you end up with max resolution / max detail blocks that are 5000 meters away from impacting your FPS. This isn't in a script, it is just how the engine works. Maybe it isn't even my fault, but then a new player comes in and uses my new hot armor replacer mod, and it drops him to 2 FPS, and he never comes back.Another great example is transparency and luminance. Same kinds of issues with FPS, hurts perceived performance on both single player and multiplayer (though no real impact on simspeed).

And then yes, there are certainly lots of mods that contain c# code in them which must run to provide the functional aspects of the mod -- and that code needs to be vetted and its impacts understood.

When you are collaborating on software development, anytime anyone modifies files in your project, it could potentially blow things up. The more people you get modifying stuff, the more possible it is that two mods interacting badly will negatively impact performance (sim speed or fps). This impacts all software development, but hits games particularly hard since they are doing so many performance heavy things by default.

This is why my suggestion was to create a process to submit a mod (or pb script) for inclusion into the base game. As the owner of a submitted mod, it is in my best interest to refine my mod until it is perfect, as the reason I'm started the mod was to refine my skill and have something to show off during future interviews. A well understood submittal, refinement, and approval process would be good for Keen and the modders who want to improve their skills, as well as the players that want the value of my mod, but aren't willing to live with 2 FPS or .4 simspeed because of it.

photo
1

'This is why my suggestion was to create a process to submit a mod (or pb script) for inclusion into the base game.'


This is a fantastic idea. A PB could then have a dropdown select for pre-loaded 'official' scripts on an official server, or, if the person has 'experimental' mode turned on they could just go on hacking about with C# to do something else - but the script input fields wouldn't display unless experimental mode was turned on.

There should absolutely be a pipeline to get mods and scripts added to the base game. Great idea!

photo
1

@Mark McCorkle


You are correct, technically. In the context of what Experimental mode is and what qualifies things as being here or not, what I said about scripting mods being a more specific unsolvable problem category is still true. What was communicated is things that cause MP performance and/or Sim speed drops are 'experimental.' FPS drops are all Client side and don't impact the overall MP experience, otherwise, we'd all be locked to 1080p or lower and changing resolution would be moved to experimental. (I'm not convinced this won't happen anyway.)


A process for submitting game code exists. There is no point in including ModAPI stuff in the base game, when people can directly submit those changes to the game's code. (see Marek's dev blog on github going away, for details).


For scripts, if a PB block exists in the game it doesn't matter if a script is included or not because they are grid dependent. Someone could still pull a poorly performing copy of TIM from github and paste it in the block. If they can't, it's not a PB anymore and you lose the ability to make it work on your grid especially if it operates on a specifically named block and you have 5 differently named blocks that you need to control from 5 different PBs for instance or your language is using a completely different character set for block names than the script is looking for. "Large Cargo Container[ Components]" will not be a match to the chinese character set and any word in that name could have a similar but alternate spelling in a different language with the same character set. Flavor and Flavour are the same thing in the US and UK, but are not string equivalents in a script and game localization isn't a translator.


Yes, there are some scripts that don't need to be edited, but the better solution IMHO to allow people to write code (which was Marek's intent when he wrote it) is to move the execution from a single "computer"(PB block) to multiple smaller computers. Meaning Instead of a PB accessing all grid blocks, the script is moved to each block with a terminal interface and the things a script can access are (Mostly) restricted to that block only and passed parameters or returns. Blocks can pass data back and forth, and there is some limited access to things outside your grid available through certain blocks (sensors, solar, etc.) then the Timer blocks, buttons etc can see any script on all blocks and map to them to run or stop them.


A better way to explain this is: You turn each block into an object node and you can wire up one block to another to pass information. It's thematically similar to the visual scripting tool. With script triggers being timers/buttons/sensors/etc. Maybe even ditch c# in scripts altogether and use node.js with a debug instance created between the game block and a web browser while the game serves up a Node-Red Editor instance to draw all of the flows and edit individual block scripts. https://nodered.org/

photo
1

These are not really new ideas are they? Isn't that exactly what they decided to do with Skyrim and its 'official' mods created by end users in their for cash store?

photo
1

I agree Program Blocks are part of the life blood of this game for so many. Without them a lot of players would probably stop playing. I know I certainly would.

PVP, the ability to build your own weapons and the ability to enhance my ships using scripts to get an edge over my opponents is why I play this game.

photo
1

I take issue with you calling this a "newtonian physics simulation". The explosive impulse alone takes a giant steaming dump all over newtonian physics when a relatively small explosion can send a multi million kilogram grid flying off at max speed. So really it's just a multi user simulation of questionable physics and an excercise in engineering to overcome the limitations imposed by the engine itself more than any external or environmental factors.

photo
2

Things like airtightness and PBs are an major part for me playing SE.


Without them i would not bother much playing it because sesigning an airlock that works and fits, running inventory with script and AI mining drones is what the fun part is.


Programmable blocks and airtighness should be an major thing for space engineers, because what is more space than an airlock and drones?


I know that physics and airtighness is an major thing programming wise, but it makes it worthwhile to play in my opinion as long the thing is not only "build an big ass spaceship with guns and blast other spaceships"


Making mass drivers and such is fun yes, but designing an spaceship with working habitat and the whole supply and production chain, building an ship printer and so on is major fun part of the game.


without programming and airtightness SE becomes just another "sandbox shooter" nothing else.


SE is right now pretty much the only game that puts focus on the engineering part, and PBs are an major part in that. Take for example Taledans manager, that is like an function that expands the game in an major way, not "just some added functions"


SE is not an game about points and so on, so mods on servers is quite possible, just make them compute on the clients not the server as much as possible and so on, but doing away with booth is in my eyes and idea that would break SE as an game that is special in an sea of "you can someway build here but it is really just buying done models with ressources and stick parts on it" like subnautica where building is sticking ready modules together, but not BUILDING.

photo
photo
4

Thanks for all the constructive feedback guys. We will continue to discuss this with the team and explore the options.

photo
2

I think keen has overlooked that one of the best ways to get join from a game like this is when we actually break the game. Sure this can be frustrating, but to some extent you need to support that game play too because new and interesting this happen. If you close the lid too tightly people will just go play Minecraft or Factorio instead as those are far more mature open world builders.

photo
2

It would be nice to get rid of the red 'Experimental Mode' warning in the top right corner of the screen that keeps appearing every ten seconds- likewise with performance issues warning that could put on the HUD as a small Exclamation mark, rather than annoying the heck out of everyone and ruining recordings...

photo
1

This can be disabled easily, however, the way this was hastily put together, without rhyme or reason, with no thought to the UI and hiding all options without any inline or online instructions, turns an easy operation into an unnecessary struggle. (Its in the Game Options...)

photo
2

Cheers- I thought I actually disabled in-game warnings but I'll check again ( may have turned itself back on when going from one world to another, because... SE.... ). That is a point you just made though- the instructions for this game are very lacking, and half the key-bindings are also missing ( such as various options for painting different sized areas, and bringing up different screens for spawning items, space master, debug, performance etc etc ). Keen really needs to work on the UI...

photo
1

Sorry, the option is in the red message pop up. Shift f2 I think. There is a box you can tick to turn off the messages.

photo
photo
3

Hello, Engineers!


We are working hard on this feature and it should be included in one of the next major updates for Space Engineers. However, as our game development process is fluid, things may change in the future.


Cheers!

photo
6

"Experimental" should be renamed "Advanced" and treated as such.