When PHost is run in phases, or shells out to execute an add-on (AUXHOST, PControl), it saves the data that is going to be UTILx.DAT files in a file called UTIL.TMP. You can try to make use of this.
The official reading is that add-ons that are just that -- add-ons -- should write to UTILx.EXT; add-ons that replace stages in PCONTROL can write to UTIL.TMP (to make their records come out at the right place). Add-ons can read this file to gather information about what PHost told the players yet.
Like UTILx.DAT, UTIL.TMP consists of multiple records.
Portable Format [PHost 3.4 and later] [V]
Each record starts with a header of the following format: +0 WORD Player Id (whose UTILx.DAT file will contain this data) +2 WORD Record Type. See UTILx.DAT in the `Player Data' section +4 WORD Record Length +6 n BYTEs Data
The data is in the format you'd expect, like in UTILx.DAT.
Unportable Format [PHost 3.3e and before] [T]
In these PHost versions, UTIL.TMP was just a temporary file. Hence it contains data in host byte order, with padding inserted by the compiler, which makes accessing it a quite fragile process. Your best bet is to declare a C struct, and hope it comes out the same way as it did in PHost.
For PHost 3.2e for "PC/DOS" (Borland C), the format is the following:
Each record: +0 DWORD Player Id (whose UTILx.DAT file will contain this data) +4 DWORD Record Type. See UTILx.DAT in the `Player Data' section +8 WORD Record Length +10 n BYTEs Data --- Type 13 (Control record - File Header) --- +0 18 BYTEs Timestamp +18 WORD Turn number +20 WORD Player number +22 WORD 0 (not in UTILx.DAT) +24 2 BYTEs PHost version +26 8 DWORDs Specification file digests +58 32 BYTEs Game Name +90 BYTE PHost Release Code +91 BYTE 0 (not in UTILx.DAT)
Under PHost 3.3e for x86/Linux (GNU C), the format is different (two padding bytes after the PHost version, two more at the end).
