[INDEPENDENT] Buckyball Racing Club

It is a shame that there isn't an in cockpit clock in either ships or SRVs, as there are plenty of non-starport fixed landmarks that could be used for racing (mountain tops, fixed crash sites, those little bases with no pads, etc) but they don't work for Buckyball without an official clock.
I do seem to remember that Zac had passed a request on to the dev team for an in-cockpit clock for the SRV, and it sounded vaguely positive... I'm aware that's getting into "Soon™" territory, though. ;)
Alternatively, showing current lat/long coordinates in the planetary map (assuming that has a clock, I don't remember) would also work?

If the API ever gets released, I wonder if we'd ever be able to create an official Buckyball application or web based logging tool that used the API.
Unfortunately, I think any API that gets released will only have access to server-side data, which will mean it'll likely not have accurate enough location info to assist with Buggyball-style races. It could potentially allow for verification of the normal races, depending on what information it returned.
 
Unfortunately, I think any API that gets released will only have access to server-side data, which will mean it'll likely not have accurate enough location info to assist with Buggyball-style races. It could potentially allow for verification of the normal races, depending on what information it returned.

Yes, I'm expecting that it'll provide access to no more than the log files already do, but I'm curious whether it would at least give "live" access to the in-game clock. If it did, then we could potentially produce an official race overlay that included the clock and the system name, and set up a single key to screenshot both the game and the overlay.

If such a overlay worked, then beyond that we could potentially sync and upload screenshots automatically (or at least log the times) via a page like EZ used.

(I work on embedded software, rather than web or pc stuff, so I'm not sure how feasible this is).
 
Well if things are largely trust based anyway. There must be some sort of clock/app that could already be used to overlay in game with borderless windowed mode?

Maybe something with a transparent background could help deter fraud ;)

I'm assuming IGT is just UTC + ~1300 years and is pretty accurate (probably NTP based).
 
Last edited:
Well if things are largely trust based anyway. There must be some sort of clock/app that could already be used to overlay in game with borderless windowed mode?

Maybe something with a transparent background could help deter fraud ;)

I'm assuming IGT is just UTC + ~1300 years and is pretty accurate (probably NTP based).
I agree totally, and any overlay that we adopted as a group would certainly help for events that wanted to use non-starport locations like RES zones or surface locations.

I'd still like to have an official BRC overlay/app though, so that we could send times directly to a web tool. I really loved EZ's Buckyball-9 tool.
One button to take a screenshot, and also log your time/system to the database/spreadsheet would be great.

I'm going to look into it before this years Bootlegger Challenge, even if the API isn't released and it needs to rely on the verbose log and a separate time-source. I'll probably need some help from someone more knowledgeable, but I can probably at least sort out a "rough around the edges" prototype.

Do overlays only work in borderless mode? I did think that Steam's overlay worked for full-screen games, but I've got to admit, I've not really played much else since ED Beta, and I don't often use overlays anyway.

PS: If I produced such tool, it would be optional to use, but I would like to experiment with something like that at the Bootlegger Challenge if no one else did before.
 
Last edited:
I'm going to look into it before this years Bootlegger Challenge, even if the API isn't released and it needs to rely on the verbose log and a separate time-source. I'll probably need some help from someone more knowledgeable, but I can probably at least sort out a "rough around the edges" prototype.

Do overlays only work in borderless mode? I did think that Steam's overlay worked for full-screen games, but I've got to admit, I've not really played much else since ED Beta, and I don't often use overlays anyway.

Steam's overlay does work fine in fullscreen mode, but only if the game is launched via Steam.
I'd potentially say you would have to be careful and liaise with FD though: adding an overlay would likely require hooking into the ED process, which is liable to raise red flags from an unknown external process. Obviously known-good things such as Steam and the Nvidia/AMD drivers are fine, so it's not an instant no-go... But it'd potentially take quite a bit of care and attention.

Not to mention that said overlay would have to be absolutely rock-solid - because if it goes wrong, it likely means bye bye game process. :p
 
Last edited:
Ah, right.

So overlays that work in just borderless mode wouldn't need the same reliability as they'd be completely separate processes? But not everyone would be able to use them.

I don't think I'd ever stop feeling guilty if I created an overlay that crashed the game during someone's run!
 
Ah, right.

So overlays that work in just borderless mode wouldn't need the same reliability as they'd be completely separate processes? But not everyone would be able to use them.

I don't think I'd ever stop feeling guilty if I created an overlay that crashed the game during someone's run!
You could probably create the equivalent of an overlay for borderless windowed mode, yes - it'd basically just be an "always on top" window that sat in front of the game without actually being the active window.

As for the possibility of crashing the game during a run - that thought had crossed my mind too, yes :D
I think the way people mostly guard against that is to have as little as possible actually running in the game process (to minimise the amount of code that causes catastrophic consequences if it actually goes wrong), and have the main logic running in a separate process.
The runtimes that we could use for this would also allow you to catch most types of error and gracefully stop the overlay code anyway, so it wouldn't be too ropey. Would still require some extended testing, though. :p
 
I had a read of some other threads during lunchtime, and noticed that use of the iPhone App API is now considered legal for third party applications:
https://forums.frontier.co.uk/showthread.php?t=175937

This API provides details such as CMDR Name, Ship Type, Current System, lots of trade data for the system, etc. It doesn't include 3d co-ordinates or a clock (as far as I know). As racer1 mentioned though UTC time could be sourced from another website, and would likely be very accurately matched with the in-game galactic time if offset by 1300 years.

Most of the existing tools that use the API are open source, because the API requires you to log into the frontier servers with your game user id & password, so the app developers make sure that everyone trusts them.

One of the existing third party apps includes a screenshot converter that creates a renamed jpg of each new bmp screenshot and also adds some metadata to the jpg.

furrycat's race-o-matic post in the Turbo Hour thread, has me wondering if the API could be used to provide information to the race-o-matic via something like Bucky's BBR-9 front end, and whether these same details could also be added to a converted to JPG screenshot as metadata.

This wouldn't be cheat-proof, but as long as either the converted JPGs or a video were submitted, it would allow easy verification for non-starport races, as each converted screenshot would include CMDR, system and time in the metadata. Other data, such as lat/long would appear in the screenshot itself.

This wouldn't require any overlays, just some keybindings and a race-o-matic for the event.

Again, I'm somewhat out of my depth here, for example I understand what's going on in the race-o-matic, but have no actual experience with database schemas.
 
Station and startport and internal ID are recorded as well as hull health and modules.

So if the race organiser went round the stations and recorded what their IDs were it would be possible to enter them on to the race-o-matic for the race and verify that your entry hit the locations. A hotkey could certainly take the screenshot and embed that information.

The difficulty is in remembering to hit the key.

I've seen people asking before if there's a way to read the log file and detect that you've docked. If there were all this could be automated. I'm not aware that it can, however.
 
Having played around with ED Toolbox recently another way of verifying buckyball screenshots occurs to me. So with ED Toolbox it can be setup to automatically jpeg your screenshots (as and when they appear in the screenshots folder) and tag them according to current system. It seems it would therefore be equally possible to automatically timestamp all screenshots (e.g. with a date/time visible watermark).
 
Having played around with ED Toolbox recently another way of verifying buckyball screenshots occurs to me. So with ED Toolbox it can be setup to automatically jpeg your screenshots (as and when they appear in the screenshots folder) and tag them according to current system. It seems it would therefore be equally possible to automatically timestamp all screenshots (e.g. with a date/time visible watermark).
Yep, that'd be very doable. No guarantee it'd match up to the in-game time second-for-second, of course.
 
Yep, that'd be very doable. No guarantee it'd match up to the in-game time second-for-second, of course.

I expect that if a UTC time server were used, then it would probably match the galactic time, assuming FD use an accurate time.

It doesn't matter that much except for the start and end time anyway, so as long as the race begins and ends in a station it would be fine. :)
 
I expect that if a UTC time server were used, then it would probably match the galactic time, assuming FD use an accurate time.

It doesn't matter that much except for the start and end time anyway, so as long as the race begins and ends in a station it would be fine. :)
Indeed, it should be fine.

That part about using an accurate time makes me chuckle though - I remember back around the time of BBR6 where the clock would regularly skew until it was out by up to 5-10 seconds, and then run fast to catch up! I seem to remember one or two racers saying they'd tactically choose when to start based on how fast/slow the clock was going... :D
 

Wonderful! :D


While I'll make my way out to Sgr A* probably tomorrow, I'll leave some of the Cookiebots behind and try remote-controlling them for races. I can't guarantee that they'll work and they haven't gotten their actuators on anything bigger than a Cobra yet, but they'll appear as CMDR Cookiebot. :)
No liability assumed for any confusion or damage caused by Cookiebots.
 
Last edited:

Ozric

Volunteer Moderator
I was going to request that, yes. :)

Although, this wasn't supposed to go out until next month...whoops.

Ah that does explain my confusion when I reached the end then :D Nice job getting onto the launcher, but there is just one thing I have to point out...

Students will be entirely safe in the hands of these veteran pilots

HAHAHA I have no idea how you convinced the board of directors of that :D
 
Nice job getting onto the launcher,
Too bad the launcher news doesn't work for me. Maybe the new one has a fix; I'll have to wait and see.

HAHAHA I have no idea how you convinced the board of directors of that :D
There might be some behind the scenes politics going on, which will be in a write up of some back story at some point, if I ever have the time. ;)
 
Back
Top Bottom