| Xorcist |
Hi, just wondering if anyone knows the format of the file that gets created at the end of Hero's Quest for import to Quest for Glory 2. The first X bytes seem to be used for the name followed by a seperator and then a series of 86 bytes that I assume map to the various attribute values and items held (data after the plain text name might be encrypted, but I can't be sure). If anyone has any info pass it my way, otherwise I'll just have figure it out the hard way. |
| Xorcist |
Okay I was able to get my hands on some of the script, but don't know a great deal about the original language itself. Can anyone point me in the right direction as far as documentation. Things like data types used when declaring variables an such. Is everything basically a byte (and arrays of bytes)? And operator meanings... I assume & and | are logical AND and OR respectively, but there is another ^ which normally I would assume is used for exponents, but seems to be used in the manner X ^= Y, so I'm not quite sure what's going on there. Any help would be appreciated. |
| Xorcist | Stupid me... once again over-analysing everything. I'm pretty sure ^= is setting one pointer equal to another. So much for my programming degree... god I feel stupid. Correct me if I'm wrong though. |
| Joel | I don't know for sure about what you're looking at, but in C the ^ operator is a bitwise exclusive or. |
| Xorcist |
Crap! That's right... like I said, so much for my programming degree, that's what years of prolonged exposure to Pascal will do to you. Thanks for the info (I really do need to brush up on my C). I just downloaded SCI Studio, so hopfully there will be a decent amount of info on the scripting language in there. Thanks again, I'll post when I've got some more info on the file generation (either then, or when I need more help). :) |
| Brian_Provinciano |
Yeah, there are the three leaked scripts. Charsave, Rimport and the third one. They should give you the info for QFG1-3. My scripting language is based largely off the original so you can check the help file out. The specs can be generated from the .sc files--just treat them as pseudocode. |
| Xorcist |
Okay, I've made some progress, but not alot. Something that is completely confusing me is the checksums that are supposedly getting generated. The code is as follows: [pre] (= checkSum1 checkSumKey) (for ((= whichSkill 0)) (< whichSkill (+ NUMSTATS CHECK_DATA)) (+= whichSkill 2)) (= [statsKey (+ whichSkill 1)] (& [statsKey (+ whichSkill 1)] 127)) (+= checkSum1 [statsKey (+ whichSkill 1)]) ) [/pre] Now checkSumKey is a predetermined value, so don't worry about that. But I interpret this code as looping while whichSkill is less than NUMSTATS + CHECK_DATA, each loop incrementing whichSkill by 2. That's pretty staight foward, however the actual code in the loop: [pre] (= [statsKey (+ whichSkill 1)] (& [statsKey (+ whichSkill 1)] 127)) (+= checkSum1 [statsKey (+ whichSkill 1)]) [/pre] isn't quite as clear. It looks to me that the first line is setting the whichSkill + 1 element of statsKey equal to the logical AND of that exact same element and 127. But 127 is 1111111 in binary... so ANDing that with any other number will yield the same number! (i.e. 100 & 127 = 100). So why is this line being run? It seems to be doing nothing (unless my interpretation is wrong). At least the next line makes sense. I'm just continually adding the value stored in the whichSkill + 1 element of statsKey to the checksum, which will end up giving me something, but I haven't gotten as far as using actualy values to determine a checksum yet. Anyone have any ideas? |
| Xorcist |
Um... okay, I just noticed statsKey is defined as such: statsKey = $53 so.... what does that mean? statsKey couldn't be an array, as $53 is nothing more than 83 in decimal. But whenever I've seen brackets elsewhere in the script it represents a string or array, so it's gotta be. Looks like I'm going to need some serious help deciphering this stuff. If anyone is up to the task, just drop me a line I could use all the help I can get. |
| Mokalus_of_Borg |
The only reason to perform a logical AND between a byte and 127 is to drop the high bit (128). 228 & 127 = 100 That's probably what's going on there. Mokalus of Borg PS - I'm well outside the understanding of the rest, though. PPS - Well, uh, seeya. |
| Xorcist | Thanks for the info, I never considered they might be error checking. Now it makes a bit more sense, because that AND insures they only get the first seven bits of the byte. Cool. Now I just have to work on the progressive XORs they're using, so I can reverse the process. |