Again I shall rant against the angry mob and advice patience and civility.
It’s not that I don’t disagrees or don’t share the fundamental frustration.
People who “bought” EDO as their first ED game who ‘feel’ like they should be entitled to a refund are entitled to their feelings.
Games are unfinished when advertised.
The thing that I would prefer from is a little understanding about large scale software development, especially games, is that everything you hear from a sales pitch is a wish list of what the devs want to put in the game and they might even have a working prototype to back it up for gameplay and screenshot.
The problem comes with integrating and scaling that prototype (or sometimes the dreaded vertical slice)
Release dates are a projected guesstimate if all goes well, with a few months added for obligatory bugs and polish.
When things goes smooth, it’s already more than enough.
Just knocking out boilerplate stuff takes time, effort and still can go horribly awry.
As a former web developer, and mocked by proper developers for being A Web monkey who did “scripts”, did I get my revenge when their backends had to get ported into web-based apps for mobile devices.
So if Bruce and others had notes about the new UI, he could have explained that the new outfitting design was to integrate storage module flow into the main outfitting flow to replace the issue of Horizons having a second branching structure for stored module that needed to be reorganised from it’s ugly single list format.
So it makes sense that when Bruce mentioned there was a “filtering” bug in the outfitting that it was to explain why outfitting didn’t work.
Bruce doesn’t know what the end goal of the new UI is, and ergo why that bug would matter or why the new ui had such bizarre flow issues, because Community Team are only shown stuff a few weeks before we are. They are as much in the dark (can’t spoil that which they don’t know) as we are as to what the final version is.
A UI-filtering bug. It Sounds so boring, dull, simple boiler plate UI issue, ask a dev or a team manager to blindly answer is that fixable before release and you will get a boiler plate response of “of course we can fix that before release”
And more than likely those devs could have fixed if those devs had nothing else to do.
But the problem was bigger than expected, and taking longer to fix.
So developer Paul Woakes is dragged out in front of everyone in the daily scrum as being the bottle neck that is stopping the other artists and devs doing their work, finishing code, polishing the UI so it’s easy to read and the highlight/roll over and the new flow is all in place. Because Paul’s code has a bug in it.
But what if you can’t find the bug in time? We must have a backup.
Outfitting must still function when the game
Goes live!!
This is why I quit software development
The insanity of developing a fallback to meet a an unmovable deadline.
So instead of waiting and hoping Paul Woakes will fix his bug, which could entirely land on artists not naming their files correctly, and crashing out one of Fred’s functions that Paul’s code relies upon.
The team has to now magic a new UI as a stopgap measure, out of their asses. (Thanks Paul glowers the team).
But seriously, How long does it take to build a new UI or retrofit the 87% completed new Outfitting to Mimic the old broken behaviours and flow that the new UI was designed to replace?
And very meeting the team glowers at Paul Woakes.
So we’ve all been complaining about the stopgap measure as being broken, which it was,
And that they weren’t fixing it. Which they weren’t because the Odyssey original UI was the one that needed to be fixed not the stop-gap Measure.
And all the time on the forums and comment section a vocal Group claim that they aren’t being listened too, as they pointed out the issue with the outfitting.
planetary tech and performance issues?
Same problem there and mentioned in the alpha as a
Bug in the occlusion system, just way more complicated.
My money is on a bug in
base construction,
specifically the way how modular base pieces developed by an artist can being joined together by the background sim, and various layers of invisible planes that need to authored in the model to do that correctly, as those planes need to be turned on/off for occlusion, for AI,
Lighting, reflection, rendering, is a contained area of atmosphere, by the code.
So if the code switches on/off the right/wrong planes, or makes them
Visible/invisible to the wrong bits or code,
Then you don’t enclose the area properly,
So just like a small pixel gap in your art work, and you try the paint bucket fill, you erroneously fills the entire page,
So AI spazes out (eating up performance) as it’s trying to map way more area than it should, does the renderer, and any system trying to calculate what render and not to render.
something (again) they new about, talked about and fans failed to take to heart and understand.
So if you think the devs have been ignoring you and your feedback,
you clearly have been ignoring theirs.
It’s not that I don’t disagrees or don’t share the fundamental frustration.
People who “bought” EDO as their first ED game who ‘feel’ like they should be entitled to a refund are entitled to their feelings.
Games are unfinished when advertised.
The thing that I would prefer from is a little understanding about large scale software development, especially games, is that everything you hear from a sales pitch is a wish list of what the devs want to put in the game and they might even have a working prototype to back it up for gameplay and screenshot.
The problem comes with integrating and scaling that prototype (or sometimes the dreaded vertical slice)
Release dates are a projected guesstimate if all goes well, with a few months added for obligatory bugs and polish.
When things goes smooth, it’s already more than enough.
Just knocking out boilerplate stuff takes time, effort and still can go horribly awry.
As a former web developer, and mocked by proper developers for being A Web monkey who did “scripts”, did I get my revenge when their backends had to get ported into web-based apps for mobile devices.
So if Bruce and others had notes about the new UI, he could have explained that the new outfitting design was to integrate storage module flow into the main outfitting flow to replace the issue of Horizons having a second branching structure for stored module that needed to be reorganised from it’s ugly single list format.
So it makes sense that when Bruce mentioned there was a “filtering” bug in the outfitting that it was to explain why outfitting didn’t work.
Bruce doesn’t know what the end goal of the new UI is, and ergo why that bug would matter or why the new ui had such bizarre flow issues, because Community Team are only shown stuff a few weeks before we are. They are as much in the dark (can’t spoil that which they don’t know) as we are as to what the final version is.
A UI-filtering bug. It Sounds so boring, dull, simple boiler plate UI issue, ask a dev or a team manager to blindly answer is that fixable before release and you will get a boiler plate response of “of course we can fix that before release”
And more than likely those devs could have fixed if those devs had nothing else to do.
But the problem was bigger than expected, and taking longer to fix.
So developer Paul Woakes is dragged out in front of everyone in the daily scrum as being the bottle neck that is stopping the other artists and devs doing their work, finishing code, polishing the UI so it’s easy to read and the highlight/roll over and the new flow is all in place. Because Paul’s code has a bug in it.
But what if you can’t find the bug in time? We must have a backup.
Outfitting must still function when the game
Goes live!!
This is why I quit software development
The insanity of developing a fallback to meet a an unmovable deadline.
So instead of waiting and hoping Paul Woakes will fix his bug, which could entirely land on artists not naming their files correctly, and crashing out one of Fred’s functions that Paul’s code relies upon.
The team has to now magic a new UI as a stopgap measure, out of their asses. (Thanks Paul glowers the team).
But seriously, How long does it take to build a new UI or retrofit the 87% completed new Outfitting to Mimic the old broken behaviours and flow that the new UI was designed to replace?
And very meeting the team glowers at Paul Woakes.
So we’ve all been complaining about the stopgap measure as being broken, which it was,
And that they weren’t fixing it. Which they weren’t because the Odyssey original UI was the one that needed to be fixed not the stop-gap Measure.
And all the time on the forums and comment section a vocal Group claim that they aren’t being listened too, as they pointed out the issue with the outfitting.
planetary tech and performance issues?
Same problem there and mentioned in the alpha as a
Bug in the occlusion system, just way more complicated.
My money is on a bug in
base construction,
specifically the way how modular base pieces developed by an artist can being joined together by the background sim, and various layers of invisible planes that need to authored in the model to do that correctly, as those planes need to be turned on/off for occlusion, for AI,
Lighting, reflection, rendering, is a contained area of atmosphere, by the code.
So if the code switches on/off the right/wrong planes, or makes them
Visible/invisible to the wrong bits or code,
Then you don’t enclose the area properly,
So just like a small pixel gap in your art work, and you try the paint bucket fill, you erroneously fills the entire page,
So AI spazes out (eating up performance) as it’s trying to map way more area than it should, does the renderer, and any system trying to calculate what render and not to render.
something (again) they new about, talked about and fans failed to take to heart and understand.
So if you think the devs have been ignoring you and your feedback,
you clearly have been ignoring theirs.
