shipname.bin

[Peter1981]

sorry tethys

[Tethys]

Notice anything strange about this screenshot?

zl999d.png (360.94 KiB) Viewed 6960 times

Thats right, I found the place where it begins adding the 'A, B, C' classifications to the end of the ship names!

Simply open trek.exe in your hex editor and go to:

0x17959C

Replace

20 41

with either

90 90 or 00 00 (to disable)

or

20 20 (for double space, but beware the next ship/station will have a ! after it!)

So, right now I am using 90 90 to see how well this will work for Galaxies Mod. Thanks SCT, Peter and everyone who posted to help me with this, greatly appreciated!

[Peter1981]

congrates tethys nice find !!

However you have only changed the start value of the first letter -- might i sugest

This tests if the name group is 0 replacing the jump if zero with a jump will force every ship name not to have a letter after it.

Code: Select all

0x74a10 asm_475610
74 71   jz   short loc_475683
to
EB 71   jmp short loc_475683

[Peter1981]

SCT mentioned peviously but i've fleshed out his idea for you tethys:

OPTION: to extend the no letter sets
the following to statements test for set 32h(50) and 33h(51) in the shipname.bin

Code: Select all

asm_475612				0x74a12
	cmp	bx, 32h			66 83 FB 32	
	jz	short loc_475683	74 6B

Code: Select all

asm_475618				0x74a18
	cmp	bx, 33h			66 83 FB 32
	jz	short loc_475683	74 65

Changing the first jump if zero (equal) to a jump less than and moving the following jump to loc_47561E means that all shipname.bin name set with ID below 32h will be sent for a letter to be added their name else will be sent to the second test.

Code: Select all

asm_475612				0x74a12
	cmp	bx, 32h			66 83 FB 32	
	jl	short loc_475683	7C 06

Changing the second jump if zero (equal) to a jump less than or equal means that all shipname.bin name set with ID 33h or below will be sent for no letter addition to teir name else will be sent for a letter to be added.

Code: Select all

asm_475618				0x74a18
	cmp	bx, 33h			66 83 FB 33
	jle	short loc_475683	7E 65

Now if you wish to have more name sets without letters you can simply adjust the gap between 32h and 33h.

for example: replace ing 32h with 30h and 33h with 35h means you will have ship name sets 30-35 without additional letters; i.e. 48,49,50,51,52,53.

[Peter1981]

Still not happy with two excellent suggestions? Wanna have letters? But wanna start with a space? and not then have an '!'?

If the answer to these questions is 'yes' read on

The plan is simple and relitivly easy to implement we need to make trek.exe use the character before 'A' like a space. This can be done by setting the initial offset character 'A' to '@' do this at:

Code: Select all

0x17959C replace 20 41 with 20 40

Now your thinking that just means all ships start with an '@' after their name (USS Enterprise @ ??!!??) rather than a ' '. And you are correct.

So you'll need to replace '@' in .ftn files with blanks the explanation of how to edit font files is here:

viewtopic.php?name=Forums&file=viewtopic&t=687

Hope this helps tethys

[Peter1981]

@SCT you mentioned somewhere on the forume a limit in trek.exe memory to how many shipnames can be used; sadly I can't find it any where?

I believe you were talking about the limit on the number of groups that could be used not a limit on the number of names in a shipname group -- am i correct?

I worte:

Just to let you know what i'm upto...

changes in shipname.bin

Code: Select all

FC 00 00 00 -> 94 01 00 00

added 38 new indicies (01 00 00 00)
added 38 new Names one for each index (44 bytes) 2byte index (e.g. 5a 00) the FF FF and a single letter as a name diffrent for each new ship index.

changes to trek.exe

Code: Select all

at 0x749C8 F8 00 00 00 [62*4=248 dec] -> 90 01 00 00 [100*4=400 dec] 

Upon loading the latest version of UE the shipnames only list 0 to 61? does anyone know if UE supports extra shipname.bin indices?

EDIT:- CTD no crash.log HELP any ideas lads?

am I correct in assuming I broke the limit and this was the cause of my CTD -- If so then how close is solving this project really? -- could you please explain the limit you were talking about SCT -- thanks.

[Spocks-cuddly-tribble]

@SCT you mentioned somewhere on the forume a limit in trek.exe memory to how many shipnames can be used; sadly I can't find it any where?

I believe you were talking about the limit on the number of groups that could be used not a limit on the number of names in a shipname group -- am i correct?

Yes.

am I correct in assuming I broke the limit and this was the cause of my CTD -- If so then how close is solving this project really? -- could you please explain the limit you were talking about SCT -- thanks.

Ask one of the programmers around here, how to do that in BotF:

They come in two versions, granting either read-write access or read-only access. (...) The attribute 'Unchecked_Access omits the corresponding checks.

http://en.wikibooks.org/wiki/Ada_Progra ... ral_access

If it’s possible (and simple & fast to do, of course), then also ask QD for a recommended area in the asm-68A000 block (length 0xC * number of name groups), since he was thinking of creating a layout wrt this area in order to avoid conflicting usages.

Again, you'd need a read-write access area (aka dynamic data field) with fixed address (e.g. like empsInfo) not one with dynamic address (e.g. like systInfo).

If answers are affirmative, report back and I'll advice you how to setup unlimited name groups.

[Flocke]

I wonder why you reference to an ada wikibook, who's programming in ada nowerdays?
also why using asm-68A000 block that is known to be read only when you need read & write (segment permissions: Read, not Read/Write in ida)?

While I can't provide you with such and also doubt QD can (other than finding a place in an already existent read/write area), I'm sure the code accessing these groups can be codecaved outsourcing the groups to a dll to fulfil your needs.
Sorry if talking about codecaves sounds annoying, but using them is pretty easy once you know how.
The amount of time is mainly dependent on code places to cave (count of access to these groups).
If you tell me what you need and provide me with a single unused read/write address to store a function pointer in trek.exe, I'll provide you with such a codecave, implementing needed code + data in the codecave, no big deal.

Edit: Ok, well, not always placing a codecave is easy, today I needed some hours, mainly cause I forgot how to do it and also needed a way to not corrupt registers with c++ code (therefore wrapped the cave). So I better say in 'most' cases it's easy, who knows what's about to come.

[Spocks-cuddly-tribble]

If you tell me what you need and provide me with a single unused read/write address to store a function pointer in trek.exe, I'll provide you with such a codecave, implementing needed code + data in the codecave, no big deal.

Edit: Ok, well, not always placing a codecave is easy, today I needed some hours, mainly cause I forgot how to do it and also needed a way to not corrupt registers with c++ code (therefore wrapped the cave). So I better say in 'most' cases it's easy, who knows what's about to come.

Thanks for the infos Flocke,

what Peter (not I) needs, is clearly pointed out above.

As always for me, the question behind is: can I do something in less than X minutes or not, since I hardly find time to write articles for many important findings and bugfixes.

@ada - the link was just an example of what would be needed, based on a quick google search (I don't know - and I don't want to know - what ada is).


@Peter1981 - To put it plainly, this project is on hold until someone is willing to spend the needed time for searching or impementing the required dynamic area.

[Peter1981]

thank-you Flocke and SCT as always i am very grateful for your infomation. I'' need to find some time myself to work on this then.

[Flocke]

what Peter (not I) needs, is clearly pointed out above.

You said you'd give advice if affirmative so my offer was directed at you (Edit: not that I wouldn't also do this for others like you, Peter ).
For implementing codecaves I'd need to know what places to cave and what code+data changes to make, if wanted I could also read data from a file or something the like. It just shouldn't be too many places to cave as I'm not that experienced with it yet either.
And I'm not gonna search/read articles and analyse myself on this, sorry.

As always for me, the question behind is: can I do something in less than X minutes or not, since I hardly find time to write articles for many important findings and bugfixes.

understood but my offer holds for other fixes as well if you need it

@ada - the link was just an example of what would be needed, based on a quick google search (I don't know - and I don't want to know - what ada is).

guessed so cause it really doesn't have anything to do with the issue, it's just an ada internal concept of pointer access resticitons, you only confuse programmers with this

...and I still dunno why you need read/write access if it's about a fixed name set, but maybe current implementation marks entries used or something, for sure I just missed that piece of information

[Spocks-cuddly-tribble]

You said you'd give advice if affirmative

Not exactly:

If it’s possible (and simple & fast to do, of course)

not always placing a codecave is easy, today I needed some hours

Wasting lifetime, be it my own or others, notwithstanding of less time consuming alternatives, is no trivial offense for me.

For implementing codecaves I'd need to know what places to cave and what code+data changes to make, if wanted I could also read data from a file or something the like. It just shouldn't be too many places to cave as I'm not that experienced with it yet either.

If I'm not mistaken, your comment implies your codecave would provide an area with dynamic location i.e. not one with a fixed address(as explicitly requested). If so, then don't waste your time - BotF already provides us with more than sufficient code of that type via a simple call.

But the good news is that adapting the code should be less timeconsuming than within my recollection.

provide me with a single unused read/write address to store a function pointer in trek.exe

This'll point you to even more unused pointers than the Pointer Sisters ever had:

Asm 5B5568-5B584F length 0x2E8 -> ex-address of the now too small old data field

Code: Select all

length of data field = number of namegroups * 0xC
004753F2                 mov     ebx, 2E8h
00475430                 cmp     eax, 2E8h

see "xrefs to" for adjusting new address pointers:
005B5568 base address
005B556C base address +4
005B5570 base address +8

and only for sub_475438
005B555C base address -0xC
005B5560 base address -8
005B5554 base address -4

my offer holds for other fixes as well if you need it

Thanks, but my code changes are based on optimization & simplification i.e. need less code than available. As a rule of thumb - the worst bugs are easiest to fix. So the undoubtful favorite of the worst calculation bug gold award - mistakenly increasing the total intel output by up too +240% - was fixed in 15 seconds.

it really doesn't have anything to do with the issue, it's just an ada internal concept of pointer access resticitons, you only confuse programmers with this

If there is no easy way in BotF to redefine read / read-write access areas resp. to disable the controlling mechanics, then it's OK.

...and I still dunno why you need read/write access if it's about a fixed name set, but maybe current implementation marks entries used or something, for sure I just missed that piece of information

Ok, I think it's time to uncover the whole truth.

You have to know, Peter1981 recently visited the mountain Selea on Vulcan, meditating there 6 days, 6 hours and 6 minutes, till the spirit of Surak touched his deepest soul and told him the final wisdom, in order to bring out the light into the pakledish darkness of our minds. And now go down on your knees to hear what Surak told Peter1981:

"...shipname.dat.….EXTEND..SHIPNAME.DAT...."

So now we ask you, brother Flocke: Can you see the light? Do you feel the vibes? Do you feel like you were blind and now you can see?

[Flocke]

forgive me not having read anything on shipname.dat, some years ago when analysing savegames I took a short look at it, that's it and I didn't work on modifying any such stuff, but well now that you tell I guess the groupnames are part of datafile not exe and get read/written by botf on loadup. (sure I could have searched it myself, but as you said, why waste my time)
The thing with these codecaves is, that in a dll you can add a static data field like you want, you just can't hardcode the addresses to botf cause at least they might change on every recompile of the dll, instead you could move code in the codecave giving access on it.
Edit: have to edit cause might get misunderstood, if moving code to a dll, inline assembler allows to introduce variables always containing the right address computed by the compiler itself. These variables can be loaded to a register as you specify, e.g. eax and then used to access the static datafield inside the dll, at least in theoretics this should work with ease.
Edit2: It's even so the compiler just can replace the corresponding command parameters with the address contained within an inline assembler parameter, so in code it looks like the address gets called directly without a register in need. That's something I still experiment some with, cause e.g. passing a hex offset of trek.exe code directly to a call statement doesn't work or the compiler would mess it up, but that's nothing not to come around as registers can be pushed on stack and restored
That's why I made this proposal.
A simple codecave requires me a few minutes or less, a few hours is a worst case and as told I had to do some general research and partially forgot how to do it. I can't tell you exactly how long it would take me in average, that needs more experience.

As it sounds it would be a simple task, at least as long there are not too many places to cave.
But I don't want to burden you with work, wouldn't give me fun either.
You don't seem to have a good day, do you?
But I'm always amused by your humour, so np.

[Flocke]

I just tested to write to 0x68A000 and it crashed, just as expected cause other than you assumed, this piece of ada document has nothing to do with segment data read/write restrictions. It's just a programming language internal concept on pointer access, like declaring pointers and the objects referenced in c++ const which can be casted (in which case the compiler would have to take care of it, dunno, never tried).
So yes I keep with a no on that part, but maybe there's a way to change segment restriction in asm code.

[thunderchero]

This may be to simple of question, but what prevents this from working?

from what I have read and tested

• 1. UE will add extra ship names to the current 62 groups without error.
  2. shipname.bin has 2 sections
  • 1. "section 1" is number of ships names per group
    2. "section 2" name of ships
  3. The FC 00 00 00 after the section for number of ships names per group in shipname.bin has no effect?
  4. At 004753F2 and 00475430 we can effect the size of the data written to shipname.dat
  5. at 0x749C8 is offset of pointer for start of name list.