Keyring in BG

[marzo]

After the recent round of questions about Usecode by Alun Bestor (as well as Mark Aherne's tutorials, which made me realize Usecode is not as hard as it seems), I decided to toy around with implementing a keyring in BG.

The keyring is almost complete; its Usecode portion is complete at least. What is missing are the intrinsics UI_is_on_keyring (0xc2) and UI_add_to_keyring (0xc3) and saving/loading the keyring data with the savegame. I think that it easier to allow BG to use the functions from SI than to try to code them in Usecode (if it is *at all* possible...), so I am politely requesting the developers to add support for these things

I also found a bug in the latest snapshot regarding the textmsg.txt file which is generated by Exult Studio; I have reported it in the bug tracker.

After these issues are taken care of, I will start creating a quest to obtain the keyring in the game.

Later,

[Beryllium]

The other toy that would be handy would be the reagent ring from Silver Seed, although, unlike the keyring, havin this in BG would change the gameplay so wouldn't be for purists.

[Dominus]

he he, I always wanted to add the ring at the end of the SF Island quest. You also need a shape for the ring, btw

Purists shouldn't even touch Exult. Neither a keyring or a ring of reagents would please purists

[Alun Bestor]

Actually I was thinking about ways a keyring could be implemented straight in usecode, and it could be doable using static variables. I haven't tested this out, though.

You'd have a single function, "KeyRing" which matches the keyring shape. This function has a static "keys" array variable which stores every key on the ring as an entry in an array.
When you use a key on the ring, it calls KeyRing with event level 2 and passes it the itemref of the key. KeyRing then checks if the key's quality is in its array of keyvalues and if not, adds it - and deletes the key regardless.

When you doubleclick the keyring, then KeyRing will get called with event level 1. It can then prompt you to doubleclick on the door, and check if the door's key ID is in the keyring's values array. If so, then open (or close) sesame.

[Alun Bestor]

One thing to bear in mind: The original use-key-on-door/chest functions in Black Gate were responsible for setting certain global flags whenever plot-critical doors/chests were opened (e.g. Christopher's chest, to flag that you've found the stuff inside as part of the investigation).

You'll need to either call these functions directly so that the flags get set properly, or else replicate the flag-setting in your own keyring code. I reimplemented and cleaned up the key-related functions in the Interaction patch but never used them, you can find them in items/keys.uc.

[marzo]

To Dominus: For now, I am using shape 1100 and the SI keyring. If you or other Exult devs think that there would arise any problems due to the distribution of a copyrighted graphic, I can easily make my own graphic.

To Alun: I tought about using statics, but there is a problem: I don't think that the statics would be saved when the game is saved. Also, I took a sneak peek at SI's keyring code and decided to copy a "hack" they use for it: the way that the keyring works is that when you use it on a door/chest, it uses UI_execute_usecode_array to call the key usecode with the target door/chest as "key" (if the key has been added to the keyring). Thus, whatever usecode is executed by using the key directly is executed by using the keyring.

To the devs: After toying with the Exult code, I was able to get the keyring working and being saved in BG with very little changes to the code. I want to know how to make a patch for Exult so I can submit it.

[wjp]

> I don't think that the statics would be saved when the game is saved.

I'm not entirely sure if they're currently saved (They're an Exult addition to usecode), but they definitely should be. What would be the point of them if they weren't saved?



> I want to know how to make a patch for Exult so I can submit it.

Use the 'diff' tool for this. (In 'unified' mode, which is the '-u' parameter.)

[wjp]

Just checked: statics are indeed saved.

[Ethan]

Not to be a party pooper, but isn't the keyring function already implemented in Exult for BG, hotkeyed to 'K'?

[Dominus]

Ethan: no, it isn't. The k hotkey behaves as if you had a keyring but you still have the individual keys somewhere in your backpack (or on your mules).

[marzo]

Patch has been submitted.

One thing that I found while working on the keyring is a small bug in the usecode for the SI keyring; I may submit a fix for it. The bug: while you can't lock a chest when the key inside it, you *can* lock it if the *keyring* has the key and is inside the chest.

[marzo]

I reimplemented and cleaned up the key-related functions in the Interaction patch but never used them, you can find them in items/keys.uc.

I missed this part the first time I read it. I also reimplemented the function for Keys, and did not see you had done that; I did use some of what you wrote as basis (such as constants.uc and shapes.uc), however. Maybe we could work together to create an unified patch?

[Alun Bestor]

Hi Marzo,
Send me an email about this (click on my name) - I like the idea of a keyring and a quest to retrieve it, but it might be best to keep patches separate for now. Haven't really worked it out yet.

[drcode]

Should be easy for us to add the SI intrinsics to BG. One problem with adding new shapes, though: The usecode # for, say, shape 1025 (0x401) would be the same as that for NPC #1 (Iolo). We're going to have to reserve a block of Usecode #'s for the shapes above 1023. I have some ideas for better UCC support of this, which I'll write a little later in the "Usecode questions" thread.

[TMNM Dragon]

DrCode: If you are going to add the SI intrinsics to BG, then can you add the BG intrinsics to SI (such as fire_cannon).

[SB-X]

What about making an "Exult" gametype, with everything possible from BG and SI, and backwards compatible with each of those games?

[marzo]

Just checked: statics are indeed saved.

Something is not working right with them even so. I have tested a static-only keyring. The keyring works perfectly; it saves the keys in the keyring and loads them. But on some occasions, it saves the keys across saves; I mean, I can add a key to it in a savegame and it will remember having the key on another savegame. I am trying to find out exactly what it is happening, but it is not easy.

[Colourless]

Probably doesn't delete the file when gamedat is cleared

[marzo]

Probably doesn't delete the file when gamedat is cleared

No, from my tests gamedat is being cleared fine. What is happening is that, when the save being loaded has no static vars, Exult is not clearing them from *memory*. I confirmed this by creating three separate saves: save #1 had no static vars saved, save #2 and save #3 both had and the var had different values. On executing Exult, loading save #1 first would always mean no static vars set even if #2 or #3 were loaded before closing Exult last - this means that gamedat is being properly cleaned. However, if I load either save #2 or #3 and then load save #1, the latter would inherit the static var from #2 or #3, depending on which one was loaded last. Save #2 and save #3 would always load correclty.

[marzo]

Should be easy for us to add the SI intrinsics to BG.

Given my limited experience with c++, the fact that I was able to add the two keyring intrinsics by myself without any trouble shows that it is easy indeed

One problem with adding new shapes, though: The usecode # for, say, shape 1025 (0x401) would be the same as that for NPC #1 (Iolo).

Hmm, I had not thought of that. I will switch the keyring to shape 1536 (0x400 + 0x200) or something to avoid this trouble (although I don't think neither BG nor SI have 512 NPC's...).

[Dominus]

Hmm, I had not thought of that. I will switch the keyring to shape 1536 (0x400 + 0x200) or something to avoid this trouble (although I don't think neither BG nor SI have 512 NPC's...).

I think a permanent fix from Jeff would be more desireable.

I really need to add this to the Wikki, I think but if you don't know about it already a helpful hint for adding shapes and releasing a patch:
normally when adding shapes the whole changed shapes.vga is saved to the patch dir. This is fine for testing but when you want to release the patch it is a bit problematic since you are distributing nearly all the graphics from the original game. With ipack (in the tools) you can create a shapes.vga that leaves the first 1024 shapes empty and begins with the shape number you specify in the ipack script.
For example if you want to add your keyring shape as shape 1025 your script looks like this:

archive shapes.vga
1024/1: keyring

Since shpaes.vga begins with shape #0, #1024 is shape number 1025. It requires your keyring shape with the name keyring00.png to work. More (and better worded) details in the ipack documentation http://exult.info/ipack.txt. With this newly created shapes.vga in your patch dir, Exult will still use your shapes.vga in static but will also use the shapes.vga in the patch dir. If you change an existing shape, the patch dir shapes.vga will override the static dir one.
What it not (yet?) does is give the option to change just a frame. If you want to override frame #5 of a shape, you need to override the whole SHAPE...

[marzo]

To Dominus (and to others interested): if you check the readme file of my "Female Redhead Avatar Mov" (available from http://www.wiredentertainment.net/exult/index.php) you will see that I already know about IPack.

The mod is actually a showcase for a general purpose batch file I wrote to facilitates distributing shapes, and it allows the overwritting of even a single frame by using IPack. It is also designed to avoid overwritting other graphic mods as much as possible, even if they use the same shape num but modify different frames. About the only thing that it does not do (which I now realize) is preserve brand new frames from a given shape if a latter mod makes changes to the same shape.

Hmm... Maybe there could be a special #allframes keyword (or something similar) which extracts all frames for a given shape (when using -x) and adds all matching files to the vga file when using -c or -u?

[Dominus]

way cool!

[drcode]

My thoughts about usecode for shapes >= 1024 is that there should be a way to indicate that you're writing a function for a shape, like:

function keyring shape(0x401) ()
...

That way, we could automatically assign a usecode # that Exult will know how to interpret. For example, the above might end up as function #0x10401.

We should probably do something similar for NPC's, and maybe spells:

function Iolo npc(1) () {...

Then, as far as having to deal with function #'s, I think that would just leave eggs.

[Alun Bestor]

That sounds like a great solution, DrCode. But yes, eggs would be harder to find an elegant solution for, since not only do they call egg-only functions but some of them call NPC functions - e.g. the starting egg for the first scene in BG calls Iolo. Ahh, those wacky U7 programmers and their mile long all-in-one functions.


Also, while I haven't checked out Marzo's work with the redhead avatar, I have found that a pretty painless way to create a new-stuff-only SHAPES.VGA file for patches is to still do it in ES: but instead of adding new shapes and frames to SHAPES.VGA, you create a new .VGA file, add the stuff you want, then rename it to SHAPES.VGA once you're done. Beats screwing around with ipack any day for me


That static variables bug was very well-spotted, Marzo. Good detective work I'd noticed similar symptoms with statics (e.g. a static flag starting off set even though I'd restored to an earlier point) but never tracked them down to that cause.

[Dominus]

Alun, true, the ES way is more graphical

But otoh ipack is very useful for a CVS environment. Instead of having to upload a "big" shapes.vga binary everytime you change something, you can just change the script and add the shape/frame for it.

[wjp]

> What is happening is that, when the save being loaded has no static vars,
> Exult is not clearing them from *memory*.

Should be fixed now. Thanks for the report.

[Alun Bestor]

DrCode, something to consider if you change how , is the ability to call variable functions. i.e., calling an item's function when you don't know the exact type of the item.

Currently this is doable by a bit of a hack - you can determine the shape/NPC number of an itemref by using UI_get_item_shape() or UI_get_npc_number(), then call the corresponding function by using script { call ; }

However, this (crappy) solution wouldn't work if function definitions are changed, since the function addresses would no longer correspond to the shape/npc numbers.

I think the ideal way to implement this (if I'm not missing the point completely and there already is an existing solution) is to put in another pseudo-method: item.call().

[Alun Bestor]

Er, "...if you change how function numbers are declared".

[marzo]

The new compiler looks good. I have one more request for it though: support for declaring empty static arrays... Right now, one can declare a normal array (say, var array = [], but the compiler does not accept a static array (static var array = []. The latter is the one required for the keyring, so...

BTW, static vars are working perfectly now. Great job!