Release 31 has made the game unplayable...

Quoted ya both in this response .

8 can hold it indefinitely.
Did it yesterday, only stopped because we were burned out. And we had a floater guy that really didnt need to be there, just made it quicker.
As we were leaving we were discussing that it could be done w/6.
The right six.

 

@DarkStarr @Chris Thank you very much for giving us back our mouse movement ability and also the option to unclick Free Attack in update 434

 

Until Unity fixes this , I shall just stay calm. At least we know now what is causing this. I moved my home to the wharf's and all my things last evening, and yes it was a trial, but I got it done.

 

Patch is out and the mouse control is back. Thank you all for doing this.

 

Check "Disable Cloth Sim" while wearing cloak still causing crash at scene change for me. Not wearing cloak at all actually remove the crash from me altogether.

 

Yes for me as well. I took my cloak off and checked disable cloth. Just now I left OH and crashed on my way out.

 

Ditto. Especially #4 and #6. Also monsters regenerate health points during combat far too quickly. The game is currently effectively unplayable.

 

was death touch doing less than 15-50 damage/heal before? I dunno bout earthquake but stone fist still works fine. Are these observations based on being used to dealing over a hundred damage with everything consistantly? because msot peopel couldnt do that before, onyl the people who powerleveled before playing the game. I casually got to around level 60ish and 1 GM weapon skill before this release and im not noticing any nerf to how i play (bludgeon and shields with moon magic and earth)

Tho i didnt go for any of the stuff that was considered overpowered either

 

I guess I jynxed it :'(

After the new patch, I started to get these scene load crashes again. I tried to remove cloak, check/uncheck "Disable cloth sim", but still crash occasionally. It was flawless before today's patch if I didn't wear the cloak.

 

@evillego6
Just because they're adopting a term for the public doesn't mean the state of the game has changed.

 

You're not wrong. I would suggest though that this game's development is non-traditional and therefore the game's current state cannot easily be classified as pre-alpha, alpha, or beta, which it seems is what Starr is saying in his post. An example, traditionally, balance and polishing is done primarily in the beta period. However, Portalarium seems to be working on a good deal of polishing in preparation for final wipe. There are parts of the game that can be classified in each of the traditional model's categories and it appears that the activity of the developers matches that. They aren't solely working in the pre-alpha stage, or alpha, or beta, and as such, using one of those term s to describe where they are in development is to give an I complete picture of the non-traditional approach the game is taking. I think Starr's statement that moving away from those terms is a wise one. One shouldn't purchase the game expecting there to be virtually no polish being done. They are very much working on polishing the game, as a team would in a beta phase. They also are not in a beta phase, and so calling it that, despite the polish, would be inaccurate.

The most accurate term that can describe the state of the game is pre-release or early access. It's had polish and balance done and continuing to be done. It can also see significant changes to systems within the game, can crash, has bugs. It can see new systems introduced. It might see new systems introduced even shortly after release. Given the disparity between the development teams activity and the non-traditional development cycle at time incorporating aspects from each of the traditional periods of that cycle, I'd have to say that I believe pre-alpha to be a term that is both inaccurate and faiks to do justice to the amount of polish and balancing that have been done up until now.

I would also argue that your statement could just as easily be cited by those pushing the argument that final wipe is not release. Traditionally, with MMOs, final wipe has been an integral part of release. Portalarium has disassociated those two terms. I grant them that. But people can just as easily state they are releasing at 'final wipe' and simply playing games with words to the public. That the game will be released as much as any traditional mmo would, except it will be released in an incomplete state.

I choose to accept Portalarium's own definition of where their development cycle is and what their distinction is between final wipe and release.

 

People who want you to go and flame Unity for the crashes are wrong to do so. The issue is Portalarium's fault plain and simple. They made the choice to upgrade the build to the latest Unity build. Build 28/29 didn't have this many crashes just since 30 as far as I know. Which was 2 months ago. This cloth issue wasn't an issue in 30 so that's 1 month ago. So to say that development work done in the past several months is crazy unless they need the very latest. But that doesn't seem right as other games that use Unity are doing just find using old engine versions. Every project that I was part of that had an "Engine" or "3rd Party Software" that upgraded we tested out the new version first and made sure that it introduced no critical issues. These tests went on for 2-3 months on avg before we were ready to even make "beta" builds to fully test things.

Saying this is pre-alpha is getting old. A one month release cycle should be changed in the back end to 1 month of testing internally then release to general public. This allows for more testing and fixing of these bugs. Allows you to make sure the systems work without having to be shown issues for 2 weeks into the build. The issue of "Its pre-alpha" doesn't hold water when 50%+ of your users are crashing on day one of the patch. Saying that news system would be delayed from being shown because they are held back a month is also crazy as you shouldn't be changing the core as much anymore. They say they are working on combat balance and story issues and other things that are to be "beta" phase so again why are we saying this is pre-alpha if they are doing beta fixes now?

Again we are less then 6 months away from release (If it holds to end of 2016) and we haven't done an Unity Engine freeze? This again seems very odd to me as a software dev.

 

The problem with auto attack isn't the need for an on screen indicator. My issue with it, is that once I toggle it on, I would prefer it stay on, instead... Once the enemy dies, it turns off, and as I approach the next enemy I have to hit the button again. Minor inconvenience, but it makes play a little more clunky.

 

It is in fact a Unity bug, they've confirmed it themselves. Other Unity games are a completely different level than ours, it's more complex than you realize here. We are in Early Access, so I would stick with that language if we want to be accurate.

 

I recall at the time the reason for the change in terminology had a lot to do with some confusion in the community. The change was to simply things for the public.. personally I think it was a mistake as now nobody seems to really understand just where in development the game is at. I've always thought Portalarium's definitions were relatively easy to understand but as you point out.. this is not traditional development. Though it's not too different either. A lot of people just don't know what to expect and at least from my perspective seem to think new features should be polished as they're released.. or very close. "Early Access" says nothing in of itself as where development is and it's easy to assume everything is farther along.

Lot of folks are used to seeing games in a beta state and nothing before that. So perhaps that's all they have to compare SotA to? Well.. can speculate on that all weekend.. As I said I get the 'final wipe' argument but it shouldn't apply in this case as Portalarium has been very clear about that.

 

You seem to forget that a s***tload of people demanded the new Version of Unity over and over again.
Because....hell I don't even know why Port used Unity in the first place. But that's a different topic.

 

Also the issue with memory access violation in Unity has been around even back in 2014 ( I remember Kerbal Space Program had the same issue with their Unity 4.5.x). So revert back the code wouldn't do much since it's the bug on the engine core (using 32-bit data on 64-bit application). The best thing to do is to continue working on the content and let Unity fixed their things. If the crashes start to be prevalent, then isolate and disable the features that could trigger the crash (cloth sim is just one of them).

 

This following was not included in patch notes prior to R29:

So that means between R29 and R30 they upgraded the Unity engine to what was being used today from what was being used.

What I think your talking about is the upgrade to Unity 5 that was done back in R15. I haven't seen people demanding the latest Unity. KSP which uses Unity hasn't even upgraded to 5.4 yet they are waiting on the next major release to do that.

 

There isn't just one golden bug that one you fix it everything will be all good. The memory leak issues are not quite the same as memory access violation. For SotA, they switch to Unity 5 in order to utilize multi thread processing and the "better textures", which is biting them with the 32-bit to 64-bit address conversion issue right now.

As for KSP, they have issue when their Unity was way back to version 4.5 (FYI http://forum.kerbalspaceprogram.com/index.php?/topic/86583-access-violation/)

There are other games that run into the same issue (e.g., Planet Explorers got hit hard by Unity crash as well).

The best thing Port could do is to try to work around the portion that would cause crash once they can identify it. Unfortunately, they had to fly Unity engineer to do the debugging at their office to pin point this issue.

Anyway, my point is reverting wouldn't really be a feasible solution if we don't want to hit a hiatus in development until Unity solve this core issue.