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: Christian H. <fir...@pi...> - 2008-05-01 08:12:11
|
Hey there, Steven! Steven Snyder wrote: > I made a few changes to the system shock sound extractor (SS1SOUND) so > that it will compile and run on linux. I tested it and it works great. I > uploaded the code and makefile here: > http://stsnyder.bol.ucla.edu/projects/ss1soundlinux.tar.gz > I doubt anyone will get any use out of it except me.. but there it is, > just in case. Heh, I have long forgotten what's available on Glens pile - most (if not all) of the contained code is widely surpassed by the code of TSSHP and TSSHP2, yet Glens work still prevails with its 'naive' simplicity :) Thank you for your support! Have fun, ff1 |
|
From: Steven S. <ser...@gm...> - 2008-05-01 07:52:51
|
I made a few changes to the system shock sound extractor (SS1SOUND) so that it will compile and run on linux. I tested it and it works great. I uploaded the code and makefile here: http://stsnyder.bol.ucla.edu/projects/ss1soundlinux.tar.gz I doubt anyone will get any use out of it except me.. but there it is, just in case. -Steven |
|
From: Christian H. <fir...@pi...> - 2008-02-06 19:34:54
|
With the kind help of "Strange Bed Fellows" (http://www.strangebedfellows.de), I got hold of an image of the original Mac version -- although the image appears to be damaged, I have three resource files to chew on. First the easy stuff: Videos and Audio chunks are stored as separate files; Videos have their file names 'readable' and the audios a number (probably the chunk id). The audio files are raw PCM (8bit) files, with an 8 byte header. Now the tricky part: Resource files have the extension of rsrc (with the exception of Archive.data) - and they have a different basic structure than the intel variants (apart from the byte order of course). A first look makes me believe that there is no chunk compression, nor a bitmap compression. Also, chunks are not classified - ie, the directory contains no type identification on a chunk level - only the directory itself seems to have one. I don't know it, but this makes me believe that the Mac port was done by some different team (company?) that only received the raw resources and a fraction of the core game code... I'll polish my notes after I have given the files another look and will update the ss-specs document. With the platform itself becoming history, it is unclear if it is fruitfull to decipher the mac resources anyway. (Only if they really contain images in higher resolutions than 128x128 it will be interesting...) ff1 |
|
From: Christian H. <fir...@pi...> - 2003-05-10 13:24:39
|
I wrote: > Other than that the (my) high res videos have the same problems > as the low res ones. Either it's my Windows build or I'm doing > something stupid as both of your codes display the frames right on > your machine... Simple. Stupid. :/ MoviData::RenderNextFrame awaits the chunk index at which the next frame is to be searched from and returns the index of the next found. I guess I wasn't clear of the meaning of those two parameter, (I yet have to define it for sure) as the method had skipped frames. (the method took the chunk _after_ the given index and returned the index _after_ the rendered frame...) I'd laugh if I had done the same with the video mails... (to be optimistic: at least then I'd have no problems anymore ;) d'oh. ff1 -- "...the place was called: The World of the Seven Suns." |
|
From: Christian H. <fir...@pi...> - 2003-05-10 12:51:49
|
jim wrote: > it's a really nasty hack > I kludged up but it might give you some idea. It expects the video chunk > in a raw file of its own, I hacked resource.c to dump it into a file > rather than muck about with resfiles. I updated MoviData.cpp/.h with the weak and strong packing routines - reading from the resource chunk. > Right. I'm off to bed now, after a week of late nights hacking ... Thanks a lot. I'm sure I wouldn't have found that out by staring at the dump :) I guess I messed something up in the conversion, because some scenes have awkward colours -- I'll try to understand the compression and then I'll compare your code with the new one. Other than that the (my) high res videos have the same problems as the low res ones. Either it's my Windows build or I'm doing something stupid as both of your codes display the frames right on your machine... So, before I get to some descent high res decompression knowledge I'll first try to to fix my frame errors. thanks, ff1 -- "...the place was called: The World of the Seven Suns." |
|
From: jim <ji...@ma...> - 2003-05-08 22:17:53
|
Cracked it. http://tsshp.sourceforge.net/images/frame01a0.png http://tsshp.sourceforge.net/images/frame02de.png My god, but that video compression is hairy. I'll have a crack at making the documentation in some way comprehensible. I've attached the code to extract the video to a set of frames (PNG files), it's a really nasty hack I kludged up but it might give you some idea. It expects the video chunk in a raw file of its own, I hacked resource.c to dump it into a file rather than muck about with resfiles. No, I didn't figure all that out by staring at the hex dump. I isolated the bit of cdshock.exe that deals with the hi-res cutscenes and disassembled it, but don't tell EA! ;) Right. I'm off to bed now, after a week of late nights hacking ... Cheers, jim -- http://madeira.physiol.ucl.ac.uk/people/jim/ - Bill Stickers is innocent! |
|
From: jim <ji...@ma...> - 2003-05-07 21:09:54
|
Another tidbit: The (what I'm currently assuming to be) dictionary chunk with type 0d is itself compressed using a simple run-length scheme with word length 3: 3 bytes data and 1 byte count in each block. For example, if you encountered the group of 4 bytes f7 16 26 04 you would output f7 16 26 f7 16 26 f7 16 26 f7 16 26. The first 32-bit word in the chunk is the uncompressed length. jim -- http://madeira.physiol.ucl.ac.uk/people/jim/ - Bill Stickers is innocent! |
|
From: jim <ji...@ma...> - 2003-05-07 17:44:02
|
I've been investigating these on a slightly different tack ... it seems that the chunk type is determined by the low 3 bits of the type byte. This gives 6 (out of a possible 8) chunk types: 0 = end marker, 1 = video frame, 2 = audio, 3 = text control, 4 = palette, 5 = dictionary. The rest of the byte is additional information. In the case of a video frame, bits 3-6 determine the image type. 0xf here is the new high-res compression format, corresponding to a chunk type of 0x79. Otherwise it's just the ordinary image type: type 4 gives chunk type 0x21 which is indeed the usual System Shock RLE based coding. There are 2 types of dictionary chunk (I'm assuming, for the moment, that's what they are), 0x05 and 0x0d, as you know. That's all for the moment ... jim -- http://madeira.physiol.ucl.ac.uk/people/jim/ - Bill Stickers is innocent! |
|
From: Christian H. <fir...@pi...> - 2003-05-04 11:40:29
|
some additional thoughts/info: The 05/0D pairs seem to appear once for every scene (the amount of pairs matches with the amount of scenes per video) 05 could be some sort of dictionary. each (variable length) entry starts with byte 00 - oddly with some exceptions (i mean the first entry in some blocks) - also the amount of entries varies. The amount of entries in 05 does not match in any way with the amount of uint32 values in 0D - which makes my thoughts useless if they correlate somehow :/ ff1 -- "...the place was called: The World of the Seven Suns." |
|
From: Christian H. <fir...@pi...> - 2003-05-03 10:03:52
|
I wrote: > I'll start on hacking them, too. So far I've found out (from svgadeth.res): New unknown subchunks: 0x05, 0x0D, 0x79 05 & 0D always come up in pairs; death scene has both three of them, with 90 entries of 79 - so this seems to be where the frames are. 0D consists only of uint32 values in some sort of table (or better: tree ?) structure: Excerpt from Subchunk 0x0035: 60 14 01 00|34 02 B4 02.38 02 B4 02.E7 1D B6 02. EF 1D B6 02.F6 1D B6 02.FE 1D B6 02|92 00 A4 04| 00 07 82 10|C8 CA A2 04.00 CB A2 04|00 08 92 08| FE FE A0 04.8E 00 A4 04|00 06 B2 02.69 E6 B2 02. FE 01 B4 02.02 02 B4 02.06 02 B4 02.09 02 B4 02. 0C 02 B4 02.C8 1D B6 02.D0 1D B6 02.D7 1D B6 02. DF 1D B6 02|58 58 C0 01.5B 5B C0 01.F9 F9 C0 01. 00 70 C2 01.44 55 C2 01.1E 1F C2 01.00 AA C2 01. 00 97 C2 01.00 CF C2 01.F5 F6 C2 01.A5 A7 C2 01. 00 36 C2 01.00 27 C2 01.E1 04 C4 01.E4 04 C4 01. ... The pipes mark path borders, dots the leaves. I plainly went after the MSB - which also could be a bitfield as they always are of power of two. If 0D is a tree, perhaps 05 describes it's structure... Well - all this is just some brainstorming - I could be wrong about everything ;) ff1 -- "...the place was called: The World of the Seven Suns." |
|
From: Christian H. <fir...@pi...> - 2003-04-29 16:47:03
|
Started to decode the format of MOVI chunks. ss-specs.txt already contains all the latest news. Besides some fields in some general header infos I'm still missing any valuable 'timeline' (ie when to show which frame). The first three bytes of an EntryIndex in the master index table could be in relation with time, but I yet haven't found the scale. Furthermore the frame decompression/render process has the same problems as with VideoMail - frames become distorted or half of it is missing. ff1 -- "...the place was called: The World of the Seven Suns." |
|
From: jim <ji...@ma...> - 2002-10-18 17:18:54
|
These are quite hirsute. Recall that a shade command in an Underworld model definition has 2 (16-bit) parameters, colour and shade (darkness). The shade value is straightforward, but I couldn't for the life of me figure out how colour is encoded. And no wonder. The colour word is not in fact a colour index. It is the ADDRESS, in the model segment (remember segments?) of a location where the colour index is to be found. These are set up on the fly (in fact, rendering commands to set them are queued) when the model is encountered. So of course they are different for different models. The actual values are stored in a different table, not even in the model segment! These tables are of course in different places for Underworld and Underworld II. In fact, the colour table has a different field size (5 vs 4) for Underworld II. The file offsets are different for different builds (there are several builds extant) but I think the layout of the segments is the same within each game. I think it might be a good idea to throw out the sodding thing entirely, and rather than fishing in the exe to extract the things once and for all to a text file or some simple format. How does uwadv handle models? Cheers, jim -- http://madeira.physiol.ucl.ac.uk/people/jim/ - Bill Stickers is innocent! |
|
From: jim <ji...@ma...> - 2002-09-26 19:02:26
|
Scrolls, potions, wands. Most scrolls and potions use generic enchantments in the range 0-63. However there are some scrolls and potions of Hallucination with an enchantment value of 69 (581) mapping onto enchantment 213, and a wand of the Frog with an enchantment value of 67 (579) mapping onto enchantment 211. Looks as if the cutoff point is 64, and we add 144. What the exact range is I don't know, perhaps Underworld II will give a handle on that, but it's a big job to investigate all the enchantments there! The wand of the Frog is the only wand to be enchanted directly rather than via a spell, as it can never run out. jim -- http://madeira.physiol.ucl.ac.uk/people/jim/ - Bill Stickers is innocent! |
|
From: jim <ji...@ma...> - 2002-09-20 18:35:06
|
I wrote: > Most weapon enchantments are in the range 128-255, corresponding to spells > 384-511. Further investigation shows that special weapon or armour enchantments (Damage, Accuracy, Protection, Toughness) use enchantment values 192-207 ONLY. All other enchantments are normal spells and don't apply a correction. Special enchantments map to spells 448-463 for weapons and 464-479 for armour. I now have all weapon and armour enchantments correct. I'm wondering now if other classes of object use the same system, i.e. a range of values indicating a spell specific to the class, mapping to a spell in the range 256-511, with other enchantment values being generic spells. Certainly TSSHP gets at least some food/potion enchantments wrong (did you know there was a loaf of bread of Cure Poison lying about? I didn't). The other question, does a spell object act as its own class for the mapping, or as the class of the object which is actually enchanted? (wand etc.) > something ;) Link field is used for NPC name, no? No, I remembered, it's stored with the NPC data. But you couldn't have an enchanted critter because its common properties won't allow it. Cheers, jim -- http://madeira.physiol.ucl.ac.uk/people/jim/ - Bill Stickers is innocent! |
|
From: jim <ji...@ma...> - 2002-09-19 14:04:48
|
> Buggrit. Now it's talking about locks of magic. Evidently locks can't be > enchanted, and don't honour the enchantment flag, and presumably the same > for keys. That complicates the enchantability test somewhat. Never mind, > it looks to be correct in the main. No, I'm being stupid again. What do all the objects which break the enchantment flag have in common? They can't be picked up. If we suppose that the enchantment flag is only valid for gettable objects (this is bit 5 of the object properties flags) then all should work fine. Cheers, jim -- http://madeira.physiol.ucl.ac.uk/people/jim/ - Bill Stickers is innocent! |
|
From: jim <ji...@ma...> - 2002-09-19 13:24:31
|
Greetings all, and hi to the uwadv guys; this information isn't in your version of the specs document, so I'm ccing you in. A recent TTLG thread got me thinking about these, so I had a bit of a look to see if I could find out how enchantments are coded in Underworld. It's a bit confusing. A general note on the "link" field first. This is either a link (object index) or a quantity or special property. This is generally determined by the link flag in the flags field (bit 6 or bit 15 of the first object description word); if this is a 1, the link field is quantity/special (not a link). The exception is triggers, which have a flags value of 0x7e or occasionally 0x7c, yet their link field is a link to a trap. A quantity (link flag set) value of less than 512 is a quantity, otherwise is a special property. Objects with special properties or which link to other objects don't stack, of course. For an enchantment this is the spell type. The best guess I've got for an "enchanted" flag is bit 3 of the flags field (bit 12 of the first object description word); this works for scrolls, which have 0x4c flags if they are magical in which case the link field is the spell type, or 0x40 if they are not in which case the link field is the text. Fountains (some of them are healing fountains) seem to work this way too. Spells and potions have 0x4c flags as well; the 4 bit might be because they are consumed when used. Enchanted weapons and armour have 0x48 flags, and again the link is the spell type. However, this throws up some false positives. Triggers have an odd flags value, as I said above. Writing objects (the ones on the wall, not scrolls) may also have this flag set, although they aren't magical and their link field is the text. So I'm not sure about this "enchanted flag" as it were, but there must be one, surely? Or perhaps it only has this meaning if applied to an object which might or might not be enchanted? Wands act differently; they link to a spell object which holds the enchantment. Presumably this is because they also have a number of charges; I'm guessing that this is the "quality" field of the spell object. I don't see any reason why this shouldn't work for any kind of objects - there's certainly at least one sceptre of Deadly Seeker in Underworld II, and am I dreaming or do I remember a gem of some sort which boosted your mana? Both of which had limited charges. Let's go through the object classes. 000-01f Weapons : Enchantable, uses enchantment flag and link field 020-03f Armour : Enchantable, uses enchantment flag and link field 040-07f Critters : Not enchantable[1] 080-08f Containers: Not enchantable, link to inventory 090-097 Lights : Probably enchantable, but not much point 098-09f Wands : Enchanted, link to spell object 0a0-0af Loot : Enchantable, by linking to spell object or otherwise? 0b0-0bf Food/drink: Enchantable, uses enchantment flag and link field[2] 0c0-0df Junk : Probably enchantable, but not much point 0e0-0ff Quest/rune: Dunno. 100-10f Keys : Stackable, no point enchanting these[3] 110-12f Misc items: Enchantable, uses enchantment flag and link field[4] 130-13f Scrolls : Enchantable, uses enchantment flag and link field 140-14f Doors : Not enchantable, may link to a lock object 150-16f 3D/decal : Not enchantable[5] 170-17f Switches : Not enchantable, link to a use trigger 180-19f Traps : Not enchantable 1a0-1bf Triggers : Not enchantable, odd flags value 1c0-??? Anim objs : Not enchantable Actually, now I've tabulated them all it looks pretty easy; objects with an object_id less than 0x140 (start of doors) are enchantable, and honour the enchantment flag. All objects but triggers honour the link flag. I'd be inclined to think that any object may be enchanted by linking to a spell object. In such a case it is the SPELL OBJECT which has its enchantment flag set, NOT the object which is actually enchanted. Now, how does the value in the link field determine what spell an object holds? Well, it seems to be complicated. (No surprise there, then). Spell names are stored in string chunk 5 (counting from zero). Most enchantments seem to correspond to the second half of these, i.e. adjusted enchantment no. = adjusted special property + 256 (= link value - 256). This works for scrolls and potions. Fountains don't seem to add the 256; a typical enchanted fountain has a link value of 582, corresponding to a special value of 70, and index 70 is "Heal" in the spells list. Pretty good. Most weapon enchantments are in the range 128-255, corresponding to spells 384-511. So far so good. Most armour enchantments are similar, but they must add an extra 16 (there are 16 damage/accuracy spells followed by 16 protection/toughness spells). However (there's always that however, isn't there) when I tried out my object describer it asserted that there was a breastplate of Local Teleport somewhere on level 8. Not very likely. Subtract 256 from the spell index and you get Resist Blows, which is much more likely. Seems then that armour and weapon enchantments are coded differently: 0-127 are generic enchantments and are unmodified, 128-255 are specific weapon/armour enchantments corresponding to 256+stored value, or 16 more than that for armours. Buggrit. Now it's talking about locks of magic. Evidently locks can't be enchanted, and don't honour the enchantment flag, and presumably the same for keys. That complicates the enchantability test somewhat. Never mind, it looks to be correct in the main. Cheers, jim --Footnotes [1] Though I'd be interested to make a critter link to a spell object and see if Underworld comes up with "a friendly mountainman of Magic Arrow" or something ;) Link field is used for NPC name, no? [2] These include potions which are (almost) always enchanted, but there do exist such things as bottles of ale of Heal. Most foods are stackable however, and they can't be both. (Bit of trivia: the "red is rotten" potion in F^HIronwit's complex isn't enchanted in the usual way; it links to a damage trap). [3] These also include the lock object, which uses the link field to determine which key fits it. Oh - and doesn't honour the enchantment flag. Sod. [4] These include fountains, which may hold a Heal enchantment. I don't see why other objects in this class shouldn't be enchantable, though I can't recall any examples off hand. [5] These seem to use the enchantment flag for something else. -- http://madeira.physiol.ucl.ac.uk/people/jim/ - Bill Stickers is innocent! |
|
From: jim <ji...@ma...> - 2002-06-12 13:06:45
|
firefreak wrote: > Well - I would guess it's stored somewhere (should be when it comes to > savegames) -- As I understood, the archive.res is nothing more than > a savegame used for startup... not? Hadn't thought of it that way, but you're right, of course. The obvious place to look would be in chunks 4000 and 4001, but there doesn't seem to be a start position there. I suspect that 4001 is inventory, which is why it's practically empty in the initial archive. 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-12 13:04:51
|
firefreak wrote: > multi-colour: always in the same order No specific data needed. > 2-bit colour field: the two remaining 16bit fields don't seem to be > related to colour. but perhaps... Well there are only 2 (well, one and a half) fields left with anything in them. Although they might use some of the fields in the map_object. > > Not all of them necessarily have to be correct for the threshold > > to be reached. > hmm - I thought about that too - possible. Well, they do if the threshold is 100% but not otherwise, or there'd be no point having a threshold. > D'OH > A big Thank You there - and again, it was something small... ;) > As far as I have seen, the difficulty level only affects the > "side effects" of the puzzles. But I'll make field tests on this. There does seem to be an extra switch box on difficulty 3 for most puzzles, but I can't find its coordinates specified anywhere. The unknown bits of the puzzle description field in the panel info are source and destination for the power flow and side effects. I've added some info to the specs about that, and also some code to read puzzle information. Looks as if the puzzle type is determined by bit 28 of the helper xref / wire description word. Definite progress! 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: Christian H. <fir...@pi...> - 2002-06-11 15:56:13
|
jim wrote: > This would suggest that there are 4 colours; red, violet, blue, yellow, > which gives us a 2-bit colour field. If the multi-colour puzzles are > always in the same order we don't need individual colour fields, so > there's only one colour field for the whole puzzle. multi-colour: always in the same order 2-bit colour field: the two remaining 16bit fields don't seem to be related to colour. but perhaps... > Level 2 seems to have all wires same colours too, at least for some > puzzles. Yes - this is why I yet don't know what determines the colour. > Not all of them necessarily have to be correct for the threshold > to be reached. hmm - I thought about that too - possible. > I had a brief look last night and it seems that each wire has 4 states: > both ends wrong, wire pointing in wrong direction; one end correct; both > ends wrong, wire pointing in correct direction; wire in the right place. > In that order as far as amount of power given goes. I didn't notice that > how close an end is to its target connector makes a difference. That was just a thought from my side - I haven't done a field test like you did :) > Wrong endianness. D'OH A big Thank You there - and again, it was something small... > The helper trigger is indeed the state, and all of it is the state. The > other fields in the panel, or some of them, presumably give extra > switching nodes and/or blanks for higher difficulty levels. As far as I have seen, the difficulty level only affects the "side effects" of the puzzles. But I'll make field tests on this. 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-11 15:44:30
|
jim wrote: >>Another idea: is the startup position of the player hardcoded >>within the exe, or is the healing suite the current location of >>the player object within archive.res? > > Hardcoded as far as I know (which isn't very far). I don't think there is > such a thing as a player object. Course, it's only 4 bytes to look for > amongst however many ... Well - I would guess it's stored somewhere (should be when it comes to savegames) -- As I understood, the archive.res is nothing more than a savegame used for startup... not? 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: jim <ji...@ma...> - 2002-06-11 12:26:38
|
firefreak wrote: > jim wrote: > > How many different wire colours are there? I can't remember off hand. A= re > > there any wire puzzles on higher Puzzle settings that have all wires th= e > > same colour? >=20 > I've found: > - all yellow, all blue, all violet > - combination of red, violet, blue, yellow (always in this order) This would suggest that there are 4 colours; red, violet, blue, yellow, which gives us a 2-bit colour field. If the multi-colour puzzles are always in the same order we don't need individual colour fields, so there's only one colour field for the whole puzzle. > > level 0 instant solution; > > level 1 all wires same colours=20 > > level 2 threshold as given; > > level 3 full power always needed. Is this right? Level 2 seems to have all wires same colours too, at least for some puzzles. > ok, but I don't see any big difference between 2 and 3 as the > power level per wire is relative to the solve level - it must > be because the target state of the puzzle doesn't change... > Or did I miss something? (just made a testgame: on level 3 > always the 4 colour combo is used and full power is to be > reached) Why should power per wire be relative to solve level? The target state of the puzzle has nothing to do with threshold power, it just determines the "correct" states of the wires. Not all of them necessarily have to be correct for the threshold to be reached. > > Likely B I'd have said ... try subtracting target from actual for all t= he > > 3-bit fields. >=20 > hmm... this could be an idea. I had a brief look last night and it seems that each wire has 4 states: both ends wrong, wire pointing in wrong direction; one end correct; both ends wrong, wire pointing in correct direction; wire in the right place. In that order as far as amount of power given goes. I didn't notice that how close an end is to its target connector makes a difference. > >>Power Puzzles: > >>Unfortunately, the state is coded in a weird way. > > Plus =E7a change, eh? >=20 > I've updated the scratchpad in trigger.c with all the possible > states for the small puzzle on level 7. Ignoring the rightmost > byte of the trigger info, you can line up the bits in > triples, so that the 3 nodes are (mostly) determined by > 001 =3D X > 010 =3D + > (000 could be empty, and 011 a full block...) >=20 > for example: state + + X has state bytes ... 0xA4 0x00 > bit triples: ... 001 010 010 000 000 000 >=20 > per definition this puzzle has a size of 3x3, so it seems to > be that the three zero nodes are the empty line on the top. >=20 > BUT: state X X + has state bytes ... 0x12 0x01 > bit triples: ... 000 001 001 000 000 001 >=20 > huh?? Wrong endianness. xxx -> 0092 -> (000000) 001 001 001 (0) xx+ -> 0112 -> (000000) 010 001 001 (0) x+x -> 00A2 -> (000000) 001 010 001 (0) and so on. I suggest the following algorithm. 9*3 =3D 27, round up to 32 so we have 4 bytes of data. Start from the 4th byte counting BACKWARDS, 00 92 00 00. When we need a bitfield take the bottom 3 bits. When we need a new byte rotate it in at the top. 00009200 -> 000 -> 00001240 [ ] 00001240 -> 000 -> 00000248 [ ] 00000248 -> 000 -> 00000049 [ ] 00000049 -> 001 -> 00000009 [x] 00000009 -> 001 -> 00000001 [x] 00000001 -> 001 -> 00000000 [x] =2E.. and the rest are blank, of course. > Furthermore the very first puzzle on Medical (my second I'm hacking > on) has some states documented in the scratchpad. > One state has all nodes off, another one with all nodes on. > The difference between those two states should point out the alignment > for the node triples, but it doesn't conclude to a period. > And there are some bits (marked with ?) which pop up without any > reason... Ooops, that doesn't work for the medical one. Hold on ... BINGO! Got it! Start with the last 32-bit word in the definition, rotating bits out 3 at a time from the bottom. When you run out, keep the bits you've got and start from the bottom bit of the next previous word (so the bottom bit of the word at offset 0x14 is the top bit of the 11th triple). Keep going until you've got them all. This takes up (potentially) all 16 "special" bytes of the trigger definition, giving a maximum of 127 bits for a 3x9 grid. Take for example a 4x3 grid: abcd efgh ijkl The bitfields in the last 2 words are 0x14: ---- ---- ---- ---- ---- ---- ---- lllk 0x18: kkjj jiii hhhg ggff feee dddc ccbb baaa You were right, they're coded in a weird way. > Doesn't seem to be. The helper trigger ought to be the state, > but I just don't get it's key... The helper trigger is indeed the state, and all of it is the state. The other fields in the panel, or some of them, presumably give extra switching nodes and/or blanks for higher difficulty levels. > > Sometimes condition is the C/S/T of the object to stick into it.=20 > > Is there a flag for condition type, or does it depend on panel type? >=20 >=20 > I guess panels always need an object to attach to. > Let's storm brain: Isotope, Relais 428, Retina Scan, Antennas, > Chipset -- any more? Not that I can think of, no. There are other quest items defined, but not used. > d'oh -- just looked at the scratchpad; The antennas have a zero > condition (btw: the Maintenance panel in the scratchpad is any > random one -- didn't know the way to 428 by heart ;) Well, perhaps antenna panels are a special case, then. You do have to open them first. What are the chances that the dev team kept the blast doors to Maintenance shut until the demodulator was needed because they didn't have any way for the panel to conditionally refuse to accept it? 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-11 10:38:50
|
firefreak wrote: > Anyway - so at least we have a solid reference where to drop > off the character. Yarh. That's a start ;) We ought to start thinking about level transitions, and to what extent the engine can survive without a level loaded, if you see what I mean. That's for the devlist tho. > Another idea: is the startup position of the player hardcoded > within the exe, or is the healing suite the current location of > the player object within archive.res? Hardcoded as far as I know (which isn't very far). I don't think there is such a thing as a player object. Course, it's only 4 bytes to look for amongst however many ... 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-10 20:50:25
|
jim wrote:
> How many different wire colours are there? I can't remember off hand. A=
re
> there any wire puzzles on higher Puzzle settings that have all wires th=
e
> same colour?
I've found:
- all yellow, all blue, all violet
- combination of red, violet, blue, yellow (always in this order)
> level 0 instant solution;
> level 1 all wires same colours=20
> level 2 threshold as given;
> level 3 full power always needed. Is this right?
ok, but I don't see any big difference between 2 and 3 as the
power level per wire is relative to the solve level - it must
be because the target state of the puzzle doesn't change...
Or did I miss something? (just made a testgame: on level 3
always the 4 colour combo is used and full power is to be
reached)
> Likely B I'd have said ... try subtracting target from actual for all t=
he
> 3-bit fields.
hmm... this could be an idea.
>>Power Puzzles:
>>Unfortunately, the state is coded in a weird way.
> Plus =E7a change, eh?
I've updated the scratchpad in trigger.c with all the possible
states for the small puzzle on level 7. Ignoring the rightmost
byte of the trigger info, you can line up the bits in
triples, so that the 3 nodes are (mostly) determined by
001 =3D X
010 =3D +
(000 could be empty, and 011 a full block...)
for example: state + + X has state bytes ... 0xA4 0x00
bit triples: ... 001 010 010 000 000 000
per definition this puzzle has a size of 3x3, so it seems to
be that the three zero nodes are the empty line on the top.
BUT: state X X + has state bytes ... 0x12 0x01
bit triples: ... 000 001 001 000 000 001
huh?? Plus: in every state having the rightmost node on (+) the
corresponding triple is zero and the first (rightmost) one is 001
(see scratchpad) -- It just doesn't make any sense...
Furthermore the very first puzzle on Medical (my second I'm hacking
on) has some states documented in the scratchpad.
One state has all nodes off, another one with all nodes on.
The difference between those two states should point out the alignment
for the node triples, but it doesn't conclude to a period.
And there are some bits (marked with ?) which pop up without any
reason...
Jim, do you have any suggestion on this?
> There aren't any more cross-references anywhere, are there?
Doesn't seem to be. The helper trigger ought to be the state,
but I just don't get it's key...
> Sometimes condition is the C/S/T of the object to stick into it.=20
> Is there a flag for condition type, or does it depend on panel type?
I guess panels always need an object to attach to.
Let's storm brain: Isotope, Relais 428, Retina Scan, Antennas,
Chipset -- any more?
d'oh -- just looked at the scratchpad; The antennas have a zero
condition (btw: the Maintenance panel in the scratchpad is any
random one -- didn't know the way to 428 by heart ;)
ff1
--=20
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-10 20:04:16
|
jim wrote: > 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. ahh - now I got you - ok. > We should probably make a list of game global variables (what a spoilery > document that would be). heh, it probably would. But also very helpful - within ss-specs ? (And also a good base for tech-speak: "Help, I'm stuck in the game!" "Have you set variable 15 already?" "What?" "err - jettisoned Beta..." ;) 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-10 20:01:08
|
jim 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. /me places hand on forehead I tried it out... I guess I just dreamed about that. Anyway - so at least we have a solid reference where to drop off the character. Another idea: is the startup position of the player hardcoded within the exe, or is the healing suite the current location of the player object within archive.res? 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. |