Prerelease v0.200.250

[LoSboccacc]

I'd say it's about time we get some official work from schine about this whole mess

 

[MacThule]

I'd say it's about time we get some official work from schine about this whole mess

Eh. They will say the new system is new, it's pre-release, it has bugs to work out, and will make more sense when it's fully implemented. Then they will update the roadmap to us. Waste of time. It solves nothing to ask for additional explanations from them.

Making them stop whatever it is they are doing to devsplain to us why it's not so bad isn't likely to change the situation (they've already invested almost an entire year into this rebuild), it's just going to slow down an already incredibly slow development process. I would rather they don't say a word, and either get on with making the new system work, or reverting stuff.

Last thing I want is them to be spending more time conferencing back and forth and swapping memos about how to present this stuff to us instead of focusing on code. I don't care about the story, I just want to see improvements.

More action, less committee!!!

That's me, anyway.

 

[JinM]

Anything new in the .277 dev-build?

 

[Nosajimiki]

I think StarMade kind of became this sort of side project a little team works on when they get bored, tweaking it and adding things to it every now and then. I know programming but don't know Java so can't tell how complicated it can get but from my perspective the whole thing seems like as i just described it. There is no other plausible explanation for such long development time i can think of other than that and don't come to me with the "it was a mass back then, they didn't have a team just one guy worked on it" crap because the pace of development is just as slow as it was back then if not slower.

I understand developing the current system is a bit more complicated and it requires a complete rewrite of the previous but there was a code which was already working in a way and if you know how it worked and build on it the revamp of it should absolutely not take that long even if we take into account the constant tweaking on the numbers to get the most desirable results after the base code is done.

I don't want to hurt the feelings of others but i'm just going to with the following:
This is an amateur dev team working in an amateur way on an amateur game. Might as well loop the 'amateur' for each statement which can be made on this game.

Other than that the potential is very much there hence the reason i keep coming back every now and then checking on how things are going around here. Get a bit disappointed each time on how long things take to progress but always leave with a bit of hope left in me.

Programing in lower level languages is a lot more time consuming than using a game engine (Unity, Game Maker, etc). Furthermore, games like this that are super math intensive generally tank if you try doing everything using fancy frameworks and libraries which normally also expedite development. I can't speak to Schine's level of expertise in low-level development, but based on the kinds of optimisations we've seen over the years, I can pretty much guarantee that he at a minimum dabbles in customising his libraries if not rewriting them all together.

Me and my brother once wrote a game that took 5 years to get out of alpha because we had to write pretty much everything from the ground up just to make it performant, and that was without a testing team constantly throwing exploit reports in our way... so yes, games do take this long. The only games that don't take this long are the ones that are built on top of existing frameworks, stupidly simple ones, and games with massive development teams.

Also don't forget, just because a major company can push out a polished looking game in 2-3 years from when they announce the beginning of development doesn't mean they did not spend years before that planning it out.

To expand on an earlier idea:

Compliment the new power and stabilizer system (and simplify the stabilizer math) by creating 3 types of reactor blocks, like the 3 types of armor. This will effectively result in 3 classes of starship, and eliminate the need to rescale your design every time you add reactor blocks.

Basic reactor blocks will have the highest output per block (2x) and the lowest power cap - hard cap at maybe 10K. They will be made in basic factories and cost the least. The stabilizer distance for basic reactors will be a constant "25m". If you stabilize at this distance you are 100% stable - under this distance 25% stable.

Standard reactor blocks will have lower output per block (1x) and a higher power generation cap - maybe 100K. These blocks will cost more than basic blocks and be manufactured in the standard factory. The 100% stabilizer distance for standard reactors will be a constant "75m".

Advanced reactor blocks will have lower power output per block (x0.5) than standard blocks and cost more per block, but have a higher power cap - maybe 1mil. The 100% stabilizer distance for advanced reactors will be a constant "150m".

Stabilizer math will be friendlier. 3 different hard power caps will allow different sizes of starship, while limiting the incentive to endlessly fill with more power and systems.

Potentially the 3 different scales could even receive different chamber options.

This would probably be a more awkward system than you think it is, and really be a problem with its hard caps. Frankly, if they were to introduce multiple reactor types, I would prefer much more of a flavor based system where they are different solutions to the same problem (like choosing between cannons beams and missiles), but effectively have the same equivalent value. For example:

Fusion Reactor: Low efficiency, does not need to be centralized, but don't explode (good for their high redundancy)
Anti-Matter Reactor: Higher efficiency when in large groups, but they explode (like current Aux)
Solar Reactor: High efficiency near stars but needs to be placed on outside of ship, very low efficiency in the void.
Complex Reactors: Some more difficult to design reactor using a lot of block types in complex configurations to gain medium efficiencies. Since they need all parts working in tandem, losing one subsystem could cripple power regen, but they don't outright explode.

I also think this kind of system would be best if you could have multiple kinds of reactors working at once like having a complex reactor at your core supplemented by solar reactors on your wings. Frankly as long as the power system never favors multiple small reactors over 1 big one from an efficiency perspective, forcing one power core is totally unnecessary and annoying.

 

[Matt_Bradock]

Ratchet Hundreda Sometimes it takes even AAA dev studios to make a game and the end result might even suck. There's a symbol of prolonged development in the gaming world and that is called Duke Nukem Forever, which took 12 years and flopped on release. Prey (2006) took 11 years to complete by a major game studio - and at least it was successful. Even games that do not have to start from scratch (e.g. make their own graphic and physics engine like Schema has) and license an engine/dev environment (for example Star Citizen that uses a modified CryEngine 3) can take a really long time to finish development even with a large, triple A studio. And here we're talking about one man doing everything for the first couple years.
That said, maybe Schema should listen to the others a little less, as I'm pretty damn sure the complete revamp of power and decisive game mechanics was NOT his idea.

 

[Lecic]

Eh. They will say the new system is new, it's pre-release, it has bugs to work out, and will make more sense when it's fully implemented. Then they will update the roadmap to us. Waste of time. It solves nothing to ask for additional explanations from them.

Making them stop whatever it is they are doing to devsplain to us why it's not so bad isn't likely to change the situation (they've already invested almost an entire year into this rebuild), it's just going to slow down an already incredibly slow development process. I would rather they don't say a word, and either get on with making the new system work, or reverting stuff.

Last thing I want is them to be spending more time conferencing back and forth and swapping memos about how to present this stuff to us instead of focusing on code. I don't care about the story, I just want to see improvements.

More action, less committee!!!

That's me, anyway.

So, the reason we shouldn't stop them from pushing a crappy system into release is because... they sunk a bunch of time into it? Is that what I'm reading here?

Nevermind that over half the team isn't even coders and could easily write up an explanation of their path forward while the coders continue to do their work....

 

[Matt_Bradock]

So, the reason we shouldn't stop them from pushing a crappy system into release is because... they sunk a bunch of time into it? Is that what I'm reading here?

Apparently. People tend to associate time and effort with quality, which is USUALLY the case but NOT always. Boyhood was filmed for 12 (or more) years and managed to become a movie about... nothing important, really. Incohesive, boring, average. But it was praised by critics because OMG IT TOOK 12 YEARS SO GOOD.

 

[The_Owl]

Apparently. People tend to associate time and effort with quality, which is USUALLY the case but NOT always. Boyhood was filmed for 12 (or more) years and managed to become a movie about... nothing important, really. Incohesive, boring, average. But it was praised by critics because OMG IT TOOK 12 YEARS SO GOOD.

tbh if a Stanley Kubrick movie took that long it'd likely be really bloody good.

 

[MacThule]

So, the reason we shouldn't stop them from pushing a crappy system into release is because... they sunk a bunch of time into it? Is that what I'm reading here?

I'm all about speaking up on the quality of their changes - as much as you have time to comfortably burn on that, anyway. In my experience of life in general though, people aren't likely to retreat from this kind of investment. That's not approval of a mistake, that's realism about human nature. They will qualify the changes, explain away problems with it, offer to adjust some details, etc, but these are real humans with real egos. If they didn't back up when they first suggested this last year and the testers/players raised red flags about it for weeks, then they aren't going to now that they've invested substantial time (money) into it. Humans don't generally work that way. The vast majority of the time, anyway. Not in my experience. There obviously are exceptions.

Call it "a prediction," if you want, based on seeing analogous collective actions IRL over the decades. I'm not saying they shouldn't swerve, only that they will not. Not hard enough, anyway. Maybe enough to make a show of swerving... but that's probably it.

Which is why I don't want an itemized explanation from them about it; it's a waste of time. Actions speak louder than words.

I'm tired of seeing official documents from them about what is planned ("perhaps 7 years from now, we may begin to implement crew... maybe. after power 3.51"). I certainly don't want to see a document about "why" they did what they already did. What use is that? They've explained their actions in detail to us before and it amounted to nothing practical. It changes nothing, except a few opinions. They literally spent months in committee with us about Power 2 and all it did was delay the inevitable suck by that many more months.

Yes; they have several non-coders, but in order for those individuals to write the content (accurately) they'll have to extensively interview the coders about it. They can't just make it up; they need approved, official descriptions and details. That is unavoidable. So it's a distraction, it will eat a chunk of what seems to be precious little monthly work time time, and it's just red tape. We can respond to what they are showing us in the pre-release without extensive documentation (which will inevitably be rejected by at least some members of the community anyway - you can never actually please all the people).

I'm expecting no major change to new systems because it's been made obvious (to me) by actions that there is a big-picture plan in effect and only compromises which do not threaten the end-goal will even be considered. All language to the contrary of actions is just smoke to keep the bees sleepy.

That's fine. Schine will apparently drive as they please; I think too many people here are embracing a delusion of agency in the development of SM based on the fact that Schine does pay attention to its playerbase. Listening doesn't mean obeying; I listen to dudes I spar with because it cues me to emotional state, that doesn't mean I'm using that info to give them what they want. So I just really don't want to pull over right now and have another giant fucking chit-chat & group bitch-session about why we turned left instead of right back at the last intersection when we already argued about it extensively a year ago and it changed almost nothing. I just want to see foot on gas and shit flying past outside my window so I can get a better idea of whether or not the set destination is going to be someplace I want to go.
[doublepost=1515099657,1515099342][/doublepost]

tbh if a Stanley Kubrick movie took that long it'd likely be really bloody good.

Too bad we don't have Kubrick's shade on the dev team...

 

[Sachys]

They literally spent months in committee with us about Power 2 and all it did was delay the inevitable suck by that many more months.

I seem to remember posting THIS around the start of that.

 

[Lecic]

I'm all about speaking up on the quality of their changes - as much as you have time to comfortably burn on that, anyway. In my experience of life in general though, people aren't likely to retreat from this kind of investment. That's not approval of a mistake, that's realism about human nature. They will qualify the changes, explain away problems with it, offer to adjust some details, etc, but these are real humans with real egos. If they didn't back up when they first suggested this last year and the testers/players raised red flags about it for weeks, then they aren't going to now that they've invested substantial time (money) into it. Humans don't generally work that way. The vast majority of the time, anyway. Not in my experience. There obviously are exceptions.

Call it "a prediction," if you want, based on seeing analogous collective actions IRL over the decades. I'm not saying they shouldn't swerve, only that they will not. Not hard enough, anyway. Maybe enough to make a show of swerving... but that's probably it.

Which is why I don't want an itemized explanation from them about it; it's a waste of time. Actions speak louder than words.

I'm tired of seeing official documents from them about what is planned ("perhaps 7 years from now, we may begin to implement crew... maybe. after power 3.51"). I certainly don't want to see a document about "why" they did what they already did. What use is that? They've explained their actions in detail to us before and it amounted to nothing practical. It changes nothing, except a few opinions. They literally spent months in committee with us about Power 2 and all it did was delay the inevitable suck by that many more months.

Yes; they have several non-coders, but in order for those individuals to write the content (accurately) they'll have to extensively interview the coders about it. They can't just make it up; they need approved, official descriptions and details. That is unavoidable. So it's a distraction, it will eat a chunk of what seems to be precious little monthly work time time, and it's just red tape. We can respond to what they are showing us in the pre-release without extensive documentation (which will inevitably be rejected by at least some members of the community anyway - you can never actually please all the people).

I'm expecting no major change to new systems because it's been made obvious (to me) by actions that there is a big-picture plan in effect and only compromises which do not threaten the end-goal will even be considered. All language to the contrary of actions is just smoke to keep the bees sleepy.

That's fine. Schine will apparently drive as they please; I think too many people here are embracing a delusion of agency in the development of SM based on the fact that Schine does pay attention to its playerbase. Listening doesn't mean obeying; I listen to dudes I spar with because it cues me to emotional state, that doesn't mean I'm using that info to give them what they want. So I just really don't want to pull over right now and have another giant fucking chit-chat & group bitch-session about why we turned left instead of right back at the last intersection when we already argued about it extensively a year ago and it changed almost nothing. I just want to see foot on gas and shit flying past outside my window so I can get a better idea of whether or not the set destination is going to be someplace I want to go.
[doublepost=1515099657,1515099342][/doublepost]

Too bad we don't have Kubrick's shade on the dev team...

I agree with you that Schine probably won't change their course. I'm just not defeatist enough to stop trying.

 

[MacThule]

I agree with you that Schine probably won't change their course. I'm just not defeatist enough to stop trying.

That's cool. We gotta push, for sure. An organized, well-represented "party" of players could probably even sway at least some solid compromises.

I haven't given up. Not on having a little effect anyway - I've totally watched Schine listen on some issues and fix some problems (trade network and shop, for example). The only thing I am against is demanding more words from Schine. I would rather see actions. Make the pre power work in some decent way, soon, or get it the hell out of here post haste. No more explanations.

Do you think another detailed statement of intent about why P2.0 is the way it is will help?

That is what I am super sceptical of, and since it costs time... I would rather demand faster change than more words.

 

[LoSboccacc]

That's cool. We gotta push, for sure. An organized, well-represented "party" of players could probably even sway at least some solid compromises.

don't we have a council? which side are they on? somehow I fear they're the one that brought this mess upon us

 

[MacThule]

don't we have a council? which side are they on? somehow I fear they're the one that brought this mess upon us

The senate has been, indefinitely, dissolved...

 

[Lecic]

Do you think another detailed statement of intent about why P2.0 is the way it is will help?

That is what I am super sceptical of, and since it costs time... I would rather demand faster change than more words.

If they're not making changes they should tell us. Doesn't take more than a minute to put up a post that says "we are not fundamentally changing the stabilizer system and it's going to be like this in release." If they are making changes, they should tell us what those changes are, so we can offer feedback.

Pushing a shitty mechanic to full release is a bad idea, because then it has a LOT of inertia. A full release mechanic now has everyone designing their ships for it, and it's even harder to get bad things fixed. I am 100% opposed to pushing mechanics to release for the sake of it. We need the devs to tell us what they are doing so we can give them feedback so a mechanic is good BEFORE it is implemented.

 

[Crimson-Artist]

If they're not making changes they should tell us. Doesn't take more than a minute to put up a post that says "we are not fundamentally changing the stabilizer system and it's going to be like this in release." If they are making changes, they should tell us what those changes are, so we can offer feedback.

Pushing a shitty mechanic to full release is a bad idea, because then it has a LOT of inertia. A full release mechanic now has everyone designing their ships for it, and it's even harder to get bad things fixed. I am 100% opposed to pushing mechanics to release for the sake of it. We need the devs to tell us what they are doing so we can give them feedback so a mechanic is good BEFORE it is implemented.

schines seeming inability to post regular news updates is made all the more laughable when you consider the way other games like Empiryon handle their update announcements.

The Empiryon devs actually regularly make posts whenever their newest dev build is up for testing and they even bother put up an EXTENSIVE change log that lists EVERY SINGLE CHANGE. Whats even more insane is that they immediately update the dev build news post when a new dev version is released. And they even bother to write a changelog even for those no matter how minute the change. The MAD MEN!

 

[MacThule]

If they're not making changes they should tell us. Doesn't take more than a minute to put up a post that says "we are not fundamentally changing the stabilizer system and it's going to be like this in release." If they are making changes, they should tell us what those changes are, so we can offer feedback.

Pushing a shitty mechanic to full release is a bad idea, because then it has a LOT of inertia. A full release mechanic now has everyone designing their ships for it, and it's even harder to get bad things fixed. I am 100% opposed to pushing mechanics to release for the sake of it. We need the devs to tell us what they are doing so we can give them feedback so a mechanic is good BEFORE it is implemented.

True and true. Some brief clarification about their position would be informative. I'd prefer it if they don't go issue a big statement or go through and fully update the road map right now though.

 

[Raisinbat]

schines seeming inability to post regular news updates is made all the more laughable when you consider the way other games like Empiryon handle their update announcements.

I went back into factorio, tried the stable version first and noticed the password input for joining a passworded server wasn't automatically active. Then tried the unstable branch for the new terrain generation and lo and behold it was fixed! I remember getting irritated with it; "Why would they fix such a minor UI issue instead of working on the real issues?!?" i thought, then had to smack myself after realising it wasn't starmade.

 

[Matt_Bradock]

Here's the real thing I don't really understand.

Up until now, Schema preferred dinamically scaling systems that only depended on how you build them. The whole reason behind the weapon update was to make it simple yet effective, no sliders or unnecessary BS, the range and behavior of the system being entirely dependent on the type and ratio of the blocks placed. Same with the defensive effects. This, and the fact you could place most systems however and wherever you wanted them (aside power gen and caps) offered unparallelled creativity as people could literally build anything and make it work. We have seen vertical ships, horizontal ships, sleek elongated ships, blocky, chubby ships, and all of them worked independent of size and shape. We only had to place the blocks and didn't have to care about a dozen different GUIs to even turn the damn thing on. All we needed was the weapons menu and the quickbars.

This update goes against everything in the previous direction. We have discrete block counts on the chambers, with 0 flexibility (it either works or doesn't depending on whether you match the exact block count or not) we have very specific directives on how to place each and every system due to new scaling, reactor-stabiliser-chamber relations and structural integrity, some designs are outright impossible to do right, and we have yet another complex GUI to learn to replace systems that were already in place and functional instead of improving on the already existing framework. The choice of discarding years of development for something completely different and way more complicated that was made from scratch is at least questionable. So, no wonder we don't really get it. Because this goes against the very thing that makes this game great, which is the unlimited creative options yet relative simplicity.

 

[Kelpaz]

The best thing that happened in the dev builds so far is the comeback of sounds.

I could "live" with power 2.0 if it wasn't for all the added extra weight.

We got stabilizer streams, an abomination from beyond the depths of frame hell.

Shield bubbles are back again limiting ship builds.

Integrity because nothing makes a ship better than making it out of explodium and restricting decorative use of thrusters.
At this point, I wonder if it's really worth it.

A side effect of the new shields is that making modular stations will be impossible to shield, unpowered docks means the station has to power everything connected and this is a huge problem since I made docking stations as a modular part to attach ships to my smaller stations.

We were also told that there would be a grace time were "new power" and "Old power" could coexist is that still happening?

Can we also get toggles for balancing our servers, examples would be:

USE_BUBBLE_SHIELDS=TRUE/FALSE
ALLOW_POWERED_DOCKS=TRUE/FALSE
SYSTEM_INTEGRITY_CHECK=TRUE/FALSE

These things should be server options not forced upon everyone.