Menu
▾
▴
tsshp-hackers — Hacking Looking Glass' data formats; discussion of the unofficial specs
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
(25) |
Jul
|
Aug
|
Sep
(4) |
Oct
(1) |
Nov
|
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: jim <ji...@ma...> - 2002-06-10 16:31:11
|
firefreak wrote: > d'oh - problem: on plotlevel 0, all the decks being specified in the > second field are accessbible - what now? Eh? No they aren't. jim -- http://madeira.physiol.ucl.ac.uk/people/jim/ "... I naturally gravitated to London, that great cesspool into which all the loungers and idlers of the Empire are irresistibly drained." - Sir Arthur Conan Doyle, "A Study in Scarlet" |
|
From: jim <ji...@ma...> - 2002-06-10 16:13:13
|
firefreak wrote: > Wire Puzzles: > Their state IS stored within the switch info (I forgot to > copy my savegame to the datadir shack uses ;) :) > Both the IS and SHOULD states are stored within a 32 bit > field each. (should: offset 0x0014, is: offset 0x0018) > Each bitfield is made up by 2 three bit combos describing one > connection (wire). Giving a maximum of 5 wires and 8 connectors each side, I make it. > This makes only two int16 fields remaining to be hacked. > I tried to associate them with the wire colors, together with > the class type (Wire puzzles appear to have 9 3 1, 9 3 2, 9 3 3) - > but failed (always one exception turned up...). > Perhaps the amount of wires is another parameter for the colors... How many different wire colours are there? I can't remember off hand. Are there any wire puzzles on higher Puzzle settings that have all wires the same colour? AIUI the various puzzle settings for wires are: level 0 instant solution; level 1 all wires same colours (presumably the OR of the different wire fields is checked); level 2 threshold as given; level 3 full power always needed. Is this right? > Another info I'm missing is the power level one wire gives. > a) The power level is hardcoded associated with the color > b) (more likely) the power output is calculated on how 'near' > the wire is to it's target connection... Likely B I'd have said ... try subtracting target from actual for all the 3-bit fields. > Power Puzzles: > The second Map Object reference adresses a trigger object > being an action 0x00 trigger without condition. > The 'private' bytes of the trigger object appear to describe > the state of the puzzle. A-ha! Another helper null trigger. > Unfortunately, the state is coded in a weird way. Plus =E7a change, eh? >=20 > The most simplest puzzle for example (lvl7, last antenna, > first puzzle to get in) has only three nodes (init: X X X). > The initial trigger state has three identical entries > (using proper bit alignment so that the nodes are described > with 3 bits each) -- but changing the puzzle to "X + +" made > unrelated changes to the trigger state... >=20 > Could it be compressed? Could be but I'm inclined to doubt it. There aren't any more cross-references anywhere, are there? > I've updated the code (also added trigger.c which loads the > raw data; plus another scratchpad ;) plus the ss-specs doc > with the info we figured out already. Great work, thanks. We can say that all triggers and switches have the same basic format (switches and panels have an extra 16-bit field which we don't know what it is yet). This is index, prev, next (as always), action (0 for default, which tends to be the case for switches), condition (4 bytes), then links and special. A trigger link field is 4 bytes; the first 16-bit word is the object index of the target trigger, I think the second is a delay. (A propagate trigger action 6 just has 4 link fields). Here's another little tidbit for you: the X-22 panel on level R has condition code 00 07 08 00. Isotope X-22 is object 8/7/0. Sometimes condition is the C/S/T of the object to stick into it. Is there a flag for condition type, or does it depend on panel type? jim --=20 http://madeira.physiol.ucl.ac.uk/people/jim/ "... I naturally gravitated to London, that great cesspool into which all t= he loungers and idlers of the Empire are irresistibly drained." - Sir Arthur Conan Doyle, "A Study in Scarl= et" |
|
From: jim <ji...@ma...> - 2002-06-10 15:21:16
|
firefreak wrote:
> > I'm beginning to be of the opinion that the low 12 bits of the
> > first word is variable ID and the high 4 comparison type (0 equals,
> > 5 less than?). Then byte 2 would be value and byte 3 fail message.
>
> I guess there's more to that:
> Elevator 6->Beta has 0F 00 00 5E (0x000F, 0x00, 0x5E)
> Elevator 6->7 has 0F 00 01 20 (0x000F, 0x01, 0x20)
>
> 0x000F appears to be the check for the jettison.
> msg 0x5E is "Beta Grove already jettisoned."
> msg 0x20 is "Elevator disabled: BioHazard emergency."
>
> so the 0x01 seems to be a NOT operator (inverting the if/else for
> the msg)...
I think you misunderstood. I was suggesting that the second field is the
VALUE and the top nybble of the first the condition type. The fail message
has an implicit "else" attached. So in pseudo-code 6-Beta would be
if (g15 == 0) { do stuff; } else message (0x5e);
and 6-7 is
if (g15 == 1) { do stuff; } else message (0x20);
which makes perfect sense if variable 15 is the beta jettisoned flag.
We should probably make a list of game global variables (what a spoilery
document that would be).
jim
--
http://madeira.physiol.ucl.ac.uk/people/jim/
"... I naturally gravitated to London, that great cesspool into which all the
loungers and idlers of the Empire are irresistibly drained."
- Sir Arthur Conan Doyle, "A Study in Scarlet"
|
|
From: Christian H. <fir...@pi...> - 2002-06-09 10:36:48
|
jim wrote: > I'm beginning to be of the opinion that the low 12 bits of the > first word is variable ID and the high 4 comparison type (0 equals, > 5 less than?). Then byte 2 would be value and byte 3 fail message. I guess there's more to that: Elevator 6->Beta has 0F 00 00 5E (0x000F, 0x00, 0x5E) Elevator 6->7 has 0F 00 01 20 (0x000F, 0x01, 0x20) 0x000F appears to be the check for the jettison. msg 0x5E is "Beta Grove already jettisoned." msg 0x20 is "Elevator disabled: BioHazard emergency." so the 0x01 seems to be a NOT operator (inverting the if/else for the msg)... ff1 -- It is a great thing when you realize that you still have the ability to surprise yourself. Makes you wonder what else you can do. |
|
From: Christian H. <fir...@pi...> - 2002-06-09 10:27:26
|
heya; big news:
Wire Puzzles:
Their state IS stored within the switch info (I forgot to
copy my savegame to the datadir shack uses ;)
Both the IS and SHOULD states are stored within a 32 bit
field each. (should: offset 0x0014, is: offset 0x0018)
Each bitfield is made up by 2 three bit combos describing one
connection (wire).
This makes only two int16 fields remaining to be hacked.
I tried to associate them with the wire colors, together with
the class type (Wire puzzles appear to have 9 3 1, 9 3 2, 9 3 3) -
but failed (always one exception turned up...).
Perhaps the amount of wires is another parameter for the colors...
Another info I'm missing is the power level one wire gives.
a) The power level is hardcoded associated with the color
b) (more likely) the power output is calculated on how 'near'
the wire is to it's target connection...
Power Puzzles:
The second Map Object reference adresses a trigger object
being an action 0x00 trigger without condition.
The 'private' bytes of the trigger object appear to describe
the state of the puzzle.
Unfortunately, the state is coded in a weird way.
The most simplest puzzle for example (lvl7, last antenna,
first puzzle to get in) has only three nodes (init: X X X).
The initial trigger state has three identical entries
(using proper bit alignment so that the nodes are described
with 3 bits each) -- but changing the puzzle to "X + +" made
unrelated changes to the trigger state...
Could it be compressed?
I've updated the code (also added trigger.c which loads the
raw data; plus another scratchpad ;) plus the ss-specs doc
with the info we figured out already.
ff1
--
It is a great thing when you realize that you still have
the ability to surprise yourself.
Makes you wonder what else you can do.
|
|
From: Christian H. <fir...@pi...> - 2002-06-07 16:57:45
|
jim wrote: > Yes, since elevator panels are always inside the elevator, its coordinates > give the tile where the player ends up. Neat. d'oh - problem: on plotlevel 0, all the decks being specified in the second field are accessbible - what now? ff1 -- We're the good guys. |
|
From: jim <ji...@ma...> - 2002-06-07 16:37:00
|
firefreak wrote: > jim wrote: > > > Elevators: The other elevator parameters give the object ID of the panels > > on each level. > > So this would be the reference where to drop off the character in the > target level, right? Yes, since elevator panels are always inside the elevator, its coordinates give the tile where the player ends up. Neat. jim -- http://madeira.physiol.ucl.ac.uk/people/jim/ "... I naturally gravitated to London, that great cesspool into which all the loungers and idlers of the Empire are irresistibly drained." - Sir Arthur Conan Doyle, "A Study in Scarlet" |
|
From: jim <ji...@ma...> - 2002-06-07 15:39:11
|
firefreak wrote: > I just had a thought: what if those Variable Values aren't the value > itself, but an index into a levels (or 'Global Game') Variable Table? > Also the Trigger Table adresses Variables throught 16bit values. Certainly there would be a set of game globals, yes. I'm beginning to be of the opinion that the low 12 bits of the first word is variable ID and the high 4 comparison type (0 equals, 5 less than?). Then byte 2 would be value and byte 3 fail message. jim -- http://madeira.physiol.ucl.ac.uk/people/jim/ "... I naturally gravitated to London, that great cesspool into which all the loungers and idlers of the Empire are irresistibly drained." - Sir Arthur Conan Doyle, "A Study in Scarlet" |
|
From: Christian H. <fir...@pi...> - 2002-06-07 15:37:13
|
I forgot: jim wrote: > Elevators: The other elevator parameters give the object ID of the panels > on each level. So this would be the reference where to drop off the character in the target level, right? ff1 -- We're the good guys. |
|
From: Christian H. <fir...@pi...> - 2002-06-07 15:31:19
|
jim wrote:
> 0008 >= 01 else message 1f, or something to that effect.
> Presumably an ff in that field gives the SHODAN face and "blocked" message ...
and:
> I submit that 501x == level x security, likely counting down from 0.
I just had a thought: what if those Variable Values aren't the value
itself, but an index into a levels (or 'Global Game') Variable Table?
Also the Trigger Table adresses Variables throught 16bit values.
So: assuming that is true, the game and each deck would need a
table of the current state of the variables (or init state in
archive.res)
idea?
ff1
--
We're the good guys.
|
|
From: jim <ji...@ma...> - 2002-06-07 15:21:21
|
firefreak wrote: > jim wrote: > > > The condition for getting an elevator to go up to level 6 is 0008 1f01. > > What is this in-game? > > That would be the elevator from 3 to 6, right? > If you want to go up there but haven't destroyed the laser yet, the > Message says something like "Power diverted to Reactor Level". > I encountered this once a long time ago. "power diverted to level R" is string 31 in the trap messages chunk ... might that be the 1f then? Bingo! 0008 >= 01 else message 1f, or something to that effect. Presumably an ff in that field gives the SHODAN face and "blocked" message ... jim -- http://madeira.physiol.ucl.ac.uk/people/jim/ "... I naturally gravitated to London, that great cesspool into which all the loungers and idlers of the Empire are irresistibly drained." - Sir Arthur Conan Doyle, "A Study in Scarlet" |
|
From: Christian H. <fir...@pi...> - 2002-06-07 15:13:54
|
jim wrote: > The condition for getting an elevator to go up to level 6 is 0008 1f01. > What is this in-game? That would be the elevator from 3 to 6, right? If you want to go up there but haven't destroyed the laser yet, the Message says something like "Power diverted to Reactor Level". I encountered this once a long time ago. ff1 -- We're the good guys. |
|
From: jim <ji...@ma...> - 2002-06-07 15:07:13
|
Elevators: The other elevator parameters give the object ID of the panels on each level. Offset 0c = 2nd level, 0e = lowest level, 12 = highest level for a 3-level elevator. The condition for getting an elevator to go up to level 6 is 0008 1f01. What is this in-game? jim -- http://madeira.physiol.ucl.ac.uk/people/jim/ "... I naturally gravitated to London, that great cesspool into which all the loungers and idlers of the Empire are irresistibly drained." - Sir Arthur Conan Doyle, "A Study in Scarlet" |
|
From: jim <ji...@ma...> - 2002-06-07 14:42:49
|
firefreak wrote: > > The 4 "security" (condition for operation) bytes > > are the same as for doors, I think it's a game variable and value. > > It could also be the level of security to be (b)reached, as they > are 4 bytes for 4 plot levels having the last one at 0xFF which > could be in relation to 'no security' on plot 0... but it would > also mean that this table and it's values are double-inverted... I never thought of that, but now you mention it you're probably right. How about minimum security for activation, out of 255? On second thoughts, no. Level 1 armoury: 5011 FFCD. Level 4 McLeod's office: 5014 FF60. Level 1 elevator: 5011 FF60. I submit that 501x == level x security, likely counting down from 0. Panel actions seem to be mostly the same format as triggers, check the specs. > I've played a bit, edited some of the puzzles & wires and then loaded > the savegame: Unfortunately the state of them wasn't stored within the > 30 Bytes. So these 30 Bytes only 'describe' the Switch, and it's state > is stored somewhere else. > That's just about 600k bytes to be searched... :/ Blerh. So the puzzle info only stores the default state. jim -- http://madeira.physiol.ucl.ac.uk/people/jim/ "... I naturally gravitated to London, that great cesspool into which all the loungers and idlers of the Empire are irresistibly drained." - Sir Arthur Conan Doyle, "A Study in Scarlet" |
|
From: Christian H. <fir...@pi...> - 2002-06-06 21:53:21
|
heya jim wrote: > Good going! Tiny tidbit for you: the fields at byte offsets 0x0c and 0x10 > of cyberjacks are the start x and y coords on entry to c/space, and 0x14 > is almost certainly z. ah - thanks. > The 4 "security" (condition for operation) bytes > are the same as for doors, I think it's a game variable and value. It could also be the level of security to be (b)reached, as they are 4 bytes for 4 plot levels having the last one at 0xFF which could be in relation to 'no security' on plot 0... but it would also mean that this table and it's values are double-inverted... some additional info: I've played a bit, edited some of the puzzles & wires and then loaded the savegame: Unfortunately the state of them wasn't stored within the 30 Bytes. So these 30 Bytes only 'describe' the Switch, and it's state is stored somewhere else. That's just about 600k bytes to be searched... :/ ff1 -- We're the good guys. |
|
From: jim <ji...@ma...> - 2002-06-06 17:40:49
|
I'm moving this to hackers ... firefreak wrote: > As promised quite some days ago, I started to hack the > switch info. Although not much found out yet, I already got > some vital values (eg accessable decks for elevator panel, > size of puzzles, ...) Good going! Tiny tidbit for you: the fields at byte offsets 0x0c and 0x10 of cyberjacks are the start x and y coords on entry to c/space, and 0x14 is almost certainly z. The 4 "security" (condition for operation) bytes are the same as for doors, I think it's a game variable and value. > I've set up a small scratchpad on top of switch.c which I'll > remove again when (most of) the info is revealed. Looking at it now. > Funny, years ago I spent hours on solving the puzzles; Now > I'm spending hours on how they actually work ;) ;) Cheers, jim -- http://madeira.physiol.ucl.ac.uk/people/jim/ "... I naturally gravitated to London, that great cesspool into which all the loungers and idlers of the Empire are irresistibly drained." - Sir Arthur Conan Doyle, "A Study in Scarlet" |
|
From: jim <ji...@ma...> - 2002-04-02 15:11:10
|
> I currently do some hacking on ultima underworld 1, just as you do for system > shock. For this, I got the uw-specs.txt from CVS. Well, I do both really, but more on System Shock at the moment mainly because there's more of it. > I'm currently trying to build a virtual machine for the conversations > stored in cnv.ark. I already can load the code and process the > assembler-like opcodes, Good work! That's more than I've done on the conversation engine. > but have problems with some stuff, e.g. the imported functions list. Do > you have more info on the conversations, or from where did you get the > specs for that? Ah, the imported functions list. The specs are rather incomplete in that area: I've fairly well figured it out though. I got the specs from eyeballing the resource files, mainly, though a strings run on the executable is instructive, and throws up among other things the list of opcode names. You'll note that the virtual code is structured very much like C in that it's stack based: there are even stack frame instructions SPTOBP and BPTOSP, because on the x86 it's normally the BP register that is used as the frame pointer. A conversation is divided into functions which use local variables and parameters on the stack (accessed by the PUSHI_EFF instruction), as do most C implementations, and each conversation also has its own private global variables block. Globals are controlled by the file babglobs.dat - there are 4 bytes per defined conversation, a 16-bit word for its slot number within cnv.ark and a 16-bit word giving the number of words of private space. In saved games these are followed for each conversation with the current values of these globals. The reason I'm blathering on about memory is that the imports table contains not only builtin functions but imported game-global variables as well. The conversation header is 16 bytes: the last 2 give the number of imports in the imports table, and the table follows straight on from that. I'll give the structure of the imports table (and hope the tabs don't come out garbled): 0000 int16 Length of import name (=n) 0002 n*char Import name n+02 int16 ID (builtin) / memory address (variable) n+04 int16 [ Seems always to be 1 ] n+06 int16 Import type (0x010F=variable, 0x0111=builtin) n+08 int16 Return type (0x0000=void, 0x0129=int, 0x012B=string) A builtin ID can be the same as a variable ID since these can never overlap. I suspect the arbitrary type numbers are indices into a large table, likely a big function call table. On entry to the conversation the game globals referenced (by name) in the imports table are loaded into the conversation's private global memory space, at the addresses given in the ID field. On exit they (at least, the npc_xx variables from the critter information) are updated from conversation memory in case they have been altered. Of course, the initial values of the npc_xx variables will depend on which NPC the conversation refers to. (Some conversations may refer to any of several different individual NPCs, e.g. the generic troll and goblin scripts). The builtins just grab some parameters off the stack, do something built-in with them and maybe return a value (in the result register). It should be fairly easy to grok what most of them do, though you'll have to eyeball the code to get the correct parameter format, of course. That ought to give you something to be going on with. It's really an amazingly flexible and sophisticated system. I've cc'd in the hackers' list as this is of general interest, and I'll add some more info to the unofficial specs next time I do a commit. I managed to write a decompiler a while back that sort of works (some of the more complex control structures still come out garbled: flow analysis is hard to do) but never integrated it into the main TSSHP release. Perhaps I should do that ...? Cheers, jim -- http://madeira.physiol.ucl.ac.uk/people/jim/ "... I naturally gravitated to London, that great cesspool into which all the loungers and idlers of the Empire are irresistibly drained." - Sir Arthur Conan Doyle, "A Study in Scarlet" |
|
From: jim <ji...@ma...> - 2002-02-26 13:47:31
|
I wrote: > It would seem that in cyberspace (only), when the available softs/logs > have run out, objects of class 7 are co-opted as extra ones. Yup. Looks like the fixture information in this case is 0006 int16 version no. (softs) 0008 int16 subclass 000C int16 type There might be level/log no. information there as well in case the fixture is taking the place of a log. jim -- http://madeira.physiol.ucl.ac.uk/people/jim/ "... I naturally gravitated to London, that great cesspool into which all the loungers and idlers of the Empire are irresistibly drained." - Sir Arthur Conan Doyle, "A Study in Scarlet" |
|
From: jim <ji...@ma...> - 2002-02-25 14:26:23
|
Well, I did hope that by now we'd have pretty much complete c/space support, but something cropped up involving softs and logs class 6. I hacked up a special renderer for these in c/space (the spinning cuboids, though they won't actually spin in TSSHP for a while), but it started tripping an assert(). (Side note: assert()s are great, use them kids). Specifically, it was being passed objects not of class 6. Even more specifically, it was getting 7/3/2, glow bulb. GLOW BULB?! WTF? A quick hack confirms that these objects are in the right place to be softs, but are actually classed as fixtures. Now fixtures aren't normally used in c/space (arrows and wotnot are actually class 8), and there are only slots available for 15 softs/logs. This is enough for a "real-world" level, but not for c/space. It would seem that in cyberspace (only), when the available softs/logs have run out, objects of class 7 are co-opted as extra ones. I have still to figure out the mapping though. Guys ... why didn't you just allocate some more softs/logs? They're only 9 bytes ...! In fact, the scene in my head now goes something like: Designer: We need some more softs slots. LG hacker: Can't. That table size is fixed. Designer: But 15 softs isn't nearly enough for a big cyberspace level! LG hacker: Hmmm. How about we use class 7? That table is just going to waste as it is. Call the extra objects ... glowbulbs, we don't use them, and we'll make them act as softs in c/space levels. I can ... kind of see the logic there. Anyway, I'll have to figure out the mapping between fixtures and logs before we get full support. Shouldn't be too hard. Cheers, jim -- http://madeira.physiol.ucl.ac.uk/people/jim/ "... I naturally gravitated to London, that great cesspool into which all the loungers and idlers of the Empire are irresistibly drained." - Sir Arthur Conan Doyle, "A Study in Scarlet" |
|
From: jim <ji...@ma...> - 2001-12-03 13:55:22
|
[ crosspost from the Hackers' forum on SourceForge ] I believe that I have finally cracked the System Shock lightmap system. Each tile has 2 light (well, dark really) fields, "upper" and "lower" of 4 bits each, in the tile flags (bits 24-27 upper and 16-19 lower). The way this is mapped onto vertices is very simple, which is probably why I had such trouble figuring it out. If a vertex belongs to a ceiling or is one of the top vertices of a wall panel it gets the "upper" light value. If it belongs to a floor or is one of the bottom vertices of a wall panel it gets the "lower" light value. Surfaces are then Gouraud-shaded in the usual way. Dynamic lighting uses the last "state" byte of a tile definition. The 2 nybbles of this byte are subtracted from the upper and lower dark values before performing any lighting calculations. jim -- http://madeira.physiol.ucl.ac.uk/people/jim/ "... I naturally gravitated to London, that great cesspool into which all the loungers and idlers of the Empire are irresistibly drained." - Sir Arthur Conan Doyle, "A Study in Scarlet" |
|
From: jim <ji...@ma...> - 2001-10-09 17:53:08
|
In the Ultima Underworlds, when you `apply' certain objects to one another in your inventory a new object is created. For example, pole + strong thread = fishing pole. The mechanism for this is very simple and is controlled by the file cmb.dat in the data/ directory. This file contains a table of 3 16-bit words for each allowable combination: `source1', `source2', `newobject' in that order. 3 zeros mark the end of the table. The low 9 bits of each word is the object ID. If an object of type source1 is applied to an object of type source2 (or vice versa) an object of type newobject is created. The top bit of each of the source words indicates whether that object is destroyed in the process: if it is a 1, the object is destroyed. (It is always the case that at least one of the source objects is destroyed: you can't create something from nothing, at least not this way). jim -- http://madeira.physiol.ucl.ac.uk/people/jim/ "... I naturally gravitated to London, that great cesspool into which all the loungers and idlers of the Empire are irresistibly drained." - Sir Arthur Conan Doyle, "A Study in Scarlet" |