Reply to Re: Beta Application: dPlay Map Changer
If you don't have an account, just leave the password field blank.
: : Looks good so far. But you're going to have to tell us how to control it so we can do some more involved tests!
: Ok
I didn't want to get into too many details, in fear someone would use it in its current form. Future versions will have version checks and the like.
: First, its run using the playavi command... so like: playavi("command parameter1 parameter2"); and so on.
: There are two commands: "check" and "map".
: Check: Requires 2 parameters. The 1st parameter is the save game number, and the 2nd is the name of the variable it is going to look up. The variable should be global. What this does is looks for the save game that you specify, extracts the value of the variable you specified, and then creates playavi.c, setting the variable to the value. Look in Start.c to see how this can be used to verify dPlay has been installed.
: Map: This has one parameter, which is the location of the map.dat you want to use, which will overwrite the current one. Pretty simple, actually.
: Examples:
: playavi("check 11 dinklogo");
: playavi("map map.s");
: There will be a full debug mode of sorts eventually, where it outputs a text file describing what problems it had. This was originally planned, but it seemed to be causing some problems.
: Oh, and running playavi seems to kill the current script, or stop it.
Okay, some thoughts:
Cool! It's finally reached beta! (I know about this for a while BTW)
Version checks, good.
What do you think about having check return the value +1? It seems better to me somehow, but I guess it's just a style thing.
I found something to look out for. When specifying a source for the new map you can put "..dinkmap.dat" and it works, which means you can specify files outside the d-mods folder. (harmless in this case but be careful).
Debug file, good.
It just stops the script (doesn't kill it) but I've already found a couple workarounds:
use script_attach(0) so it dies when Dink leaves the screen (or right away if you redraw, as you likely would after changng maps) or use set_callback_random to call a function that kills the script.
Lastly not to be a party pooper, but if the maps basically share a dink.dat doesn't that mean they not only have to be the same size but have the rooms created in the same order?
: Ok
I didn't want to get into too many details, in fear someone would use it in its current form. Future versions will have version checks and the like.: First, its run using the playavi command... so like: playavi("command parameter1 parameter2"); and so on.
: There are two commands: "check" and "map".
: Check: Requires 2 parameters. The 1st parameter is the save game number, and the 2nd is the name of the variable it is going to look up. The variable should be global. What this does is looks for the save game that you specify, extracts the value of the variable you specified, and then creates playavi.c, setting the variable to the value. Look in Start.c to see how this can be used to verify dPlay has been installed.
: Map: This has one parameter, which is the location of the map.dat you want to use, which will overwrite the current one. Pretty simple, actually.
: Examples:
: playavi("check 11 dinklogo");
: playavi("map map.s");
: There will be a full debug mode of sorts eventually, where it outputs a text file describing what problems it had. This was originally planned, but it seemed to be causing some problems.
: Oh, and running playavi seems to kill the current script, or stop it.
Okay, some thoughts:
Cool! It's finally reached beta! (I know about this for a while BTW)
Version checks, good.
What do you think about having check return the value +1? It seems better to me somehow, but I guess it's just a style thing.
I found something to look out for. When specifying a source for the new map you can put "..dinkmap.dat" and it works, which means you can specify files outside the d-mods folder. (harmless in this case but be careful).
Debug file, good.
It just stops the script (doesn't kill it) but I've already found a couple workarounds:
use script_attach(0) so it dies when Dink leaves the screen (or right away if you redraw, as you likely would after changng maps) or use set_callback_random to call a function that kills the script.
Lastly not to be a party pooper, but if the maps basically share a dink.dat doesn't that mean they not only have to be the same size but have the rooms created in the same order?
