StarMade v0.199.214 Auxiliary Power, Better Graphics, Better Textures, and Bugfixes

So as it stands now, only really BIG and really small ships seem to benefit from the new auxiliary power: big meta brick-ships have nigh-impenetrable shielding and dozens of blocks between outer hull and AUX group, whilst small ships are good as dead if they get hit anyway.

Devs might as well follow the suggestion and make AUX an alternative and volatile power source, in addition to being Docked Reactor: The Block. For one thing, new players may find it's simplicity enticing - you don't have to play Tetris with your spaghetti reactors to get the desired output.

I solved the problem of lag caused by undocked reactors months ago. I hooked the logic clock on my reactors to a jump drive. Docked entities can't jump but if a reactor became undocked it'd jump away. Then to avoid leaving a bunch of space garbage they had a self destruct system that would go off shortly after they undocked/jumped. I also found that a cannon slave made the docked reactors require a lot less power caps so they were more efficient than I think they're being given credit. I admit I haven't played with the new blocks yet and I may like them but I suspect my big ship is going to have significantly less power.

Star-Boy said:

I solved the problem of lag caused by undocked reactors months ago. I hooked the logic clock on my reactors to a jump drive. Docked entities can't jump but if a reactor became undocked it'd jump away. Then to avoid leaving a bunch of space garbage they had a self destruct system that would go off shortly after they undocked/jumped. I also found that a cannon slave made the docked reactors require a lot less power caps so they were more efficient than I think they're being given credit. I admit I haven't played with the new blocks yet and I may like them but I suspect my big ship is going to have significantly less power.

Click to expand...

Two power supply groups firing alternately have basically the same effect as a cannon slave, and every good power injector uses one of these methods.

Docking relies on two blocks, jump drive plus logic clock are at least four blocks, so the chance of losing the auto jump drive is higher than the chance of undocking. Also, jump inhibitors might disable the drives.

Zekester81 said:

When he said armor weave i assume he is implying weaving sets of armor tetras through docked layers increasing the protection. Had he said layers i might have assumed just armor layered over it.

Click to expand...

I'm saying armor layers outside AND inside of it (weaved into it). Nowhere did I mention that it'd be docked, that'd produce more lag than docked reactors.

keptick said:

I'm saying armor layers outside AND inside of it (weaved into it). Nowhere did I mention that it'd be docked, that'd produce more lag than docked reactors.

Click to expand...

By figuring out the explosive patterns of the reactors when they destabilize, I am fairly sure I have figured out the best layout for the groups of 10000. I have found a layout that will only lose 429k from its regeneration of 1.929m. A chain reaction finishing will still leave me 1.5m e/sec.

I will be posting my findings in a findings thread in a few days. I will also be posting the bugs I found out through my testing. One is quite bad.

Chckn Wildstyle said:

By figuring out the explosive patterns of the reactors when they destabilize, I am fairly sure I have figured out the best layout for the groups of 10000. I have found a layout that will only lose 429k from its regeneration of 1.929m. A chain reaction finishing will still leave me 1.5m e/sec.

I will be posting my findings in a findings thread in a few days. I will also be posting the bugs I found out through my testing. One is quite bad.

Click to expand...

Question- Don't the explosion patterns change for every reactor shape and layout, meaning that trying to armor "where the explosions will happen" on a reactor just results in the explosions shifting location?

Of course, you can get around that by docking armor, I suppose, but people have already covered problems with that.

keptick said:

I'm saying armor layers outside AND inside of it (weaved into it). Nowhere did I mention that it'd be docked, that'd produce more lag than docked reactors.

Click to expand...

Right on. I have seen this armor weave thing on the CC section and it immediately came to mind as having possible impact with this new addition.

I really need to get my pc somewhere to update so i can check it out. I'm not against the aux reactors, just concerned about how it might actually work out. Also slightly frustrated as i was building my first ship using docked reactors. I believe my design will allow for the conversion, but I already had the reactors in place.

Lecic said:

Question- Don't the explosion patterns change for every reactor shape and layout, meaning that trying to armor "where the explosions will happen" on a reactor just results in the explosions shifting location?

Of course, you can get around that by docking armor, I suppose, but people have already covered problems with that.

Click to expand...

You are partially right in that assessment, but not completely.

Each permutation of the reactor group will explode in a "random" way, but it is not truly random as it has to follow a pathing algorithm. Whilst each pathing it does is not the exact same, the pattern is, offset by the original "completely random" initial explosion. I have repeated these experiments dozens of times so far and the only thing that changes is the initial random explosion, but the rest is very similar across all tests.

I am testing various similar permutations of the same basic shape I found to see what is the most effective.

I will go much more in depth in the thread I make about it.

Basically, the moral of the story is that nothing in game code is completely random and you can learn the effects without knowing the cause.

Chckn Wildstyle said:

You are partially right in that assessment, but not completely.

Each permutation of the reactor group will explode in a "random" way, but it is not truly random as it has to follow a pathing algorithm. Whilst each pathing it does is not the exact same, the pattern is, offset by the original "completely random" initial explosion. I have repeated these experiments dozens of times so far and the only thing that changes is the initial random explosion, but the rest is very similar across all tests.

I am testing various similar permutations of the same basic shape I found to see what is the most effective.

I will go much more in depth in the thread I make about it.

Basically, the moral of the story is that nothing in game code is completely random and you can learn the effects without knowing the cause.

Click to expand...

Non-randomness is a bug, and should already be fixed in the latest dev builds, according to Lancake.

Malacodor said:

Non-randomness is a bug, and should already be fixed in the latest dev builds, according to Lancake.

Click to expand...

I'll just have to find the next pattern then, as I said before, there is no such thing as random in code.

The problem, Chckn, is that the randomizing system can be made, like a computer RNG, to access disparate and ever-changing bits of information, like a combo of date and time, and various filesizes that are prone to change. It may have a pattern, but that pattern will be dependent on these changing numbers, and thus basically unpredictable.

Madman198237 said:

The problem, Chckn, is that the randomizing system can be made, like a computer RNG, to access disparate and ever-changing bits of information, like a combo of date and time, and various filesizes that are prone to change. It may have a pattern, but that pattern will be dependent on these changing numbers, and thus basically unpredictable.

Click to expand...

We will see how they end up doing it. I assume that it will be randomized only once off of the server clock and then use a defined algorithm afterwards, otherwise the explosions occurring would be based on the connection that person has to the server, and could be abused with lag weaponry.

Madman198237 said:

The problem, Chckn, is that the randomizing system can be made, like a computer RNG, to access disparate and ever-changing bits of information, like a combo of date and time, and various filesizes that are prone to change. It may have a pattern, but that pattern will be dependent on these changing numbers, and thus basically unpredictable.

Click to expand...

Right, there are big differences between RNGs. The current system apparently uses a bad one. Also, not rerolling after an explosion event is probably a simple oversight.

Hi Schema, when you guys mention better graphics, as much as I can agree, I have also noticed that it takes an enormous amount of Ram to load everything at once and will create huge spikes. While my new Graphic Card can handle some of the new Graphics, it still cannot handle the game Full-Throttle.
Which is quite unfortunate.

I have noticed that the loading of Blocks and such, the shadows and everything is not worth all the troubles of the lag when compared to smoothness and beauty.
I LOVE the redesign! It's FANTASTIC! However, when I compare what I could do without lag and all the dangers that the Lag presents to me, it becomes obvious that I would rather lower the graphics.
This being said, the MOMENT you lower the graphics... It takes away from all of that outrageous amount of Investment you guys put it for those graphics. And I mean Outrageous beacuse IT'S SOO FREAKING BEAUTIFUL!!!! I could drool.
I LOOVVEEEE what you guys did! It's amazing to look at!
So this is where it brings me. What could be done that would allow for a smoother loading of all the coding that it implies?
If each and every block could load a different code to differenciate the distance and the importance of each block, would that put less stress on the long run considering the amount of Blocks we can sometimes find ourselves dealing with? (IE on Planets, around several Asteroids, building humongous Stations).
If the distance could be taken into further account, as you have already demonstrated, would that allow for a smoother run of what is near, lowering the CPU's instance and allowing for a more enjoyable gameplay altogether?

Also, with all the logics that's coming into play, we have slowly been noticing a major flipside to it's creativity. Although it is absolutely GENIUS to have this within the game, I have also noticed that it's been causing crash of overloads on some servers.
I am unsure what is the cause of it but the link is defintiively between some Logics and the server's capacity.
What if we were to find a method to change the overload and have it minimalize the cost of the RAM altogether?

I did not study into any of this, I can only share my ideas as someone who use my brain daily for all sorts of tasks at my job. I have also understood that... not sharing my Ideas is the Basic points of a Companies Downfall.
Minimalizing the Costs of Financial investment in a company ought to be the major capital print on every Dev's foreheads. I do understand and recognize this.
But without discussing these ideas and possibilities, no one will ever improve or devellop new ideas.
So!
1. Graphics - Down to Good, quality - Performance... Why not both? Possible venue?
2. Complex Coding causes RAM overloading Servers Capacity causing Crashes. Possible need to re-evaluate it's potential and where you ought to be in the evolution of the game.
3. The game will grow more and more complex as time goes on, I think one of the first Priority at this point is to find out what can be done to lower the Essence of the Game to allow a smoother play-through for all the current and upcoming players.

Again, I am not in your shoes nor am I a programmer. I'm a visionnary, a Motivator, a Catalyst for growth and advancement. If what I can bring allows the team at Schine to continue ahead, I will be glad to provide what I can.

Thank you,
Thibni_Official
Motivator, Catalyst, Streamer and Promoter