Right, so. I know MNIK's already taken notes on the .wop file format, but I've taken some of my own as well (admittedly because I completely forgot about his notes on the format, but that's not the point). The .wop data structure (not including the actual in-editor adjusters) is as follows:
Code: Select all
$0000 - model length byte
$0004 - model name (assuming !None, i.e. 5 characters)
$0009 - texture length byte
$000D - texture name (assuming !None, i.e. 5 characters)
$0012 - XScale
$0016 - YScale
$001A - ZScale
$001E - XAdjust
$0022 - YAdjust
$0026 - ZAdjust
$002A - PitchAdjust
$002E - YawAdjust
$0032 - RollAdjust
$0036 - WAE X Offset
$003A - WAE Y Offset
$003E - WAE Z Offset
-- $0042 to $007A are UNKNOWN VARIABLES 1 to 15 --
$007E - MovementType
-- $0082 to $009E are UNKNOWN VARIABLES 16 to 23 --
$00A2 - DefensePower
$00A6 - UNKNOWN VARIABLE 25
$00AA - Object ID
$00AE - Type
$00B2 - SubType
$00B6 - Active
$00BA - UNKNOWN VARIABLE 26
$00BE - ActivationType
$00C2 - ActivationSpeed
$00C6 - UNKNOWN VARIABLE 27
$00CA - Timer
$00CE - TimerMax1
$00D2 - TimerMax2
$00D6 - UNKNOWN VARIABLE 28
$00DA - UNKNOWN VARIABLE 29
$00DE - WaterReact
-- $00E2 to $00F2 are UNKNOWN VARIABLES 30 to 34 --
$00F6 - Data0
$00FA - Data1
$00FE - Data2
$0102 - Data3
$0106 - Data4
$010A - Data5
$010E - Data6
$0112 - Data7
$0116 - Data8
$011A - Data9
$011E - String 1 length byte
$0122 - String 1 (assuming 4 characters)
$0126 - String 2 length byte
$012A - String 2 (assuming 4 characters)
$012E - UNKNOWN STRING 1 (35) length byte
$0132 - UNKNOWN STRING 1 (assuming 4 characters)
$0136 - UNKNOWN STRING 2 (36) length byte
$013A - UNKNOWN STRING 2 (assuming 4 characters)
$013E - Talkable
-- $0142 to $015A are UNKNOWN VARIABLES 37 to 43 --
$015E - MovementSpeed
-- $0162 to $017A are UNKNOWN VARIABLES 44 to 50 --
$017E - Exclamation
-- $0182 to $019E are UNKNOWN VARIABLES 51 to 58 - $0192 is the FROZEN variable --
$01A2 - ScaleAdjust
-- $01A6 to $01C6 are UNKNOWN VARIABLES 59 to 67 --
$01CA - UNKNOWN STRING 3 (68) length byte
$01CE - UNKNOWN STRING 3 (assuming 4 characters)
$01D2 - UNKNOWN STRING 4 (69) length byte
$01D6 - UNKNOWN STRING 4 (assuming 4 characters)If none of the object strings are in use (ObjectTextData0, ObjectTextData1, 35, 36, 68, and 69), then we subtract 4 from the offsets above. For instance, the regular gate object has no text strings (and indeed, no use for them), so the length byte for string 2 is at $0126 + 6 - 4, or $0124. Remember that this is all in HEX, not decimal - in other words, we count like this: 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, 10.
Still with me? Alright, cool.
So, where am I going with all this? Well, a week ago, I did some .exe digging in both wg.exe and editor3d.exe - Emerald was wondering if an object's YAW could be adjusted with CMD4. As far as we know (and I'm reasonably convinced of this for reasons I'll get into), it can't, but I decided to dig a bit deeper than just playing about with the command to see if things happened in-game.
I ended up finding a rather large string list in the editor .exe - one that turned out to be quite interesting. Here it is, after having been cleaned up and annotated slightly:
Code: Select all
_vcurrentobjectmodelname
_vcurrentobjecttexturename
_vcurrentobjectxscale
_vcurrentobjectyscale
_vcurrentobjectzscale
_vcurrentobjectxadjust
_vcurrentobjectyadjust
_vcurrentobjectzadjust
_vcurrentobjectpitchadjust
_vcurrentobjectyawadjust
_vcurrentobjectrolladjust
_vcurrentobjectx
_vcurrentobjecty
_vcurrentobjectz
_vcurrentobjectoldx UNK 1?
_vcurrentobjectoldy UNK 2?
_vcurrentobjectoldz UNK 3?
_vcurrentobjectdx UNK 4?
_vcurrentobjectdy UNK 5?
_vcurrentobjectdz UNK 6?
_vcurrentobjectpitch UNK 7?
_vcurrentobjectyaw UNK 8?
_vcurrentobjectroll UNK 9?
_vcurrentobjectpitch2 UNK 10?
_vcurrentobjectyaw2 UNK 11?
_vcurrentobjectroll2 UNK 12?
_vcurrentobjectxgoal UNK 13?
_vcurrentobjectygoal UNK 14?
_vcurrentobjectzgoal UNK 15?
_vcurrentobjectmovementtype
_vcurrentobjectmovementtypedata UNK 16
_vcurrentobjectspeed UNK 17?
_vcurrentobjectradius UNK 18?
_vcurrentobjectradiustype UNK 19?
_vcurrentobjectcollisionpower UNK 20?
_vcurrentobjectpushdx UNK 21?
_vcurrentobjectpushdy UNK 22?
_vcurrentobjectattackpower UNK 23?
_vcurrentobjectdefensepower UNK 24 (FORMERLY)
_vcurrentobjectdestructiontype UNK 25?
_vcurrentobjectid
_vcurrentobjecttype
_vcurrentobjectsubtype
_vcurrentobjectactive
_vcurrentobjectlastactive UNK 26?
_vcurrentobjectactivationtype
_vcurrentobjectactivationspeed
_vcurrentobjectstatus UNK 27?
_vcurrentobjecttimer
_vcurrentobjecttimermax1
_vcurrentobjecttimermax2
_vcurrentobjectteleportable UNK 28?
_vcurrentobjectbuttonpush UNK 29?
_vcurrentobjectwaterreact
_vcurrentobjecttelekinesisable UNK 30?
_vcurrentobjectfreezable UNK 31?
_vcurrentobjectreactive UNK 32
_vcurrentobjectchild UNK 33?
_vcurrentobjectparent UNK 34?
_acurrentobjectdata
_acurrentobjectdata
_acurrentobjecttextdata STR 35?
_acurrentobjecttextdata STR 36?
_vcurrentobjecttalkable
_vcurrentobjectcurrentanim UNK 37?
_vcurrentobjectstandardanim UNK 38?
_vcurrentobjecttilex UNK 39
_vcurrentobjecttiley UNK 40
_vcurrentobjecttilex2 UNK 41
_vcurrentobjecttiley2 UNK 42
_vcurrentobjectfutureint UNK 43?
_vcurrentobjectmovementspeed
_vcurrentobjectfutureint10 UNK 44? (NPC X DEST)
_vcurrentobjectfutureint11 UNK 45? (NPC Y DEST)
_vcurrentobjectfutureint12 UNK 46?
_vcurrentobjectfutureint13 UNK 47?
_vcurrentobjectfutureint14 UNK 48?
_vcurrentobjectfutureint15 UNK 49?
_vcurrentobjectfutureint16 UNK 50?
_vcurrentobjectexclamation
_vcurrentobjectshadow UNK 51?
_vcurrentobjectlinked UNK 52?
_vcurrentobjectlinkback UNK 53?
_vcurrentobjectfutureint21 UNK 54?
_vcurrentobjectfrozen UNK 55
_vcurrentobjectfutureint23 UNK 56?
_vcurrentobjectfutureint24 UNK 57?
_vcurrentobjectfutureint25 UNK 58?
_vcurrentobjectscaleadjust
_vcurrentobjectfuturefloat2 UNK 59?
_vcurrentobjectfuturefloat3 UNK 60?
_vcurrentobjectfuturefloat4 UNK 61?
_vcurrentobjectfuturefloat5 UNK 62?
_vcurrentobjectfuturefloat6 UNK 63?
_vcurrentobjectfuturefloat7 UNK 64?
_vcurrentobjectfuturefloat8 UNK 65?
_vcurrentobjectfuturefloat9 UNK 66?
_vcurrentobjectfuturefloat10 UNK 67?
_vcurrentobjectfuturestring1 STR 68?
_vcurrentobjectfuturestring2 STR 69?I've experimented with a few of the unknown values after finding this list. What I've noticed so far:
- The WAE X/Y/Z offsets seem to have something to do with controlling object logic in-game. After manually setting all the values to 0 on a barrel, the barrel was rendered nonsolid in-game - I could pass through it and click on it as if it were an empty tile. However, spellballs were still blocked by the barrel model, and flashing the barrel restored its solidity. Further experimenting resulted in a tile that I couldn't cross over, but spellballs could - this was not affected when the barrel was flashed or destroyed.
OldX/Y/Z seem to be completely deprecated. I believe these are a relic from the pixel-movement era of the game's development, seeing as they seem to work in co-ordinates instead of tiles.
Yes, for some reason, Pitch/Yaw/Roll are repeated a total of 3 times. The first set, used in the Editor, seem to be "offset" values like X/Y/ZAdjust, while the second set seems to be used in the game itself to determine what direction an object's facing, if that makes sense. I don't know what the "Pitch2" values are about, though.
Unknown variable 32 (currentobjectreactive) seems to be the "initialize" variable for an object. Setting this to 0 causes the object's model to spawn at full scale (slightly larger than average for coins, absolutely massive for chompers) at 0, 0, 0 with absolutely no interactivity.
Variables 33 and 34 (currentobjectchild/parent respectively) are both set to -1 (FF FF FF FF) by default. Disappointingly, these seem to be deprecated.
Variables 39 through 42 are an object's X/Y co-ordinates in the .wlv, repeated twice (39/41 for X, 40/42 for Y). I'm not entirely sure why they're repeated, but there you go.
Variables 44 and 45 are listed as "futureint" 10 and 11 in the string list, indicating they were probably placeholder values, though they're actually used for an NPC's movement target. Amusingly, Chompers use the same variables for their targeting system, too.
Variables 52 and 53 (currentobjectlinked/linkback) are... strange, to say the least. They're related to Flash in some way, as the names suggest, but I've yet to really figure out how. Clearing the values on a flashed Chomper in a save file resulted in me re-flashing nothing to the destination square, while the Chomper regained "solidity" and had its facing direction offset. I'm not really sure how to explain this.
