StarMade - Devblog May 22nd 2017

[schema]

Greetings, citizens ~



Here’s another weekly devblog.



What are we working on right now?


We are currently finishing off a redesign of the chunk request system which will make requesting chunks over multiple entities a lot more controllable. This means that chunks close to the player can be requested a lot faster resulting in a much better overall experience with loading times for objects (as e.g. asteroids that are far in the back get less priority over closer objects). Prioritisation did exist in the previous system, but it was more local to the entity.

Also, a few prototypes to test out if our plans for the reactors are viable implementation wise have been implemented. One example is a system which can create a convex hull (Convex hull - Wikipedia) of an arbitrary amount of blocks has been implemented. This system’s focus is to be as fast as possible and to provide a variable amount of precision to simplify complex structures. This is then not only usable to make the distance between stabilizers and main rector actually viable, it can also be used graphically to outline ship systems.

Furthermore, Terra has been working on a rather significant launcher update. See below for details!

Launcher Update
While most of the work is done, the UI isn’t quite finished yet, so you’ll have to rely on imagination instead of screenshots for now. (Sorry about that!)

This update consists of two major changes:

Firstly, we’ve merged all of the settings popups into a single dialog. This both drastically improves ease-of-use, and gives us unlimited space to add more settings later, for example logging. (Implementing this required extensive changes throughout the codebase, so the thorough QA required for this will delay release somewhat.) We’ve retained the settings gear icons, but instead of opening their respective popups, they now act as shortcuts into the new settings dialog; this should help with transition. The architecture behind the consolidated options also allows us to implement more complicated and/or settings-dependent features, of which this release’s second feature is a good example:

The second is something that people have been requesting for ages: official support for multiple StarMade installs! Adding them is straightforward and easy, and you may have as many as you like. There’s also a dropdown on the main window that allows switching between them quickly. No more manually changing the path. No more version/branch mismatches. No more multiple launchers. Everything just work

There have also been minor tweaks throughout; some visible, some not.

Power feedback
Thank you for the large amount of feedback on our new power proposal. So far it seems that we need to iron out some key issues and tweak the system here and there.

The major concerns so far seems to be:

• Restrictive rules that contradict several goals (Simplicity, Logical):
  
  • 1 active reactor per entity | 1 active reactor for entire ship
    
    
  • Minimum block count for chambers
• Tech points are too abstract
  
  
• Bad terminology for power related functionality such as Tech Points, Chambers, Skill trees, ...

These are definitely valid concerns. In the next few days we’ll work try to work on resolutions to as many issues as we can and try to improve the power system so that doesn’t have to compromise on build creativity that much yet also not open up for exploits.

As a side note, with the power proposal we are of course planning a responsive and informative GUI that will come with the system, which will indicate exactly how the system is functioning so that it’s easily understandable just from that without having to read one word of explanation.

Making things work with docked entities
Perhaps an interesting topic to talk about and why it’s not that easy to find a solution for it that still follows the goals we’ve set up.

With the current in-game power system, the main reason why people use docked reactors, is to bypass the softcap limit that is set per entity. It gives you more favorable power production per block by spreading it out over multiple entities. Anyone that doesn't do this, such as just sticking with a single big ship, will be at a severe disadvantage.

In this proposal, we have power reactor blocks scale in a linear fashion, there’s no way to get more power per block by splitting them over multiple entities…

But there's still something related to power that can be bypassed which is the minimum distance required between the reactors and stabilizers. That distance scales differently depending on reactor block count. It only influences the amount of volume your ship needs to get more power out of it but it comes down the same exploit but most likely just less severe.

There’s a possibility where the distance can scale linear just like the power blocks do, it depends on preliminary playtesting to figure that out.

If that was the case, docked reactors would already have a big chance of coming back.


There are also power related things we have to care about when talking about docked entities such as chambers, but you can simply disable those from working and it will be just fine from a ship perspective.

However, when investigating what exactly is wrong with this, we noticed that there are plenty of other inconsistencies when it comes to docked and undocked ships. Both examples could literally be the same ship yet as soon as you dock one of them, it becomes part of another ship and it loses a part of its systems and functionality.

The docked power allowing you to bypass the softcap is far from the only issue StarMade has with inheriting systems and functionality. It’s just the most severe one which is why it’s being focused on so much.

Just a few examples that we can bring up:

1. Only the main ship, the one at very bottom where everything is docked is too, can control movement.
   
   
2. Rail connections are weak points, if you combine 2 of the exact same entities with each other through a rail connection, and someone manages to destroy your rail. Your ship that you still control, suddenly lost half of its mass. As if the experimental feature “break off” was enabled.
   
   
3. No full 2-way inheriting.
   
   
   1. Shields are inherited from the parent entity
      
      
   2. Thrust and mass, are inherited from the child entities
      
      
   3. Rail enhancers, rails only enhance their 1st level child entities <=> entities only care about the enhancers of their parent
      
      
   4. Mass is inherited 1- way, the bottom ship will be the sum of its own mass, and the chains above it.
      
      
   5. On top of all this, most of these systems use power, yet power either inherits only from the parent, and/or it uses its onboard power.

There are 2 distinct cases here:

Docked entities should be fully independent from their parent and children
This would be the safest option when it comes to exploits and amount of work to be done, it would also decrease complexity and make StarMade easier to learn. Yet it comes at the price of limiting creativity a lot and reduce the amount of advanced structures you can make later on. Modular ships would not be feasible with this system.

Docked entities should completely merge with them when it comes statistics.
This would be the best option gameplay wise, allowing as much creativity but also risk opening up the system for exploits. It could also be too complex for new players to get into this although that’s more of a progression problem than

As for some of the advantages of turrets versus fixed weaponry, we can always balance those through AI accuracy, swivel speed or some other system that does not add special rules to the inheriting of systems.

We’ll be looking at more feedback of course.


As always, thanks for playing StarMade!

~ The Schine Team

 

[Exozen]

First!

 

[therimmer96]

RIP Starlaunch, you'll be missed by no one.

 

[kiddan]

There are 2 distinct cases here:

Docked entities should be fully independent from their parent and children
This would be the safest option when it comes to exploits and amount of work to be done, it would also decrease complexity and make StarMade easier to learn. Yet it comes at the price of limiting creativity a lot and reduce the amount of advanced structures you can make later on. Modular ships would not be feasible with this system.

Docked entities should completely merge with them when it comes statistics.
This would be the best option gameplay wise, allowing as much creativity but also risk opening up the system for exploits. It could also be too complex for new players to get into this although that’s more of a progression problem than

How about both? In a system with reactors, chambers, and conduits; What if you could connect conduits to rails and dockers to transfer power between entities? If you do not set-up conduits, nothing but motion is inherited.

Could be a bit too complex (which way do you want to transfer power? Which way can you transfer power?). Thoughts?

 

[jstenholt]

I can't wait until I understand what the hell the power update actually is. Then I can start arguing about it with everybody else.

 

[lupoCani]

for some of the advantages of turrets versus fixed weaponry, we can always balance those through AI accuracy, swivel speed or some other system that does not add special rules to the inheriting of systems.

Before I go about offering any more detailed opinions, I'd just like to remark that balancing the game around what AI can and cannot do seems like a terrible idea. This would mean making balance dependent on limiting the game's control features in the long term. Swivel speed and sensor accuracy are the sensible options.

Oh, and, if you are looking into letting turrets inherit firepower, I'm very happy about that.

How about both? In a system with reactors, chambers, and conduits; What if you could connect conduits to rails and dockers to transfer power between entities? If you do not set-up conduits, nothing but motion is inherited.

I do agree that conduits - or, rather, physical contact points for transferring resources - between entities is an appealing solution. Such a system would include full transfer of power, shields, firepower, and even as fallback docking fixtures.

 

[Ithirahad]

Docked entities should completely merge with them when it comes statistics.
This would be the best option gameplay wise, allowing as much creativity but also risk opening up the system for exploits. It could also be too complex for new players to get into this although that’s more of a progression problem than

It is not very complex to explain that stuff on docked entities is treated as part of the main entity.

As for some of the advantages of turrets versus fixed weaponry, we can always balance those through AI accuracy, swivel speed or some other system that does not add special rules to the inheriting of systems.

Swivel speed scaling with size is necessary one way or the other. Please don't make AI accuracy really bad under any condition by default as a balancing method; that is just frustrating.

 

[Matt_Bradock]

Dear schema !

Thank you for your adamant efforts to keep the game up to date, and make it more enjoyable and easier to learn for new players. If done right, this rework may make the learning curve a little less like trying to climb Mt. Everest.

Well here's a proposal to handle the docking power problem.
- Let docked entities inherit all defensive chamber effects from parent entity if they don't have an active reactor system (such as countermeasures, shield boost or armor boost)
- Let the players decide if they want to use an active reactor on their docked entity or use the parent entity's (but make it an either/or, if the docked entity's reactor is online it can in no way get power from the parent entity) Move this setting to the AI settings (checkbox: Always use onboard reactor)
- Make turret swivel speed scale downwards with dimensions and mass just like with ships, but upwards (to a certain cap, like 50%) with additional mass enhancers. This adds to realism as well, and gives the option to builders that if they want anti-fighter turrets, they can make them turn faster through extra enhancers but that costs more space and power.

As for effects on turret weapons, I still kind of need clarification whether the tertiary effects will remain unchanged (only consuming power, not connected to reactor) or weapon effects themselves will be part of the chamber system and consume "tech points" to function. Obviously, the latter needs an active reactor on the entity with the guns to work, or for tech points to be inherited from the parent entity just like power. The third alternative, namely, removing tertiary effects from turrets and docked weapon modules altogether, is not something any of us would want, in my honest opinion.

So what's the battle plan here?
- Leave weapon effects unchanged, and only move defensive and utility effects to the chamber system?
- Move weapon effects to the chamber system, and enable active reactors on turrets to power the weapons and effect chambers?
- Disable reactors on docked entities and let them inherint TP from the parent entity instead, along with power?
- Allow a secondary reactor system on the parent entity to be dedicated to feeding docked entities with power and TP (through connecting to the rails through conduits or something)?
- Disable effects on docked turrets and fixed guns altogether and be done with it?

 

[Lancake]

It is not very complex to explain that stuff on docked entities is treated as part of the main entity.

Correct, it is easy to say that docked entities are treated as part of the main entity. We were pointing towards the rules and special cases to be considered that could result in making this happen, very complex. A very abstract example would be:

• in order to achieve X (merging of entities):
  • you have to put restrictions A, B, C, D and E in the game.
    
  • you have to add special cases to M, N and O that are exempted from the above
  • you have to change scaling of systems T and U to make it work

Giving all of that info to the player without throwing them a list of bullet points, is not easy and if done improperly, could easily cause an overflow of information.

Swivel speed scaling with size is necessary one way or the other. Please don't make AI accuracy really bad under any condition by default as a balancing method; that is just frustrating.

It seems we should avoid concrete examples to not give you the wrong idea. The point was that you don't need to change the inheriting system to make it work just fine for some special cases. Whether the few examples we gave would be decent solutions or not does not matter here. Perhaps nothing needs to change at all when it comes to turrets,
Perhaps everything needs to change with turrets.

Perhaps we have to remove the entire rail system to make inheriting work (that's a joke).

 

[Ithirahad]

- Let the players decide if they want to use an active reactor on their docked entity or use the parent entity's (but make it an either/or, if the docked entity's reactor is online it can in no way get power from the parent entity) Move this setting to the AI settings (checkbox: Always use onboard reactor)

If this was done, then they might as well allow multiple running reactors on the main ship, and let people choose what reactor they want their main ship guns to use? I don't understand the difference between these.

Also, people could still clip together docked reactor blocks for turret power to get extremely high power density.

One reactor per ship seems to be the best way to keep things neat, tidy, and under control.

 

[petlahk]

Has anyone thought about just not letting docked entities share power with the main vessel, and removing the power and shield transfer beams from the game completely? It really isn't like the power and shield transfer beams were useful for anything other than getting around power caps in the first place. Or, is there something more complicated that I'm missing? If there is something that I'm missing, please explain.

 

[NaStral]

The best setup for server performance is one where there are as few docked entities as possible. As much as I'd hate to see the possibilities of what you can do in terms of shipbuilding reduced I'd also really like to see the game perform smoothly enough to be broadly attractive to a wide variety of players. If the whole thing absolutely has to be changed from the ground up let it be for performance reasons more than anything else. Ideally, any kind of options regarding exceeding the power cap should be something you can put in the main body rather than tempting players to dock more large objects to, or even worse IN their ship. Moving parts, especially moving parts done in ways that aggravate the way the game engine and servers handle everything is a huge problem.

Personally I think the current system is perfectly fine and while it's a bit arcane to some, it's not as impossible and unfair as some people make it out to be. Some kind of modification of the current system with elements of what is proposed might be a better direction to go in rather than a radical change where, from by the looks of it, we'd just be exchanging one unsatisfactory system for another.

I do agree with the potential for systems to have more efficacy per block, as that would reduce the total block count for all entities.

 

[Lecic]

The best setup for server performance is one where there are as few docked entities as possible. As much as I'd hate to see the possibilities of what you can do in terms of shipbuilding reduced I'd also really like to see the game perform smoothly enough to be broadly attractive to a wide variety of players. If the whole thing absolutely has to be changed from the ground up let it be for performance reasons more than anything else. Ideally, any kind of options regarding exceeding the power cap should be something you can put in the main body rather than tempting players to dock more large objects to, or even worse IN their ship. Moving parts, especially moving parts done in ways that aggravate the way the game engine and servers handle everything is a huge problem.

Personally I think the current system is perfectly fine and while it's a bit arcane to some, it's not as impossible and unfair as some people make it out to be. Some kind of modification of the current system with elements of what is proposed might be a better direction to go in rather than a radical change where, from by the looks of it, we'd just be exchanging one unsatisfactory system for another.

I do agree with the potential for systems to have more efficacy per block, as that would reduce the total block count for all entities.

Your first and second paragraphs are completely contradictory. The current system MASSIVELY ENCOURAGES docked entities. You really can't get rid of this problem without massively modifying the system, and if you're going to do that, you might as well rework it from the ground up with something that's more interesting to build and easier to learn.

 

[Oblivionburn]

From what I understand, the goal is to start making StarMade more of a "game" than just a "sandbox/ship building simulator"... please correct me if I'm wrong. While I personally see this as an incredibly good thing to do, there's two big problems here:

1) The community/veterans only know StarMade as a sandbox and wish to keep it that way. Being able to jump in and have full creative freedom without needing to do much IS StarMade, and is what makes the game stand out from what they perceive to be the competitors (i.e. Space Engineers, Empyrion, etc).

2) Games are built on rules, limitations and obstacles/problems to overcome for a sense of achievement, whereas a sandbox is the lack of these (an emphasis on creative freedom).

There is inevitably going to be backlash as StarMade gains more limitations/obstacles/rules to go from "sandbox" to "game", and there seems to be a serious need for the developers to discuss this with their community to ease some of the pains/confusions/conflicts-of-interest.

I do agree that conduits - or, rather, physical contact points for transferring resources - between entities is an appealing solution. Such a system would include full transfer of power, shields, firepower, and even as fallback docking fixtures.

This sounds pretty awesome, and I think it would make ship building/combat far more interesting. It's also a good example of how implementing limitations/obstacles/rules = more rewarding/interesting gameplay.

 

[NaStral]

Your first and second paragraphs are completely contradictory. The current system MASSIVELY ENCOURAGES docked entities. You really can't get rid of this problem without massively modifying the system, and if you're going to do that, you might as well rework it from the ground up with something that's more interesting to build and easier to learn.

Apologies as I was not being clear enough in terms of what I meant. My second paragraph was about the current system of power generation, caps and auxiliary in how they are placed and nothing to do with how that power is transmitted between entities, as that was the first paragraph. With that being said, it might be better if an entity docked to another cannot generate it's own power while docked but rather must draw it from the main. That's essentially what I was getting at.

 

[Sgtwisky]

Dear schema

So what's the battle plan here?
- Leave weapon effects unchanged, and only move defensive and utility effects to the chamber system?
- Move weapon effects to the chamber system, and enable active reactors on turrets to power the weapons and effect chambers?
- Disable reactors on docked entities and let them inherint TP from the parent entity instead, along with power?
- Allow a secondary reactor system on the parent entity to be dedicated to feeding docked entities with power and TP (through connecting to the rails through conduits or something)?
- Disable effects on docked turrets and fixed guns altogether and be done with it?

IIRC, your first statement here is in fact the case. I remember reading it as confirmed in the proposal thread. I am also going to assume that shield protection for turrets/docked entities will not change. At least I hope it does not.

EDIT: Found the quote

Not sure if it was in the post, I know it wasn't in the video. As far as offensive effects, those will stay. Your weapons can remain unique from gun to gun. Defensive effects will overlap with the chamber tree system, so it's best if they are just incorporated.

/EDIT

SO... with all the talk about how to handle docked entities I figure I will throw my 2 cents into the fray.

The main drawback to allowing entities that are docked, to use their own reactors is that it can be used to circumvent the spacing required in some cases. A case of this would be docked (Fixed) weapons that are fired with logic.

The upsides however, IMO are the ability to use drones (drone power would not be turned off while docked), The ability to use self powered turrets (great if your main ship is taking a beating, turrets can keep fighting).

SO, why not just say that docked entities, that are NOT turrets (no turret AI, not on turret axis) cannot be fired? This would solve the main issue would it not? Assuming I am correct in what I think the main issue is. I would also add that any entity docked would inherit its parents defensive effects. And those effects would supersede its own until it was undocked. So in the case of a drone, it might have Ion Defense while docked but when it undocks, it's own systems kick in and the effects of Ion Defense are removed.

Of course Thruster/Shield transfer would remain the same. If all entities to be their own separate thing but get temporary protection/effects while attached to the mother ship, its pretty straight forward. And if the only exception is that unless its AI is set to turret, and its docked to a turret axis, then it cannot shoot its weapons is a pretty simple exception to explain to new players. In fact, you only need a sentence or two.

If I am missing something about what players are worried about, then please let me know what the real (or other) issues are.

 

[Extholious]

[My Two Cents On The Docked Entity Problem]

The Possibility That I See Working The Best Would Be That Entities Under A Certain Size (Clarification: Small Entities Like Most Drones And Anti-Missile Systems Would Be Able To Power Themselves And/Or Draw From The Main Ship And Larger Entities Would Be Either Unable to Power Themselves Or Be Unable To Draw Power From The Main Ship) There Is Also The Option Of Adding Limits To The Power Production Of Docked Entities/Transfer Rates That Grow/Shrink According To The Sizes Of The Docked Entities.

 

[33Cav]

Turret effectiveness cannot be balanced using AI accuracy as long as:

• Turrets fixate on targets even when a target is no longer able to be fired at (out of firing arc, even out of range in some cases)
• Some weapons still aim for ship cores

Only after these issues are dealt with can AI accuracy be used as a reliable method of changing AI weapon effectiveness

 

[Lecic]

The ability to use self powered turrets (great if your main ship is taking a beating, turrets can keep fighting).

This is not a good thing. Imagine if we decided cannons/cannon or punch passive was completely immune to damage to the reactor of the ship unlike every other system for no real reason. Turrets should be treated like every other system. Full shield sharing, full armor sharing, mothership power only.

 

[Nacon]

There are 2 distinct cases here:

Docked entities should be fully independent from their parent and children
...
Docked entities should completely merge with them when it comes statistics.
...

I got a 3rd case for ya.

Docked entities should completely merge with them IF both entities are owned by same user/faction. Otherwise they will be independent on their own.