My 300 series ships seem to kill servers?

[NaffNaffBobFace]

Played on three different servers this morning and all 3 crashed after players blew up my 300's... Was in a 350R twice and a 315p once.

First time the 350R did its usual thing of exploding and leaving me in the seated position. So I just sat there pushing every button on the keyboard and then just talked on chat for about a minute and then crash to desktop taking everyone on the server with me as the option to rejoin did nothing when I came back. Okay, a one off, might not have been me.

Second time was in a 315p, I advised in chat what happened with the 350R and that i'd appreciate it if no one blew me up as it might kill everybody. Flew over Jump Town, guy in a saber blew me up. Instead of being in the seated position I re-spawned in a bed in Olisar but couldn't move, couldn't use inner thoughts, pressing H did nothing. Chat didn't work and suddenly no one was using it. Force quit and coming back no option to rejoin the server, it was dead too.

Okay, so this is becoming a bit of a running theme thinks I.

So I jump in my 350R, book it over to Jump Town and just as I'm making my initial flypast to scope out the scene the game freezes, force-quit, no option to rejoin server, can only assume I was one-shot from below.

Is the 300 series killing servers in revenge for it being killed?

 

[mindfart]

This should be an add-on for every ship.
Like, the fuck you module.

 

[Kiladyn]

lol right now I cant even play, the 3.4.3 update made me start getting the error 30000 between loading into the server and like maybe 3 minutes in the server.

 

[Lorddarthvik]

Played on three different servers this morning and all 3 crashed after players blew up my 300's... Was in a 350R twice and a 315p once.

First time the 350R did its usual thing of exploding and leaving me in the seated position. So I just sat there pushing every button on the keyboard and then just talked on chat for about a minute and then crash to desktop taking everyone on the server with me as the option to rejoin did nothing when I came back. Okay, a one off, might not have been me.

Second time was in a 315p, I advised in chat what happened with the 350R and that i'd appreciate it if no one blew me up as it might kill everybody. Flew over Jump Town, guy in a saber blew me up. Instead of being in the seated position I re-spawned in a bed in Olisar but couldn't move, couldn't use inner thoughts, pressing H did nothing. Chat didn't work and suddenly no one was using it. Force quit and coming back no option to rejoin the server, it was dead too.

Okay, so this is becoming a bit of a running theme thinks I.

So I jump in my 350R, book it over to Jump Town and just as I'm making my initial flypast to scope out the scene the game freezes, force-quit, no option to rejoin server, can only assume I was one-shot from below.

Is the 300 series killing servers in revenge for it being killed?

I'd say no, your 300s aren't killing the servers. All the issues you mentioned happened to me in auroras and mustangs and my friend was still on the server just fine. It sounds more like your client getting de synced. Common issues.
It would be funny though. Put it in the patch notes that 300s kill servers and now all 300s are either very safe or get trolled to kill the servers. Oh the glorious chaos that would ensue lol

300s are a mess and have been for some time, with 3.5 rework around the corner I don't think they will fix it either.

 

[Vavrik]

I'd say no, your 300s aren't killing the servers. All the issues you mentioned happened to me in auroras and mustangs and my friend was still on the server just fine. It sounds more like your client getting de synced. Common issues.
It would be funny though. Put it in the patch notes that 300s kill servers and now all 300s are either very safe or get trolled to kill the servers. Oh the glorious chaos that would ensue lol

300s are a mess and have been for some time, with 3.5 rework around the corner I don't think they will fix it either.

It's unfortunate. There are a couple of principles in software development that CIG seems to be unconcerned about. The problem is in the difference between good, and good enough.

 

[NaffNaffBobFace]

It's unfortunate. There are a couple of principles in software development that CIG seems to be unconcerned about. The problem is in the difference between good, and good enough.

At this point it may be pointless fixing anything that doesn't break less than, say, 25% of the time. There is just so much more game to make that could break what is fixed now when it's implemented.

 

[Vavrik]

At this point it may be pointless fixing anything that doesn't break less than, say, 25% of the time. There is just so much more game to make that could break what is fixed now when it's implemented.

It's natural for humans, including software developers to think that way. The logic is that we can fix the problems later when we have time. Sounds reasonable even to me, but I know better. The cost increases at some exponential rate the longer you wait, and it's not even an arbitrary value. It's predictable. It doesn't matter what you're doing either. Building a house, designing a (real) spaceship, or writing software for a game.

From what I've seen of CIG, they have fallen right into the trap, and you and I are funding it.

 

[NaffNaffBobFace]

It's natural for humans, including software developers to think that way. The logic is that we can fix the problems later when we have time. Sounds reasonable even to me, but I know better. The cost increases at some exponential rate the longer you wait, and it's not even an arbitrary value. It's predictable. It doesn't matter what you're doing either. Building a house, designing a (real) spaceship, or writing software for a game.

From what I've seen of CIG, they have fallen right into the trap, and you and I are funding it.

I see where you come from. Build it right, build it once.

From my experience using software systems at work (end user, not dev), adding features to a live product can break or causes issues or conflicts for parts of the systems that are already running.

How should SC be doing it? It's hard to know how while still allowing us access to the Alpha - as an example the last time there was a major peice of functionality added to our work systems (read: mechanic in SC's case) it took two years of functional testing before it could be launched and bugs still got through. I wouldn't want all that time adding to the alpha phase every time a mechanic is added, salvage, exploration, refuel etc etc

 

[Vavrik]

From my experience using software systems at work (end user, not dev), adding features to a live product can break or causes issues or conflicts for parts of the systems that are already running.

It's not actually quite build it right, build it once, although that would be ideal. It just doesn't happen often that business software requirements are that static, and if you have projects that take 2 or more years to write, you can bet your booty that a number of requirements changed during the development cycle. That is one of the major contributing factors to cost overruns in corporate projects. Yes, we know how to fix that. CIG is affected by similar kind of problem.

How should SC be doing it? It's hard to know how while still allowing us access to the Alpha - as an example the last time there was a major peice of functionality added to our work systems (read: mechanic in SC's case) it took two years of functional testing before it could be launched and bugs still got through. I wouldn't want all that time adding to the alpha phase every time a mechanic is added, salvage, exploration, refuel etc etc

CIG doesn't have the moving target issue that business software has when it takes a long time, and for the record it doesn't matter that they release the alpha for public consumption, actually that is a good thing if they manage it correctly. The problem I see is that they add requirements before they fix problems. That is not being managed properly, and the longer they wait, the more expensive those issues get. How much more expensive is dependent on several factors, but the averages are not pretty.

The numbers are averages of what a single bug costs.
1 X During design and prototyping.
5 X development cycle
15 X during product testing cycle
100 X during the post deployment period.

Pick your poison.

 

[Lorddarthvik]

In case of the

It's not actually quite build it right, build it once, although that would be ideal. It just doesn't happen often that business software requirements are that static, and if you have projects that take 2 or more years to write, you can bet your booty that a number of requirements changed during the development cycle. That is one of the major contributing factors to cost overruns in corporate projects. Yes, we know how to fix that. CIG is affected by similar kind of problem.



CIG doesn't have the moving target issue that business software has when it takes a long time, and for the record it doesn't matter that they release the alpha for public consumption, actually that is a good thing if they manage it correctly. The problem I see is that they add requirements before they fix problems. That is not being managed properly, and the longer they wait, the more expensive those issues get. How much more expensive is dependent on several factors, but the averages are not pretty.

The numbers are averages of what a single bug costs.
1 X During design and prototyping.
5 X development cycle
15 X during product testing cycle
100 X during the post deployment period.

Pick your poison.

That's a really interesting, I didn't know it worked like that, thanks!
With the reworked ships like the 300s I think they went with all of the above. They rebuilt the thing from the ground up. That's why they didn't bother fixing bugs on the old one.
With the rebuild they could potentially end up better off cost wise though, compared to fixing up the old ship. Using the "new" pipelines/systems they are familiar with by now could potentially introduce much fewer bugs and issues with the rebuilt ship.
I bought a citcon edition reworked Mustang and it seems to be working fine, with only the common bugs and issues unrelated to the ship itself. So the 300s could end up being pretty much bug-less as well.
Now when it comes to the whole project, yeah, I can absolutely see your point.

 

[Bambooza]

It's not actually quite build it right, build it once, although that would be ideal. It just doesn't happen often that business software requirements are that static, and if you have projects that take 2 or more years to write, you can bet your booty that a number of requirements changed during the development cycle. That is one of the major contributing factors to cost overruns in corporate projects. Yes, we know how to fix that. CIG is affected by similar kind of problem.



CIG doesn't have the moving target issue that business software has when it takes a long time, and for the record it doesn't matter that they release the alpha for public consumption, actually that is a good thing if they manage it correctly. The problem I see is that they add requirements before they fix problems. That is not being managed properly, and the longer they wait, the more expensive those issues get. How much more expensive is dependent on several factors, but the averages are not pretty.

The numbers are averages of what a single bug costs.
1 X During design and prototyping.
5 X development cycle
15 X during product testing cycle
100 X during the post deployment period.

Pick your poison.

Ah the joys of software development. Of course I've had often to pick the last poison because it was far more advantageous to be first to market and patch post release then it was to spend a few more months in the development cycle. What has been beneficial has been to embed QA testers with development as it has really helped with the prototyping and development cycle.