StarMade Dev Blog 17 November 2017

[jacabo136]

That problem is not related to the dev build, I've seen this thing pop up in release builds as well. Try relinking your credentials in the Online Play screen. Sometimes it's just a problem with registry authentication, even if you're just playing SP.

Ah ok. That worked brilliantly! Thanks for the help!

 

[Nebulon-B_Frigate_FTW]

Whoa, this was a hell of a thread to read through. After binging it all, a few things stand out in regards to the main issues raised:

1. Unshielded sacrificial hull would be a lot less useful if, as was suggested earlier, all weapons had the (currently useless due to its debuff) explosive effect applied so that damage was spread out to nearby blocks. We really need to get past drilling tiny holes in targets being the only way to damage ships, as it makes main hull useless and flailing ablative armor about at extreme range too good.
2. There's the age-old debate of whether turrets should be fully integrated into a mothership's protection or basically left to their own devices as sacrificial lambs. I think there's a way to do both, so that you can pick off turrets without having them used as ablatives to mess with weapon effects:
   1. Damage should always have some localized shield bleed-through (whether to nearby blocks or nearby systems)
   2. Hitting a docked entity fully hits the mothership's shields
3. Maybe weapons are too long range? It seems like a lot of the problems are in part that we can't really target things because they're less than 1km long, maybe 50 meters wide, and 5-10 km away. Avorion has weapons with similar ranges, but the scale of ships is much larger and they accelerate slower, so you can actually see what you're aiming at pretty well.

Now, as to the new systems:

1. New power system is trash. It doesn't accomplish its goals at all, everything just wants to be a really long rod with the important bits at the front and back. I'm an RPer, and this system severely limits which shapes of ships I can build while also making me shove some crap in their fronts and backs. Filling ships solid with systems is a problem for us RPers because it makes us shove crap in between our walls. You want to make us stop shoving crap in between our walls? Make systems that aren't based pretty much solely on having X number of blocks to achieve a given output (like, make us need space in some way for things, or make us need crew, things should require more structure and less sheer number of blocks).
2. New shield system is a possible way to hurt spaghetti meta, since it gives you comically large bubbles that only spaghetti or other extreme designs will extend past; I'm not hopeful it'll really change much of anything. Unfortunately for me, it means I need to shove the shield crap in between the walls only in one section of walls, can't shove it in between all the walls. This makes RP ships soooo much worse.

Now, in general (this part is mostly directed at schema):

1. There are communications problems. Communication mainly comes in a large dump of what schema wants to do along with many scattered forum posts and maybe a livestream or two. That's bad because it means that, by the time the playerbase is able to give feedback, the decisions have already really been made and it's just a mess as we discover them like this very thread. We need a steady flow of information that allows us to provide feedback well before an idea is fully done. We also could really do with one issue at a time when it comes to systems overhauls. Please put out planning documents earlier and refine them as feedback comes in, so that they can be scrapped or fixed before we have to have 9-page arguments about them in a single night.
2. In regards to the way new power and new shields are being done, I think that it's wrong to put off goals like stopping spaghetti monsters or having ship interior out in later systems. Spaghetti monsters in particular are a multi-faceted problem, and require more than one solution; new power should not be encouraging them, as it leads to more imbalance now and possibly counteracts action taken against them in the future with new weapons.
3. So, about balancing...I think that this idea that "we can get a system in, and then balance it via configs" is fundemantelly wrong because all you are really doing most of the time is shifting or stretching the graph of combat efficiency vs. whatever is being changed. To achieve balance properly, you need to mess with the shape of the graph primarily, as PvPers are essentially just hill-climbing to find the peaks. The spaghetti monster meta exists because of lower density (in terms of blocks per volume, not mass per volume) ships being more combat efficient, you should be designing systems to either favor higher density or a certain density if you want to stop them, not hoping that a larger stabilizer distance will help.

 

[Jojomo]

New power system is trash. It doesn't accomplish its goals at all, everything just wants to be a really long rod with the important bits at the front and back. I'm an RPer, and this system severely limits which shapes of ships I can build while also making me shove some crap in their fronts and backs. Filling ships solid with systems is a problem for us RPers because it makes us shove crap in between our walls. You want to make us stop shoving crap in between our walls? Make systems that aren't based pretty much solely on having X number of blocks to achieve a given output (like, make us need space in some way for things, or make us need crew, things should require more structure and less sheer number of blocks).

Make systems need space and not depend only on block numbers? That's exactly what power 2.0 does....

When we were discussing your MF design I showed you a design with a central reactor and over double the power output of your design: ships don't have to be a stick built with reactor at one end and stabilisers at the other.

The new system doesn't push for long thin rods, despite the impression it gives at first glance. It pushes for shorter sticks, i.e. almost "bricks" rather than "sticks" which aren't difficult to turn into a wide range of designs without too much effect on efficiency.

Do you know the goals of systems 2.0?

1. Predictability: Placing a block leads to predictable outcomes
2. Simplicity: The game should only describe the rules to the player, not telling the player exactly what to do
3. Make every block matter without losing its importance with different ship sizes
4. Depth: The system needs to have equally viable choices within each possible situation, creating additional gameplay possibilities where possible, keeping complexity unchanged.
5. Performance: Game limits must not be avoidable, using the least amount of these limits is better to minimize any potential exploits
6. Performant: Must perform well from a game engine perspective
7. Creativity: Allow as much creativity as possible
8. Logical: Needs to make sense to the player
9. Solution focused: Must solve any current game issues with that particular system

I think it's doing well so far.

New shield system is a possible way to hurt spaghetti meta, since it gives you comically large bubbles that only spaghetti or other extreme designs will extend past; I'm not hopeful it'll really change much of anything. Unfortunately for me, it means I need to shove the shield crap in between the walls only in one section of walls, can't shove it in between all the walls. This makes RP ships soooo much worse.

Connect your shield groups, you can place them anywhere then...

In regards to the way new power and new shields are being done, I think that it's wrong to put off goals like stopping spaghetti monsters or having ship interior out in later systems. Spaghetti monsters in particular are a multi-faceted problem, and require more than one solution; new power should not be encouraging them, as it leads to more imbalance now and possibly counteracts action taken against them in the future with new weapons.

When was stopping spaghetti put off?
New power doesn't encourage them, it continues to allow them. Spaghetti was invented in power 1.0

So, about balancing...I think that this idea that "we can get a system in, and then balance it via configs" is fundemantelly wrong because all you are really doing most of the time is shifting or stretching the graph of combat efficiency vs. whatever is being changed. To achieve balance properly, you need to mess with the shape of the graph primarily, as PvPers are essentially just hill-climbing to find the peaks. The spaghetti monster meta exists because of lower density (in terms of blocks per volume, not mass per volume) ships being more combat efficient, you should be designing systems to either favor higher density or a certain density if you want to stop them, not hoping that a larger stabilizer distance will help.

I disagree.
You create a set of variables that allows a flexible, wide range of curve shapes, and then get on with the next job while the testers do theirs. To wait until it is finalised would be incredibly inefficient. Schine is a company operating in real world conditions - it can't afford to be inefficient.

 

[Nebulon-B_Frigate_FTW]

Make systems need space and not depend only on block numbers? That's exactly what power 2.0 does....

When we were discussing your MF design I showed you a design with a central reactor and over double the power output of your design: ships don't have to be a stick built with reactor at one end and stabilisers at the other.

The new system doesn't push for long thin rods, despite the impression it gives at first glance. It pushes for shorter sticks, i.e. almost "bricks" rather than "sticks" which aren't difficult to turn into a wide range of designs without too much effect on efficiency.

Do you know the goals of systems 2.0?

1. Predictability: Placing a block leads to predictable outcomes
2. Simplicity: The game should only describe the rules to the player, not telling the player exactly what to do
3. Make every block matter without losing its importance with different ship sizes
4. Depth: The system needs to have equally viable choices within each possible situation, creating additional gameplay possibilities where possible, keeping complexity unchanged.
5. Performance: Game limits must not be avoidable, using the least amount of these limits is better to minimize any potential exploits
6. Performant: Must perform well from a game engine perspective
7. Creativity: Allow as much creativity as possible
8. Logical: Needs to make sense to the player
9. Solution focused: Must solve any current game issues with that particular system

I think it's doing well so far.


Connect your shield groups, you can place them anywhere then...

When was stopping spaghetti put off?
New power doesn't encourage them, it continues to allow them. Spaghetti was invented in power 1.0


I disagree.
You create a set of variables that allows a flexible, wide range of curve shapes, and then get on with the next job while the testers do theirs. To wait until it is finalised would be incredibly inefficient. Schine is a company operating in real world conditions - it can't afford to be inefficient.

Power 2.0 doesn't require structure, it just requires distance between the crap shoved in between walls; an actual structure requirement is what Space Engineers has, with conveyor systems. As for shields, shield crap now having to be connected is not very great because it means you need all those gaps in the walls connected for it.
You increased the power output by increasing the depth of the mandibles on your design; that is not always an option. Power 2.0 doesn't push for shorter sticks, it pushes for longer sticks having the non-reactor end thicker.

As for Power 2.0's goals, it is more predictable and simpler, but not every block matters, it's only depth is due to chambers (the one good part of it IMO), performance was never a problem with power, there's very little room for creativity, it's not logical, and it doesn't solve any current game issues. In particular on the last one, the goals indicate it should be discouraging spaghetti, but nothing about it does.
To be quite honest, the goals stated are so general that they're almost useless; Power 1.0 satisfied most of the goals just fine except for depth and predictability, Power 1.0 with chambers would satisfy Power 2.0's goals better overall.

 

[Jojomo]

You increased the power output by increasing the depth of the mandibles on your design; that is not always an option. Power 2.0 doesn't push for shorter sticks, it pushes for longer sticks having the non-reactor end thicker.

I didn't increase the depth, 2m was the existing depth.

It doesn't push for long thin rods. It's lighter to lower efficiency and have a shorter stick, unless the ship is systems only with no hull.

As for Power 2.0's goals, it is more predictable and simpler, but not every block matters, it's only depth is due to chambers (the one good part of it IMO), performance was never a problem with power, there's very little room for creativity, it's not logical, and it doesn't solve any current game issues. In particular on the last one, the goals indicate it should be discouraging spaghetti, but nothing about it does.
To be quite honest, the goals stated are so general that they're almost useless; Power 1.0 satisfied most of the goals just fine except for depth and predictability, Power 1.0 with chambers would satisfy Power 2.0's goals better overall.

The goals are for systems 2.0, not just power 2.0. We haven't yet seen it all and we don't know how it will break spaghetti meta, but we know that it includes plans to do so.

 

[GnomeKing]

I am on-board with the overall goals, but I am not really liking the implementation of all parts of 2.0.

Going down the stabilizer route could be done in a few alternate ways - this one feels really flat and uninteresting:/

I can see that removing capacitor blocks gives more room for chambers on an equivalent build - but i am still not clear on how removing the capacity system helps other aspects (if at all), eg tracking entity- state-change and AI decision-trees ?? In terms of just 'building-fun' at present removal of the interlocking generator/capacitor system also feels a bit simplistic...which seems a shame when there is potential for many interesting block-rule sets in StarMade.

(?maybe a simplified base system will allow easier future expansions ?)

In regard of shields - i think this needs to go either; a) towards much smaller radius, so that thoughtful placement of shield groups on corvettes/frigates and bigger does become an interesting design factor; Or b) basically might as well remain as 1.0 :/, especially because the effort of refitting does not yield much interest or new function (presently).

A system of 'Dump-shield-block-anywhere-at-all-and-forget', being replaced by 'dump-shield-group-pretty-much-anywhere-and-forget' does not seem like a huge step forward :/...and surely it must take a relatively larger hit on CPU resources compared to 1.0 shields, no ?

 

[Valiant70]

Lancake thought of spaghettis to be problematic before they really became popular here, so we have several measures planned to make it less viable to build in a spaghetti style, even though we don't want to share the plans until the weapons update is fully announced.

I'm sure you have your reasons for this, but I believe the community could be more helpful if you share the information sooner. Either way I'm looking forward to seeing the weapon changes.

 

[petlahk]

I think that needing to put my stabilizers 10 blocks away for 12 block reactor is a bit nuts. But. I need to play around with the system a bit more before I can really say.

 

[Nebulon-B_Frigate_FTW]

I didn't increase the depth, 2m was the existing depth.

It doesn't push for long thin rods. It's lighter to lower efficiency and have a shorter stick, unless the ship is systems only with no hull.


The goals are for systems 2.0, not just power 2.0. We haven't yet seen it all and we don't know how it will break spaghetti meta, but we know that it includes plans to do so.

I fail to see why one would use a lower efficiency short stick over a long stick with max efficiency. This is a game where it is advantageous to be long, you don't even need any blocks in between. In fact, to convert an old design, I think one of the best ways is to replace all the old power with new power, only needing to adjust for it needing to be contiguous, build out a ways some direction, place a big ball of stabilizers, then armor and sever it so the enemy doesn't easily spot it.

So, what you're saying is that the whole will fix the problem, but we've only seen a part, and so it's unfair to criticize that part for actively making the problem worse? That is fundamentally unhelpful; our whole issue is that schema has some endgame planned out that we aren't privy to, and consequently we're only allowed to criticize the steps we already have. And that, I think, is the big problem; it might be that the end result of all these steps is a wonderful system like schema dreams of, but it seems like individual steps are just making things worse, and it's very hard for a lot of bad steps to result in a good end state. That leaves things being good down to the emergent properties of a complex system of those individual parts, but I don't think chances are high the emergent properties will solve things.

I am on-board with the overall goals, but I am not really liking the implementation of all parts of 2.0.
...
A system of 'Dump-shield-block-anywhere-at-all-and-forget', being replaced by 'dump-shield-group-pretty-much-anywhere-and-forget' does not seem like a huge step forward :/...and surely it must take a relatively larger hit on CPU resources compared to 1.0 shields, no ?

This is my big issue not just with these new systems, but StarMade's core design. Fundamentally, the game acts as a space RPG in the sense that we dump points in the form of blocks into stat upgrades; our ship hull designs don't really matter. Everything boils down to a numbers game outside of weird stuff like docked hull because the whole game is designed around numbers.
Space Engineers ships may have some problems, but this whole discussion is completely moot for them, and would be even if they had shields and lasers. And why? Because Space Engineers ships have very few aspects that come down to "shove this many blocks into a corner" (pretty much just gyroscopes); their primary form of offensive capability comes in conveyor belts feeding ammo, which naturally leads to a decentralized weapons system all throughout the ship. And SE ships tend to have interiors...not because of any arbitrary restriction on their nuclear reactors, but because you need to physically go somewhere to repair the ship.

Now, I don't expect build mode to go or be limited to within a shipyard or whatever anytime soon, so really the only useful thing out of this for now is that I think shields would be better if the groups were more decentralized and networkable.
For decentralization, the new system already is a huge step towards that...we just need a much smaller starting radius; I'm not kidding when I say most ships I'm willing to build right now would fit within the current starting radius easily. I'm not sure on radius growth, but I really wouldn't want something like a Star Destroyer to get away with any less than a few dozen shield groups; I'm just not sure how much you'd need currently as I haven't built that big.
As for networking, maybe instead of just shield capacitors increasing a group's capacity, we could have some sort of way to "pipe" shielding power around? Either just from the reactor (or multiple if we ever get multiple) to groups or between groups as well. I think we need something where there are solid supply chains you can sever, in order to reward saner designs (less spaghetti), make combat to be more interesting, and not have us shoving crap between walls mindlessly.

Although, that would certainly increase CPU load. Fundamentally, the numbers-game mentality StarMade has is what makes it so scalable over other games. I think, though, it has to to some extent give up that mentality for the sake of being a fun game as opposed to just a high-performance one.

 

[Levarith]

Is anyone else getting this when loading dev build? i have deleted my entire install and reinstalled twice and tried on multiple dev build versions... all give me this...

 

[Snowtiger256]

Is anyone else getting this when loading dev build? i have deleted my entire install and reinstalled twice and tried on multiple dev build versions... all give me this...

Try relinking your credentials to Registry in the "Online Play" section. I've seen this happen on release versions too, so it's not dev specific. Sometimes there's a problem with Registry authentication, even if you're playing in SP.

 

[Di3Hard]

Try relinking your credentials to Registry in the "Online Play" section. I've seen this happen on release versions too, so it's not dev specific. Sometimes there's a problem with Registry authentication, even if you're playing in SP.

I'm actually getting the same problem as Levarith, I've tried the credentials and all but I'm still getting the error even after reinstallation. Any other suggestions on how I can fix this issue?

 

[Levarith]

Try relinking your credentials to Registry in the "Online Play" section. I've seen this happen on release versions too, so it's not dev specific. Sometimes there's a problem with Registry authentication, even if you're playing in SP.

That fixed it thanks.

Anyone else notice shields not showing up when in build mode or in display modules? using [shield] and [shieldPercent] both return 0.0 rather than my shield value. Also when i exit and target my ship is reads that I have 4 times as much shield as build mode claims my shield cap is.

 

[Snowtiger256]

Shields are also being changed in the update, and they're not ready yet, so the game is giving you values that are off. It'll probably get fixed at some point down the line.

 

[Levarith]

and now I am back to the same error as before with nothing I do fixing it. I have reinstalled multiple times even going as far as manually deleting the entire folder from local files then uninstalling to make sure I get everything. I have relinked credentials... nothing fixes it. Even going back to the build .188 that was stable enough for me to play. Not really sure what went wrong but now my entire game in unplayable.

 

[Snowtiger256]

Might wanna try reinstalling in a different directory, than in local files. Sometimes installing Starmade into directories where Windows controls the user privileges (like C:\Program files and such) can cause errant behavior in Starmade. Try reinstalling in C:\Starmade for an example and see if that works.

You can point the launcher into a different directory by clicking on the cogwheel next to the Build type selection box in the launcher. Just make sure you save the new directory after entering it into the Install directory text box in the Build type Options dialog.

 

[Ithirahad]

and now I am back to the same error as before with nothing I do fixing it. I have reinstalled multiple times even going as far as manually deleting the entire folder from local files then uninstalling to make sure I get everything. I have relinked credentials... nothing fixes it. Even going back to the build .188 that was stable enough for me to play. Not really sure what went wrong but now my entire game in unplayable.

Send in a bug report; include the most recent log file.

 

[Snowtiger256]

Dev .195 crashes on world load, Spits out an error message:

 

[petlahk]

Dev .195 crashes on world load, Spits out an error message:

On world load, or after you close out of the tutorial? Lancake said something about this sort of thing being something related to updating in between the dev builds. Either way, you should really submit a bug report to phabricator instead of posting it here:

Phabricator

The devs will see your post and will act on it.

 

[Snowtiger256]

On world load for me. That's been handled already, it's gone in the latest dev build. Met with Lancake last night in chat and it has been fixed.