ScrollingDialog module: Setup module worth it?

[monkey0506]

As stated in the title, this thread is in regards to my ScrollingDialog module. I've been working on a major rewrite which I might actually end up having to scrap because I'm worried it will end up being too slow with most of the module's data being stored in a single String... :

But regardless of whether the version I'm working on is fast enough or not, I have a question for those who might actually use this module. Based on a user request I added a secondary module for setup purposes (ScrollingDialog_Setup) so that the module itself could be updated without having to disturb the existing dialogs.

I'd actually like to provide some means for the user to keep their dialogs in-tact when upgrading the module, but even the way it's currently implemented is messy. In order to get the information from the setup module to the main module I have to use all sorts of functions for retrieving the data, which clutters up the setup module's scripts. And even providing support for nested dialogs requires that the user puts their interactions (at least those requiring nested dialogs) into the main module since the setup module can't call any of the functions defined by the main module.

With the current implementation I'm working on, I would have to implement not just functions to get the values of all this data, but I would also have to implement functions to set each of the data Nevermind that bit. That's just bullocks. The current implementation would actually greatly simplify and clean up the setup module's scripts.

Okay, so the real question here is: Is it worth my trouble to write the setup module again, or should I just scrap it?

I've implemented methods so that dialogs can be dynamically managed (rather, created and updated, there are no methods to actually remove them entirely). But you have to define your dialog interactions in the module script, which would mean if you update the module, you would have to remember to copy your interaction scripts.

[SSH]

Some thoughts:

1. Check out the latest MultiResponse module: I use a hash function to choose one of 100 (configurable to more or less as you desire) Strings to keep data in, which makes it faster... you might want a similar approach.

2. Have you tried setting up #defines to make the setup thing easier?

3. Would it be easier to have 3 modules: one BEFORE the setup and one AFTER the setup?

4. Perhaps its worth asking CJ for a way to upgrade modules better (by some kind of patch mechanism?) in AGS 2.8 since this would be an editor thing and he's doing a complete rewrite anyway...

[monkey0506]

1. Maybe I'm just stupid, but I don't really see how that could help in this case. The way I'm thinking this through the array would have to be the same size as the maximum number of topics, right? Actually I suppose it would help seeing as I'm working on implementing named dialog topics. If this method turns out to be too slow I'll consider the hash function route.

2. How so? I've already set up macros to make sure that the setup module is imported first...but aside from that I don't really see how I could use macros to make it any easier.

3. The problem with this (I assume you mean one before the main module and one after it, not the setup module) is that the main module would then have no means to call the functions from the module after it, i.e., there would be no way to run the interactions. I could, of course, make it so that the on_event function used when the user clicks on the label is implemented in the 3rd module, which could then call both the function in the main module and the 3rd module (the main module function already calls the setup module function). However if the user calls ScrollingDialog.RunInteraction I wouldn't be able to run these 3rd module interactions, which the user may actually depend on running for their dialog to run properly.

4. I'd like some sort of patching mechanism, but realistically I'm not sure how it could be implemented. I don't really know anything about it, but it seems to me like it would be difficult as to keep the code in-tact it would have to read through the functions themselves to make sure that they stay in the same order and don't collide with one another if one of the patched functions is longer than the previous version. But I guess it couldn't really hurt to ask him.

[EDIT:]

The method I was using was in fact too slow. I let it run for several minutes after finally getting everything set up...and...there was no screen update. It didn't crash due to loops because it wasn't running that many loops, it was just iterating through a lot of Strings. Rather, iterating through one String lots of times.

Anyway, I've implemented a hashing method like you suggested, and it seems to be running fast enough now...except I've encountered a few bugs I'll have to work out later. For now my mom needs the computer to do her school work...(she's just started back to college in January to get her Bachelor's degree).

[SSH]

1. Maybe I'm just stupid, but I don't really see how that could help in this case. The way I'm thinking this through the array would have to be the same size as the maximum number of topics, right? Actually I suppose it would help seeing as I'm working on implementing named dialog topics. If this method turns out to be too slow I'll consider the hash function route.

Not necessarily: the number of items in the array depends on your hash function. If your has function is "use the topic number" then you would need to do it as described, but you could make it something like: (topic # + dialog #) % 32, then you would only need 32 items in the array...

3. The problem with this (I assume you mean one before the main module and one after it, not the setup module)

No, I mean have the sandwich the other way around: the setup comes in the middle, rather than the main module in the middle.

4. I'd like some sort of patching mechanism, but realistically I'm not sure how it could be implemented. I don't really know anything about it, but it seems to me like it would be difficult as to keep the code in-tact it would have to read through the functions themselves to make sure that they stay in the same order and don't collide with one another if one of the patched functions is longer than the previous version. But I guess it couldn't really hurt to ask him.

A line-by-line merge is easy: you have to have a copy of the old module as it was imported, the new module to be imported, and the current version that is installed int he game. If a line is in all three, obviously it stays. If it has been changed between old and current and new doesn't change it from current, keep the current, and vice versa. If it changes in both, you have a clash and need to flag it... but if the new editor actually keep these files lying around in the filesystem as CJ says, then you can get your source code control system to do this for you!

[monkey0506]

3. The problem with this (I assume you mean one before the main module and one after it, not the setup module)

No, I mean have the sandwich the other way around: the setup comes in the middle, rather than the main module in the middle.

I'm still failing to see exactly how this would all work. The main module calls two of the setup module's functions: one for initializing the dialogs, and one for running the dialog interactions. My tests show that it would be possible to declare the functions in one module while actually defining them in another. This has actually led me to get the three-module route working, but with the main module still in the middle.

I think what you were envisioning is what I'm now thinking of. I've moved most of what was in the setup module, but didn't really involve the user in any way into the main module. And now I've got a different module defined after the main module holding the setup module's initialization and run-interaction functions as well as those of the main module which call the setup module's functions. So I've now moved it back into two modules.

The question now is would it really make it easier on the users to have a third module for the main module's initialization and run-interaction functions so that all that the setup module would actually contain is those functions pertinent to them?

I'm reluctant to using 3 modules...but I can definitely see the benefit behind doing so.

So for now I have two different copies of my testing game. One with two modules, and one with three. Perhaps if I can get some user opinions on this issue I can decide better which to release.