feat: enhance RavenColonial integration and add Project Creation #383
Conversation
toemaus313
commented
Oct 31, 2025
toemaus313
commented
- Added automatic RavenColonial sync detection and enablement when docking at construction sites. This resolved issues with BGS-Tally syncing commodity delivery data up to Ravencolonial build page
- Added Create Project dialog with ability to use stations that were pre-planned in Ravencolonial
- Added "Open Build Page" button to Progress window for quick access to RavenColonial build page
- Implemented auto-creation of systems and builds when RavenColonial project exists
- Fixed UI errors when no system is loaded during startup
…ments - Added automatic RavenColonial sync detection and enablement when docking at construction sites - Added Create Project dialog with ability to use stations pre-planned in Ravencolonial - Added "Open Build Page" button to Progress window for quick access to RavenColonial projects - Implemented auto-creation of systems and builds when RavenColonial project exists - Fixed UI errors when no system is loaded during startup
| if system == None: | ||
| Debug.logger.warning(f"Invalid ColonisationConstructionDepot event (no system): {entry}") | ||
| return | ||
| if self.system_id and self.market_id and self.current_system: |
There was a problem hiding this comment.
Two things.
First, a ColonisationContribution cannot be done until after you've docked. Docking at a colonisation site will create the system & the build so doing it here is unnecessary. After docking you'll have ColonisationConstructionDepot events which will create the progress.
Second, BGS-Tally isn't just an RC client, it can function entirely without RC. This code assumes that if someone has a system in RC they want it synced with BGS-Tally. I chose to only sync with RC if the user specifically enables it.
There was a problem hiding this comment.
I've been testing the existing release for a couple more hours this morning and feel that the automatic creation of RC projects is actually causing more problems than it solves. What I'm seeing is:
- Autocreated project doesn't have a build type or body, and pulls the ugly $SYSTEMCOLONISATIONSHIP.... string for the station name. This could easily be parsed out, but you'd still have the issue of no build type or body
- Autocreated project doesn't appear in the planning page for RC, even though the build exists
- I could find no apparent way to create a build page based on an existing pre-planned site in RC, even though I have synced up my plan from RC
- If you aren't the Architect and you try to deliver, the events are ignored by the plugin. There is no provision to create a project on behalf of the Architect. This is a feature that becomes important to groups working on large systems together
I believe changing the creation to a manual process would fix these issues and make for a more intuitive user experience, and also have a feeling that's why the original developer didn't make it automatic in SRVSurvey. How I think changing this to manual would resolve the issues:
- Name can be pre-populated in the UI dialog and user can edit as desired. Build type and body would also be selectable.
- I believe the above would resolve the issue of the build not appearing in the System page of RC
- If a project page on RC needs created for a pre-planned RC site, this could be selected from a dropdown that is populated by the RC API as in my lightweight plugin or SRVSurvey. This also resolves the issue of the build page not appearing in the RC Systems page
- Manual process would allow the assignment of a different CMDR name if the one delivering isn't the Architect. If they put in the wrong Architect name, it will error if the RC System is locked, otherwise it can be fixed later in RC by the Architect
There was a problem hiding this comment.
The workflow for project creation on a pre-planned site looks like this:
When the user hits the Create Project button, RC API sends the system body information and any preplanned sites to populate those fields in the UI. User selects their prebuilt site here:
And when they select the site, the Build Name, Construction Category, Model and Body are all filled in. They hit Create and are whisked away to the build page.
There was a problem hiding this comment.
feel that the automatic creation of RC projects is actually causing more problems than it solves
Maybe... I really dislike making users enter information that the system already has. It's unnecessary workload and opens the possibility of user error resulting in duplication.
have a feeling that's why the original developer didn't make it automatic in SRVSurvey
From talking to him, originally projects & sites were entirely distinct and SRVSurvey was just a project client. This has been changing over time though when we last talked his feeling was that projects & sites still weren't properly connecting.
Autocreated project doesn't have a build type or body
Is it failing to match the build with the site, i.e. creating a new site? If so why? (This should be in the logs)
Generally speaking it should be able to match the colonisation site you landed at with the existing site [colonisation.py:199] in which case it would pick up the layout and body and fill these in automatically.
If you aren't the Architect and you try to deliver, the events are ignored by the plugin.
This should not be the case. What code is causing them to be ignored?
There is no provision to create a project on behalf of the Architect. This is a feature that becomes important to groups working on large systems together
This also should not be the case. If you land at a construction site a project should be created regardless of who the architect is. Is that not happening?
Manual process would allow the assignment of a different CMDR name if the one delivering isn't the Architect.
Assignment to what, the project or the system?
There is something that does need to be fixed which may address much of the above.
When RC added commander authentication (using FDev auth) it changed to allow open and closed systems. BGS-Tally currently only checks if the commander is the architect. It doesn't check if the commander has permission to edit the system even if they aren't the architect which it should.
|
|
||
| self.rows.append(r) | ||
|
|
||
| # Add RavenColonial button at the bottom |
There was a problem hiding this comment.
It feels like this could just be an action based on (right?) clicking on the build at the top of the list (self.title) rather than taking up space by adding an extra button just for it.
There was a problem hiding this comment.
How/where/if to put the buttons or adjust the UI would probably best be decided by you guys, I really just added those as a proof of concept more than anything. I'll defer to you guys on any UI changes :-)
| #### A. `bgstally/ravencolonial.py` | ||
| Added new method `check_auto_sync(system_address, market_id)`: | ||
| - Checks if a project exists via `/api/system/{systemAddress}/{marketId}` | ||
| - Verifies commander assignment via `/api/cmdr/{cmdr}` |
There was a problem hiding this comment.
You can get this information without making an additional call (/api/system/{systemAddress}/{marketId} includes a commanders section).
There was a problem hiding this comment.
Ahh thank you! I'm going to leave this unresolved so that I can remember to fix that if these changes intend to get implemented
| **Location**: Lines 179-238 | ||
|
|
||
| #### B. `bgstally/colonisation.py` | ||
| Added auto-sync checks in three locations: |
There was a problem hiding this comment.
I think this is a question for Aussi and the BGS-Tally users –– should we just assume RC integration for anyone who has a key setup or only use the integration if they enable it?
There was a problem hiding this comment.
It's always a good design principle to give maximum control to the users, and I've always tried to do this wherever possible in BGS-Tally.
Currently you can enable / disable synching with RC system-by-system. However, what is the actual benefit to a user of disabling RC sync for a system? If they have gone to the trouble of setting up RC with a key etc, would a user ever want to select a system to not be synched... I suspect the answer is no, in which case I don't see a problem with auto-synching. Happy to hear an opposing argument though, if there is a valid reason.
There was a problem hiding this comment.
My 2 cents: I think if a user has gone through the trouble to figure out where the RC API Key is in the first place, it's likely a safe assumption they will want that integration in BGS Tally. That being said, I'm curious why the API key is needed? As far as I can tell all of the API calls being made don't require the API key to be entered, but I may be missing something.
|
You're missing something. API Key support is fairly recent in RC but
writing to systems fails if you aren't authenticated either with the api
key or the older rcc-cmdr header.
…On Fri, Oct 31, 2025 at 8:16 AM toemaus313 ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In AUTO_SYNC_CHANGES.md
<#383 (comment)>:
> +
+**Key Improvement**: Systems are now **automatically added to BGS-Tally tracking** when you dock at a construction ship where you're assigned to a RavenColonial project - no manual system creation required!
+
+### Changes Made
+
+#### A. `bgstally/ravencolonial.py`
+Added new method `check_auto_sync(system_address, market_id)`:
+- Checks if a project exists via `/api/system/{systemAddress}/{marketId}`
+- Verifies commander assignment via `/api/cmdr/{cmdr}`
+- Handles both string buildIds and project objects from API
+- Returns `True` if both conditions are met
+
+**Location**: Lines 179-238
+
+#### B. `bgstally/colonisation.py`
+Added auto-sync checks in three locations:
My 2 cents: I think if a user has gone through the trouble to figure out
where the RC API Key is in the first place, it's likely a safe assumption
they will want that integration in BGS Tally. That being said, I'm curious
why the API key is needed? As far as I can tell all of the API calls being
made don't require the API key to be entered, but I may be missing
something.
—
Reply to this email directly, view it on GitHub
<#383 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAN5K2RKQ54CFH5EBH2RO2L32N4OFAVCNFSM6AAAAACKXO3HHOVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTIMBUG43TCMBVGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
The most likely scenario I can think of is someone wanting to
stealth build. This is less of a need with the recent anti-sniping changes
but I can see scenarios where a commander temporarily doesn't want data
being sent to RC.
That said I could see us going either way with this. It's a very simple
change to auto-set the RCSync flag for any cmdr who's put in an RC API key,
or for any system that's already in RC, or even to make it a
user-preference to default to syncing.
…On Fri, Oct 31, 2025 at 3:16 AM Aussi ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In AUTO_SYNC_CHANGES.md
<#383 (comment)>:
> +
+**Key Improvement**: Systems are now **automatically added to BGS-Tally tracking** when you dock at a construction ship where you're assigned to a RavenColonial project - no manual system creation required!
+
+### Changes Made
+
+#### A. `bgstally/ravencolonial.py`
+Added new method `check_auto_sync(system_address, market_id)`:
+- Checks if a project exists via `/api/system/{systemAddress}/{marketId}`
+- Verifies commander assignment via `/api/cmdr/{cmdr}`
+- Handles both string buildIds and project objects from API
+- Returns `True` if both conditions are met
+
+**Location**: Lines 179-238
+
+#### B. `bgstally/colonisation.py`
+Added auto-sync checks in three locations:
It's always a good design principle to give maximum control to the users,
and I've always tried to do this wherever possible in BGS-Tally.
Currently you can enable / disable synching with RC system-by-system.
However, what is the *actual benefit* to a user of disabling RC sync for
a system? If they have gone to the trouble of setting up RC with a key etc,
would a user ever want to select a system to not be synched... I suspect
the answer is no, in which case I don't see a problem with auto-synching.
Happy to hear an opposing argument though, if there is a valid reason.
—
Reply to this email directly, view it on GitHub
<#383 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAN5K2WKB7KMN5T3LLOLARL32MZHJAVCNFSM6AAAAACKXO3HHOVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTIMBTGUZDEMZRGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
4 participants
