Update 1: Getting back into it

I’ve been making some comments on the UDIC Facebook page about some of my work attempting to polish a few of the triggers from early in the game.  My initial foray has left a little stumbling as a I try and interconvert a word of bytes (2 bytes or 16 bits) from decimal to binary and back and sometimes into hex.  The ordering can get a little fuzzy as the byte order for the parameters in the files are first byte corresponds to the values of 0 to 255 and the second bytes results in the larger decimal values.  Most converters on the web, however, use the reverse.  Additionally most trigger parameters aren’t housed as full bytes.  Parameters are often subdivided with strings of bits providing the value used by the trigger.  Sometimes individual bits are actually flags.

To show this more succinctly, here is one of the trigger commands (Reveal Item) displayed as hexcode:

• 0x0003 corresponds to a list of options:  “No FadeIn”, “Slow FadeIn”, and “Fast FadeIn”
• 0x000c corresponds to a list of options:  “No Scale Up”, “Slow Scale Up”, and “Fast Scale Up”
  
• 0x00f0 corresponds to a list of options:  “No Special Effects”, “Special Effect 1”, “Special Effect 2”, “Special Effect 3”, “Special Effect 4”, “Special Effect 5”, “Special Effect 6”, “Special Effect 7”, “Special Effect 8”
• 0xc000 corresponds to a list of options: “Stop Reveal If Blocked”, “Ignore Object If Blocked”, and “Wait Until Clear If Blocked”
  

Translating this to something more comprehensible:  The value of 3 means the first bits (the ones on the far right as traditionally presented – 0000 0011) have values of 1 in binary while the other 6 bits of the byte are zero.  As a result, the engine collects the value as determined by only these two bits.  This means that the values possible are 0 to 3.  This is because when only the first bit is true, you get a value of 1; and when only the second bit is true, you get a value of 2.  If both are true, you get an additive result of 3.  It examines these in isolation from the rest of the byte as if they don’t exist for the purposes of determining the fade effect.  Similarly, the value of c is a decimal value of 12, which can only be obtained when the third (corresponding to 4) and fourth (corresponding 8) bits are true (0000 1100).  This means that for the Scale effect, the engine looks at the third and fourth bits in isolation and it will only get a value between 0 and 3.

As you can see, the 0xc000 means the last two bits (the ones on the far left) define what to do if dealing with a blocked area.  My trigger editor currently treats the parameters as a single 2 byte/16 bit word meaning I have to convert between decimal and binary and make changes to the individual bits, and convert back.  The ordering got a little confusing at first especially because of the hex-bytes being in refuse order within the file compared to the traditional notation.

I’m rapidly getting back into the groove as the above detailed explanation should indicate.

_____

The first little bug I decided to focus on to get my feet wet on is the fire place in the Avatar’s house.  When turned on and off the first time, the fire appears (as a fade in effect) and disappears (as a scale down effect) as it should; however, subsequent turning of the valve doesn’t cause the fire to appear.  Luckily, I noticed quickly during testing that the fire did indeed appear, but was just a tiny scaled down version.  Unfortunately, adding the scale up tag to the reveal command didn’t fix the issue.  On the first turn of the valve, the fire scaled up correctly and scaled down correctly; however subsequent turn off does not cause the fire to scale back up.  Even including ignore if blocked wasn’t enough.

I think remembered having a similar bug before with the Moonglow catacomb teleport.  So after looking at the scripting fixes I performed there, I found out that….I just… changed the scaling to a fading effect only.  Ugh, buggy buggy scripting effects.   I’m left to conclude that the hardcoded scale down does not work correctly with the scale up effect, which works on its own.

____

Another bug I’ve been looking at is the vase in Stonegate that you knock off the shelf with the gust spell.  The issue being that the vase won’t fully fall with the gust spell and appears stuck partially thru the shelf.  No position adjustment of anything had any effect.  So I decided to try and fake it and add a hurl command to help the visual…. and just wow. The gust spell is rather broken.  The trigger for this “puzzle” already includes a command to hurl the vase at the pressure plate.  There is actually some contrivances with the way this “puzzle” is scripted.  Both the vase and shelf aren’t solid.  In fact, the vase and pressure plate are not involved at all.  There is a path cross (also known as a pathegg by Ultima designers) that the gust spell must cause to “Turn On” resulting in a trigger that causes the vase to become solid and get hurled at the pressure plate.  I’m not sure that the gust spell can do anything to other objects except maybe nudge them a little.  In any case, I’ll be making a cleaner looking contrivance with this particular puzzle.

I mean dang, the designers, scripters, and programmers didn’t even have time to put bandaids on properly.  The buggy and issues that just won’t let themselves be fixed really makes you appreciate the frustrations they must have had under a time crunch.

That is all for today.  I’m going back in, wish me luck.