how do starbases and outpost influence territorial claim?

[Peter1981]

morning all, just a quick question

when you build a outpost or starbase in a sector you claim that sector, if it is populated then you claim the surrounding 8 sectors (unless already owned by someone else major/minor/rebels et al), does any one understand where this is found in the trek.exe?

the reason I ask is that I would like to increase the radius of the starbase so that it claims more teritory, maybe radius 2, for the larger galaxies we now play in.

thanks for any help everyone

[Martok]

That's an excellent question, Peter! I'd be curious to know the answer myself. I agree that with the larger maps, giving starbases a larger "claim area" seems appropriate.

[Tethys]

As would I as this would play a large role in my Mod as well...

[Peter1981]

there must be in the trek.exe at least one routine for assinging ownership of a sector to a player:

1 when the game starts and generates each empire,
2 when a new colony is founded/destroyed(supernova et al)
3 when a system is subjugated/rebels
4 when a minor becomes a member/bribed
5 when a outpost/starbase is built/destroyed

i think that covers most of the ocassion when boundaries change. --

Any thoughts much appreciated.

[Peter1981]

as an after thought you gan change the sector claim in UE for saved games I've read the artical on saved game in modding but didn't see anything on the ownership of sector any thoughts

[KrazeeXXL]

I would like to increase the radius of the starbase so that it claims more teritory, maybe radius 2, for the larger galaxies we now play in.

nice idea

It should indeed be very useful for huge maps to increase the territories a bit and fill up the rag-rug.

The intercept option became almost useless.

for sp and huge maps ok but for mp and small maps... another story.

[Peter1981]

the territorial claim is mention in system ownership when galaxies are created by gowron in another post, howerver this is the only referance i have found to ownershipas alway beg to ask the code masters what their thought are on this

[Tethys]

there must be in the trek.exe at least one routine for assinging ownership of a sector to a player:

1 when the game starts and generates each empire,
2 when a new colony is founded/destroyed(supernova et al)
3 when a system is subjugated/rebels
4 when a minor becomes a member/bribed
5 when a outpost/starbase is built/destroyed

i think that covers most of the ocassion when boundaries change. --

Any thoughts much appreciated.

Do not forget about contested sectors, and how they are affected during gift and demand.

[Peter1981]

my guess is that there is a bit mask for major empire ownership and minor, and independants (rebel) systems. minors and independant systems override all other ownership concerns. However if one major empire ownership bit is set then it is that empires sector, if more than one then it is contested unless it is an colony then that race takes priority.

[QuasarDonkey]

Hi Peter. I don't know if you are aware but I've been recently working on creating a nice IDA database for trek.exe. It's not quite finished yet, but you'll find it under "Standard Trek.exe IDA Database" in Modding Information.

Anyway, I looked though it, and I think I have the function you're looking for. If you download my IDB file, you'll find a function called Game_Borders_Calculate at offset 004476C0. It's called by the main turn processing function at 00458260.

I'm certain it's the function you're looking for, as it loops over the star systems and starbases. Be warned, it looks like a fairly complex function... and there are a few other functions it calls purely related to border calculation.

Edit: function at 4472B0 called at the end of Game_Borders_Calculate also looks important, as it loops over all the sectors, and also seems to access empire data.

[Peter1981]

thanks QD will look in to this

[QuasarDonkey]

Hey again, I did some work cleaning up Game_Borders_Calculate() and related functions by playing around with some nice IDA features. I've updated the Trek.exe IDB file, and you should find it a lot more reasonable to work with now. I haven't studied the function extensively, but I have noticed it loops over the StarBases array, checking whether a StarBase is built, setting ownership of that sector if it is built, etc. It also sets the sector.claim property. So it's definitely the function you're looking for. But you'll also have to look through the other functions it calls too.

If I have more time soon I'll try do a detailed analysis.

[Spocks-cuddly-tribble]

Some time back I also had have a look at the issue, but I didn't saw an easy solution:


sub_47A430 seems to be a loop over the adjacent sectors

It gets called for: (+for some AI simulation?)

- Inhabited major systems -> loc_44772E -> sub_4474E0

- Outposts -> 004477B5...

- Starbases -> 0044775A...


Relevant code area for claim of uninhabitated sectors without stations:

sub_4472B0 -> 44741E - 447437

i.e. analysis of ds:[5B4210] & sub_47A5A0 (but I think the above code is the key to the problem)


And below we find:

sector.lst
Offset 0x0054 to 0x0067= (5empires * 4bytes) = sector accessible: 0=No, 1=Yes



btw @ the Admins: I'd suggest QuasarDonkey for the Codemaster rank, due to his outstanding efforts wrt the mechanics of BotF (I still hadn't the time to try the database out yet). Also I'd give him moderator access to the codding section, so he can edit/update the modding index with his projects.

[Tethys]

btw @ the Admins: I'd suggest QuasarDonkey for the Codemaster rank, due to his outstanding efforts wrt the mechanics of BotF (I still hadn't the time to try the database out yet). Also I'd give him moderator access to the codding section, so he can edit/update the modding index with his projects.

Seconded. Its up to TC and AFC in the end.

Anyways, just a thought on how Outpost and Starbase could affect control of surrounding sectors:

Outpost in sector (empty or star) = Control that sector
Starbase in sector (empty or star) = Control that sector and adjacent sectors

Outpost in populated sector = Control that sector and adjacent sectors
Starbase in populated sector = Control that sector and 2 layers of adjacent sectors

Maybe, if possible, we could have a third tier starbase to control 3 layers of adjacent sectors at late techs.

[QuasarDonkey]

Well I wouldn't jump too far ahead until we fully understand the code. I'm not sure if it's possible to extend the range yet. But I've made some progress deciphering it.

SCT is largely correct. My IDB has sub_47A430 listed as Game_Map_GridMap_47A430, which is called by Game_Borders_Calculate. I believe all the functions mentioned are called from Game_Borders_Calculate (4476C0). I'm 100% certain this is the right function. Here's a short snippet from Game_Borders_Calculate:

Code: Select all

[Tbc]:0044773F                 mov     bx, [edx+StarbaseInfo_t.shipFunction]
[Tbc]:00447743                 lea     eax, [edx+StarbaseInfo_t.sectorPos] ; Load Effective Address
[Tbc]:00447746                 cmp     bx, 7           ; Compare Two Operands
[Tbc]:0044774A                 jnz     short loc_4477A7 ; Jump if Not Zero (ZF=0)

This would seem to support the comments about separate functions handling outposts and starbases. But I'm still not sure how it works overall. I've been doing the donkey work, trying to make the code as readable as possible first. It's paying off, but it's slow work.

I did notice at the very end of Game_Borders_Calculate, a call to Game_Borders_4472B0 -- this code actually sets the claim and ownership flags for the sectors. You'll notice the claim flag is set using inclusive OR

Code: Select all

or [edi+Sector_t.Claim], dl

, whereas ownership is exclusive

Code: Select all

mov [edi+edx*4+Sector_t.Ownership], edx

It's a bit strange. First it loops through the starbases, checking if they're operational, who owns them, etc. and makes calls to the GridMap functions based on this. Then another function loops over the starsystems to see who owns them, etc. The final function loops over all the sectors (the entire grid), setting the claim and ownership. But it looks at starbases and starsystems too. So why the separate functions?

Maybe BotF is keeping multiple copies of data again...

It should become clearer once we figure out the GridMap functions like the one at 47A430 which uses the borderGridMap data stored at 5B4210 (it's an array of 5 pointers, dynamically allocated grids, one for each empire). I'll try make it a priority to reverse engineer that data structure (a little harder than usual since it's dynamically allocated and it's not stored in the save files: the Game_Border_Calculate function is also called just after LoadGame).