Horizons Where's the clock

Status
Thread Closed: Not open for further replies.
It is mind numbing to me we don't have this yet. They can redesign the cockpit dropping the IPAD in our lap for the Horizons changes, but a clock? Something ironic about the real world's clocks are based on Greenwich Mean Time, but a group of cats 60 miles away in Cambridge can't add this simple tool to a 34th century spaceship? :p
 
I don't see the need to have the development schedule disrupted for this when the clock is already visable in the game. [...] You never just change the plan in such a way without facing the fallout from doing so.
Blimey, I thought I was exaggerating for emphasis when I suggested that might be the case. I had no idea some projects were genuinely run that way. While none of us knows whether ED's development actually is managed like this, it would certainly explain much about the current state of the game if it was, especially all the niggling little missing features and annoying bugs that seem to survive through multiple builds.
 
Blimey, I thought I was exaggerating for emphasis when I suggested that might be the case. I had no idea some projects were genuinely run that way. While none of us knows whether ED's development actually is managed like this, it would certainly explain much about the current state of the game if it was, especially all the niggling little missing features and annoying bugs that seem to survive through multiple builds.

I'm sorry to say but yes, some projects are run very badly. If planned well enough you would have a contingency built in to allow for bug fixes etc. However this is where feature creep can bite you if the fix will take longer then the built in safety margin.

Simple building site example: Bob is a plasterer, he's been booked on the 10th day of the project to come in and plaster the walls with two days planned to let it go off.

Frank, the electrician is due to finish his work on the 9th day but he has a problem and will need to come back on site to finish putting the plug sockets on the wall.

What to do? Put Bob off and also ring the decorators to let them know they are no longer required on day 13 but should start work on the 14th... They may be booked to do other work on that day. But if we let Bob in and then call Frank back to finish that means we'll need Bob back to re-plaster the wire runs... then two days for it to go off then we can call the decorators back in if they are available.

In other words, all it can take is one thing not to be done on time and you can have a nightmare on you're hands. Yes the work for the clock is rather simple to get done but in order to get it done right - do it at the right time ;)

Then there is the other nightmare... you're bosses deadline for release but that's a pile of horse dung we'd better not get into!

Me personally I try to always have it so a few people will be free for a while so they can either pick up the slack or be put onto something quick like this. I always build an 18-20% time contingency into each phase of the project to cover creep and last minute additions.
 
Last edited:
Stop making excuses for the dev's, of course the there should be a clock, when they implemented this type of mission they created a requirement for it.

Which could mean that "Time" itself was created by some developer somewhere so that we would be able to complain about either not having enough of it or not being able to see when it's wasted. :D
 
I'm sorry to say but yes, some projects are run very badly. [...]
Simple building site example: [...]
Oh, I'm no stranger to how these things work in the real world. (Judging by the state of my walls I think Bob and Frank were responsible for my last rewire).

But the idea that the addition of a simple "CTRL-C = Clock" routine running alongside the "CTRL-F = FPS" code could be indefinitely blocked because it's not on somebody's flowchart is quite worrying. But then I don't really understand how modern software development is managed. In my very limited and archaic experience you just got on with it and if you could fix an easy bug while you were taking a break from fixing the more difficult bugs it was a win. I guess things are just too complicated to get away with that now, so perhaps I shouldn't be surprised.

Tangent:
About 6 or 7 years ago, having owned several Apple devices and had nary a problem with any of them, I noticed something odd started to happen. Bugs that had been reported in version a of the OS, and successfully fixed in version b, would suddenly reappear in version c and have to be reported again. Eventually (or not, this is Apple) they would get quashed for the second time in version d. But that version would reintroduce a problem everyone thought had gone away with version b, and so on.

At first I couldn't understand how this was possible. Once a bug had been identified and removed, how could it reappear? Code doesn't spontaneously revert to an earlier state. Of course many of these would have been different bugs with similar symptoms, but in many cases it was clear that a previously implemented fix had just gone away.

But then I started reading about trends in project management, and how code branches were forked and reintegrated into the trunk at regular intervals. How in some cases several teams would be tasked with solving the same problem and the one with the first or most elegant solution would be implemented. All of these branches and reintegrations had to be carefully managed to avoid conflicts. All of a sudden the penny dropped. Where in my naivety I'd been assuming that all bugs were caused solely by bad coding, now it was obvious that bugs could be caused -- or even reintroduced -- by bad management. It was a revelation, albeit a rather sobering one. As an end user it meant I could no longer assume that only new problems would manifest with new code versions, but that old ones could also resurface.

I had hoped that with a smaller team, FD might have been able to avoid this sort of thing with ED. But judging by the retrograde steps we've seen in recent builds (broken missions that previously worked, AI that seems to have unlearned much of what it spent the last year learning etc.) I'm wondering whether something similar isn't happening here.
 
Clock implemented*

Screenshot_0071.jpg

* Frequent manual updates required.
 
Oh, I'm no stranger to how these things work in the real world. (Judging by the state of my walls I think Bob and Frank were responsible for my last rewire).

But the idea that the addition of a simple "CTRL-C = Clock" routine running alongside the "CTRL-F = FPS" code could be indefinitely blocked because it's not on somebody's flowchart is quite worrying. But then I don't really understand how modern software development is managed. In my very limited and archaic experience you just got on with it and if you could fix an easy bug while you were taking a break from fixing the more difficult bugs it was a win. I guess things are just too complicated to get away with that now, so perhaps I shouldn't be surprised.

It all depends on how they are managing the project. Personally I like to get everything right so we don't have to go over old code later - it becomes to tempting to 'play' with it a bit more delaying things even further. Given that we've seen minor updates on a regular basis I should think they have built in some safe guards. :)

I could write a book on the horror stories I've seen and the games that have failed due to poor planning. Regardless FD have a window to get the bugs in Horizons to an acceptable level along with a few tweaks I just wish they would come out and say this is what they are doing to try and negate some of the forums worries.
 
I use MSI afterburners on screen display for gpu temp ect, but you can have the time on display as well, good solution for now at least, especially vr users.
 
Welcome to the half baked nature of these timed missions they didn't bother to even put a proper mission clock, sure you can look at the galaxy map but it won't pretain to the mission nor does the information on the side pannel. Honestly the whole timed mission should have been held off untill it was properly implemented with a mission specific clock support to track the mission. I mean at this point the mission could actually go past the specified time but you'd never know since its so hard to track.

Not only that but on my low spec system, opening the galaxy map takes between 20 and 30 seconds!
 
I also use rainmeter on occasion, if the need arises really, see top and middle left just in case its not obvious :) I know its probably not the solution most are looking for in this thread but it works.

View attachment 92664
 
Last edited:
I also use rainmeter on occasion, if the need arises really, see top and middle left just in case its not obvious :) I know its probably not the solution most are looking for in this thread but it works.

Sorry but:

"Contact Elvis at ???? black market"?
"Must find barnicles"?

That's funny...
 
...bad coding, now it was obvious that bugs could be caused -- or even reintroduced -- by bad management. ...

Code branch management can get hideously complex very easily, depending on how many clients/versions you're trying to support. Hopefully they've developed Horizons to run off the same branch as the base game otherwise things could get worse
 
Why is there four pages long discussion about where the clock is?
One in the home screen of station services, other in galaxy map.
 
Okay Frontier, there is player demand for a dash clock. Why not a bobble-head with a clock in the base? Earn a little extra cash for the company, meets player demand, and adds some functionality to a dash decoration. Just a suggestion.
 
Status
Thread Closed: Not open for further replies.
Top Bottom