Suggestion Changelog for dev-versions

[tomorrow]

Hey i, like many other players are interested in a development version change log, where all new features are listed that have been added to the game, as also bug-removals and feature-removals. So that we are all up2date to the game and even people without having purchased the game (which do not have access to the dev-versions) know that is coming soon and what problems have been solved. This can also give more feedback and suggestions, and as always maybe solve problems.

Thank you in advance for your time and patience

tomorrow

 

[AndyP]

The dev-versions serve one purpose:

Test 'stub'-features and make a guess on how useful they may be, and have a small team of testers and developers test those, to see issues or problems with the mechanics behind it.
Sometimes features get revoked in total.

But its all a very dynamic process going on between the development and testing.

Some phases also run down the way to only add and program stuff that is already discussed
and planned in detail to the end. And the dev-builds are only for sneak previews on them, to request
comments and get a few internal suggestions. (Or sometimes for special events only)

Just to give a rough estimation on that:

starmade-build_20140404_200842.zip 04-Apr-2014 20:11 155M
starmade-build_20140409_142108.zip 09-Apr-2014 14:23 156M
starmade-build_20140413_190743.zip 13-Apr-2014 19:10 150M
starmade-build_20140430_152323.zip 30-Apr-2014 15:26 153M
starmade-build_20140501_150434.zip 01-May-2014 15:07 153M
starmade-build_20140502_093424.zip 02-May-2014 09:37 153M
starmade-build_20140502_113112.zip 02-May-2014 11:34 153M
starmade-build_20140502_143208.zip 02-May-2014 14:35 153M
starmade-build_20140503_162540.zip 03-May-2014 16:28 153M
starmade-build_20140504_091500.zip 04-May-2014 09:18 153M
starmade-build_20140504_111151.zip 04-May-2014 11:14 153M
starmade-build_20140504_200632.zip 04-May-2014 20:09 153M
starmade-build_20140505_163940.zip 05-May-2014 16:42 153M
starmade-build_20140506_153021.zip 06-May-2014 15:33 153M
starmade-build_20140506_201135.zip 06-May-2014 20:14 153M
starmade-build_20140507_172255.zip 07-May-2014 17:25 153M

Are the builds since release.
16 and counting, as we are entering the 'fix-phase' to go towards release.

This needs many code changes that may break the game or even your universe while testing for a fix.
They are not meant for anything else than testing specific functions on their behavior change and confirming fixes. Sometimes they have only added a few more log-messages to catch a reproducible bug better.

You do not have any benefit on 'using' them, without being part of the development-cycles that require them.

It is also a 'rumor' dev-builds are only accessible by 'purchased game owners'.
This is not true and has nothing to do with it. It is really commonly known where those dev-builds are and also the credentials are far away from 'hidden' or 'secret'.

This rumor is most likely based on the fact the dev-builds will be restricted to a closed group of people in the future. This meant: Developers, Testers and maybe other people of importance to starmade. (Like Bench doing the videos on logic gates, to have them 'ready' on release.)

Planned are 3 levels of releases:
Dev - Only available to people involved into development and bug-testing
Pre/ReleaseCandidates: Available for public testing. (May be 'beta' for steam-users)
And finally the Releases. distributed by the Launcher/Steam.


As for know, you can easily use the bug-tracker that is in use for a while now to see when bugs got fixed and even see things that are currently being worked on.

A small set of default filters allows easy navigation through it:

• All bugs (current Release)
• All bugs (incl. Dev-Build)
• New in Dev-Builds
• New in latest release
• What's new? (last 7 days)

There is also a small chance you can provide useful help with the dev-builds or to the bug-hunting in general by answering the issues that require public feedback.
Also anyone is invited to add issues.

So summarized:
There is no real need for this, unless you are involved into development.


- Andy

 

[tomorrow]

thx that was very interesting to read
now you even answered all my questions xD

 

[Valiant70]

Regardless of features getting revoked or my own access to anything, I would like to have a change log of the dev builds because I am curious about the state of development.

This rumor is most likely based on the fact the dev-builds will be restricted to a closed group of people in the future. This meant: Developers, Testers and maybe other people of importance to starmade. (Like Bench doing the videos on logic gates, to have them 'ready' on release.)

Planned are 3 levels of releases:
Dev - Only available to people involved into development and bug-testing
Pre/ReleaseCandidates: Available for public testing. (May be 'beta' for steam-users)
And finally the Releases. distributed by the Launcher/Steam.

I am very strongly against any secrecy about or restricted access to these test builds. Hiding things does not help anything and may rule out useful input from the largest body of testers available, the player base at large.

If you're worried about making some idiot cry when you remove a feature, you shouldn't worry about that. Missile addicts will scream when the PD bug fixes come out. Some people even complained about the rail update. People always get upset for no reason, and hiding things from them is doing them no service.

 

[AndyP]

This topic is kind of old,
however,
playing around with half-done features that save corrupted blueprints that may crash servers on upload, or just corrupt your world and cause follow up issues, making it almost impossible to track down a future problem back to this, does not help anyone.
Within the tester group, we can communicate to remove/resave all blueprints from dev-build XYZ, but asking the public to do this, when they all play around with them, wont work out, and some of those maybe used to harm other players.

Any feature that is sort of ready to play around with, would then get a pre-release to allow server-owners and other players to check their game for problems with the update in a testing environment. IF they find anything, they know for sure that its worth reporting it.
Current example of this:
To have a good way to test HP-Systems in their early stages, any shot to a ship ignored shields for 2-3 dev-builds, we got countless reports "shields are broken" or complaints like "HP will replace shields? Noooo" when trying to explain this is intended, most of them got upset and even yelled at us "How could disabling shields be intended in any way?"
All stuff we do not want to waste our time with, it leads to nothing than having to explain the same things over and over again.

Finally:
We did not split this up in leveled access yet, anyone can access any dev-build, so no need to complain about this. =)

- Andy

 

[Valiant70]

Within the tester group, we can communicate to remove/resave all blueprints from dev-build XYZ, but asking the public to do this, when they all play around with them, wont work out, and some of those maybe used to harm other players.

If desired, blueprints could have a tag added that tells what build they were saved in. Servers could enable or disable the ability to upload blueprints from dev or pre-release versions.

Any feature that is sort of ready to play around with, would then get a pre-release to allow server-owners and other players to check their game for problems with the update in a testing environment. IF they find anything, they know for sure that its worth reporting it.
Current example of this:
To have a good way to test HP-Systems in their early stages, any shot to a ship ignored shields for 2-3 dev-builds, we got countless reports "shields are broken" or complaints like "HP will replace shields? Noooo" when trying to explain this is intended, most of them got upset and even yelled at us "How could disabling shields be intended in any way?"
All stuff we do not want to waste our time with, it leads to nothing than having to explain the same things over and over again.

These freak-outs sound like newspaper headlines... Might need to add a warning and a "quiz" before allowing public access to dev builds. One multiple-choice question:
"There's a bug, or I really hate something in the dev build. What should I do?"

• Freak out and scream at the Schema over the forum
• Calmly submit a bug report or a polite suggestion thread IF someone hasn't already
• Check starmade dock chat for any Schine team members and bring it up there
• Rage quit. There's nothing I can do about it.

The second choice would obviously be the correct one. This would prevent vegetative humans from playing dev builds and reduce the number of dramatic newspaper headline comments.

You're obviously in charge of things and have to do what you consider most beneficial, but these are my thoughts on the matter.

 

[AndyP]

If desired, blueprints could have a tag added that tells what build they were saved in. Servers could enable or disable the ability to upload blueprints from dev or pre-release versions.

They have a tag telling the "blueprint-format-version".
The need for a reverse tracking of versions if they belong to a dev, pre or release version would be quite a bit of overhead for the server, however, almost all release versions were published as dev-build before. So this would not really work, with adding a specific "build-type-tag" that wont have any real use at all, as quite a big portion of blueprints around are from a dev-build or were started in a dev-build to be ready by the time the features hit release.

These freak-outs sound like newspaper headlines... Might need to add a warning and a "quiz" before allowing public access to dev builds. One multiple-choice question:
"There's a bug, or I really hate something in the dev build. What should I do?"

• Freak out and scream at the Schema over the forum
• Calmly submit a bug report or a polite suggestion thread IF someone hasn't already
• Check starmade dock chat for any Schine team members and bring it up there
• Rage quit. There's nothing I can do about it.

The second choice would obviously be the correct one. This would prevent vegetative humans from playing dev builds and reduce the number of dramatic newspaper headline comments.

You're obviously in charge of things and have to do what you consider most beneficial, but these are my thoughts on the matter.

It may sound a bit over the top, but those were real things we got faced just within the last few weeks.
However, anyone is welcome to play dev-builds and visit our official testserver(s), in case you have some errors with the game, or stuff does not seem to work, someone there can usually give a short feedback about the status in the form:
"feature not done yet"
"already reported"
or
"never seen it, may you show it to me?"
while the last one, will lead to a forward to either support if its a problem with the system, or a report request if its a valid new thing, we were not aware of.

So, usually when you play dev-builds and want to get into contact about issues you encounter, there are many ways to do so, and using the bug-tracker, support or writing a direct message to me or Lancake leads to a qualified answer for your problem.

And as this worked for quite a while now, there IS no restriction in dev-builds and its delayed/discarded until we really see a need for it.

- Andy

 

[Valiant70]

and its delayed/discarded until we really see a need for it.

Well, hopefully the need will not arise at least during the Alpha stages of the game when development is highly interesting and the community is greatly involved.

 

[Xtremesonicboom]

This topic is kind of old,
however,
playing around with half-done features that save corrupted blueprints that may crash servers on upload, or just corrupt your world and cause follow up issues, making it almost impossible to track down a future problem back to this, does not help anyone.
Within the tester group, we can communicate to remove/resave all blueprints from dev-build XYZ, but asking the public to do this, when they all play around with them, wont work out, and some of those maybe used to harm other players.

Any feature that is sort of ready to play around with, would then get a pre-release to allow server-owners and other players to check their game for problems with the update in a testing environment. IF they find anything, they know for sure that its worth reporting it.
Current example of this:
To have a good way to test HP-Systems in their early stages, any shot to a ship ignored shields for 2-3 dev-builds, we got countless reports "shields are broken" or complaints like "HP will replace shields? Noooo" when trying to explain this is intended, most of them got upset and even yelled at us "How could disabling shields be intended in any way?"
All stuff we do not want to waste our time with, it leads to nothing than having to explain the same things over and over again.

Finally:
We did not split this up in leveled access yet, anyone can access any dev-build, so no need to complain about this. =)

- Andy

To be fair, the way Andy is talking about doing version types in the future is very similar to the way Minecraft does its versioning. There are a bunch of builds that the Minecraft community never sees, as the developers go through and test things. After they've added a group of features, they package it into a snapshot version that they release to the public so they can have a large sample size to capture as many bugs as possible. And then, after a few snapshots full of features that were added to see how the community would respond and bugs that get fixed, a release version comes out that contains most or all of the features from the snapshots, and all the bug fixes. This approach to version access is nothing new, and, in my opinion, is the most logical way to set it up.

Regardless of features getting revoked or my own access to anything, I would like to have a change log of the dev builds because I am curious about the state of development.

I am very strongly against any secrecy about or restricted access to these test builds. Hiding things does not help anything and may rule out useful input from the largest body of testers available, the player base at large.

If you're worried about making some idiot cry when you remove a feature, you shouldn't worry about that. Missile addicts will scream when the PD bug fixes come out. Some people even complained about the rail update. People always get upset for no reason, and hiding things from them is doing them no service.

If desired, blueprints could have a tag added that tells what build they were saved in. Servers could enable or disable the ability to upload blueprints from dev or pre-release versions.


These freak-outs sound like newspaper headlines... Might need to add a warning and a "quiz" before allowing public access to dev builds. One multiple-choice question:
"There's a bug, or I really hate something in the dev build. What should I do?"

• Freak out and scream at the Schema over the forum
• Calmly submit a bug report or a polite suggestion thread IF someone hasn't already
• Check starmade dock chat for any Schine team members and bring it up there
• Rage quit. There's nothing I can do about it.

The second choice would obviously be the correct one. This would prevent vegetative humans from playing dev builds and reduce the number of dramatic newspaper headline comments.

You're obviously in charge of things and have to do what you consider most beneficial, but these are my thoughts on the matter.

You bring up very good points, but usually the best solution to a problem is the simplest one. How much coding would it take to add a "Dev Version Qualification" quiz to the website or the launcher? How much coding would it take to add another entry into a blueprint telling what version type it was made in? As stated earlier, the snapshot versions (called Release Candidates in this case) would be your best view into the development process. It's great to be interested in the development of the game, and consider how much more information we get compared to a big ticket title like... Eve: Online for example. I'm sure there's a changelog for Eve: Online with all the features and bug fixes, but you'd have to do some digging to find it. One last point. The distinction between bugs and features, where it isn't utterly game breaking, is extremely blurry, and is up to a combination of the developers and the community to decide on. An example in Minecraft is BUD switches in redstone. This is most certainly a bug, but so many members of the community have taken advantage of it that it's become a feature, and the devs have given up on removing it.

As much as it sucks, ignorance is bliss for many people and they might be better off not knowing the steps for testing the new features, and instead would benefit from only seeing the features in their complete state. I'm not trying to hurt anyone's feelings, that's just the way it goes.

 

[AndyP]

Initially we had this system with 3 layer access in mind, but for the sake of simplicity we keep our current system, with releases and dev as indication.

If you frequently play dev-builds it would be best to play on our testserver(s) and get in contact with us this way.
After some time, we usually make contact with you by other more direct ways.

So the need for special permissions is not really needed, as we do not want to prevent people from trying the new features and get an idea what they will look like.
The only thing you need to know, and this is general for all development systems:
Once you enter the dev/nightly builds you get used to features that others did not yet get the hands on, but every update has a risk that you configuration breaks.


- Andy