Beta Application: dPlay Map Changer
I finally got around to making dPlay, or Dink++ as it used to be called. After a series of misadventures with C++ (which must be the worst programming of all time), I learned there was a Perl-> exe convertor. And I'm quite skilled in Perl, because Perl rocks.
Anyway, essentially dPlay allows you to change the map from within DinkC after installing it, without the need to start the D-Mod any differently, run a special application or anything. More functionality will be added in the future.
The main disadvantage is the map has to have the same exact layout as whatever map is going to replace it... it has to do with Seth doing one single thing in Dink efficiently (reading Dink.dat once when the game is loaded).
So... I need people to test it, to see if it works.
http://www2.gvsu.edu/~walmadl/files/dplaymod.zip
http://www2.gvsu.edu/~walmadl/files/dplayexe.exe
Try installing the mod first, and see if it works. It should come up with an error message, and an URL that doesn't work. Then install dplay.exe, and the mod should work fine.
There isn't much to do... Talk to the Duck of Time and Seasons to change between the Winter and Summer maps.
Soo... let me know if it works, or if it doesn't.
Anyway, essentially dPlay allows you to change the map from within DinkC after installing it, without the need to start the D-Mod any differently, run a special application or anything. More functionality will be added in the future.
The main disadvantage is the map has to have the same exact layout as whatever map is going to replace it... it has to do with Seth doing one single thing in Dink efficiently (reading Dink.dat once when the game is loaded).
So... I need people to test it, to see if it works.
http://www2.gvsu.edu/~walmadl/files/dplaymod.zip
http://www2.gvsu.edu/~walmadl/files/dplayexe.exe
Try installing the mod first, and see if it works. It should come up with an error message, and an URL that doesn't work. Then install dplay.exe, and the mod should work fine.
There isn't much to do... Talk to the Duck of Time and Seasons to change between the Winter and Summer maps.
Soo... let me know if it works, or if it doesn't.
: I finally got around to making dPlay, or Dink++ as it used to be called. After a series of misadventures with C++ (which must be the worst programming of all time), I learned there was a Perl-> exe convertor. And I'm quite skilled in Perl, because Perl rocks.
: Anyway, essentially dPlay allows you to change the map from within DinkC after installing it, without the need to start the D-Mod any differently, run a special application or anything. More functionality will be added in the future.
: The main disadvantage is the map has to have the same exact layout as whatever map is going to replace it... it has to do with Seth doing one single thing in Dink efficiently (reading Dink.dat once when the game is loaded).
: So... I need people to test it, to see if it works.
: http://www2.gvsu.edu/~walmadl/files/dplaymod.zip
: http://www2.gvsu.edu/~walmadl/files/dplayexe.exe
: Try installing the mod first, and see if it works. It should come up with an error message, and an URL that doesn't work. Then install dplay.exe, and the mod should work fine.
: There isn't much to do... Talk to the Duck of Time and Seasons to change between the Winter and Summer maps.
: Soo... let me know if it works, or if it doesn't.
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!
: Anyway, essentially dPlay allows you to change the map from within DinkC after installing it, without the need to start the D-Mod any differently, run a special application or anything. More functionality will be added in the future.
: The main disadvantage is the map has to have the same exact layout as whatever map is going to replace it... it has to do with Seth doing one single thing in Dink efficiently (reading Dink.dat once when the game is loaded).
: So... I need people to test it, to see if it works.
: http://www2.gvsu.edu/~walmadl/files/dplaymod.zip
: http://www2.gvsu.edu/~walmadl/files/dplayexe.exe
: Try installing the mod first, and see if it works. It should come up with an error message, and an URL that doesn't work. Then install dplay.exe, and the mod should work fine.
: There isn't much to do... Talk to the Duck of Time and Seasons to change between the Winter and Summer maps.
: Soo... let me know if it works, or if it doesn't.
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!
: 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.
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.
: : 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?
: 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.
Hrm... I'm not sure what you mean. You mean return the value of the variable plus 1? I'm just not sure what that would do.
: 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).
I can't see any case where this could be a bad thing... if someone wants to mess up their map.dat, its up to them. And because it only copies the file on top of map.dat, it can't delete anything.
: It just stops the script (doesn't kill it)
I was afraid of that... I have a couple other workarounds that might work a tad better.
: 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?
From what I've seen, no. Perhaps with DinkEdit... but with WDE the room number references all seem to go in order, no matter when the room was inserted.
Hrm... I'm not sure what you mean. You mean return the value of the variable plus 1? I'm just not sure what that would do.
: 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).
I can't see any case where this could be a bad thing... if someone wants to mess up their map.dat, its up to them. And because it only copies the file on top of map.dat, it can't delete anything.
: It just stops the script (doesn't kill it)
I was afraid of that... I have a couple other workarounds that might work a tad better.
: 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?
From what I've seen, no. Perhaps with DinkEdit... but with WDE the room number references all seem to go in order, no matter when the room was inserted.
: Hrm... I'm not sure what you mean. You mean return the value of the variable plus 1? I'm just not sure what that would do.
You know how it basically sets &dinklogo back to was it already was? It seems to me it would be a slightly better check to set it to that plus 1.
[b]: : 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).
: I can't see any case where this could be a bad thing... if someone wants to mess up their map.dat, its up to them. And because it only copies the file on top of map.dat, it can't delete anything.[/b]
I meant in furture commands. For example if you made a cammand to dynamically create scripts or soemthing, you'd have to make sure you couldn't create one in another d-mod's folder.
: From what I've seen, no. Perhaps with DinkEdit... but with WDE the room number references all seem to go in order, no matter when the room was inserted.
Ah, yeah, WinDinkedit might well take care of that.
You know how it basically sets &dinklogo back to was it already was? It seems to me it would be a slightly better check to set it to that plus 1.
[b]: : 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).
: I can't see any case where this could be a bad thing... if someone wants to mess up their map.dat, its up to them. And because it only copies the file on top of map.dat, it can't delete anything.[/b]
I meant in furture commands. For example if you made a cammand to dynamically create scripts or soemthing, you'd have to make sure you couldn't create one in another d-mod's folder.
: From what I've seen, no. Perhaps with DinkEdit... but with WDE the room number references all seem to go in order, no matter when the room was inserted.
Ah, yeah, WinDinkedit might well take care of that.
: You know how it basically sets &dinklogo back to was it already was? It seems to me it would be a slightly better check to set it to that plus 1.
Yeah, I get that... but I still don't see how adding one would do anything. I feel stupid
: I meant in furture commands. For example if you made a cammand to dynamically create scripts or soemthing, you'd have to make sure you couldn't create one in another d-mod's folder.
Ah, yeah.
Yeah, I get that... but I still don't see how adding one would do anything. I feel stupid
: I meant in furture commands. For example if you made a cammand to dynamically create scripts or soemthing, you'd have to make sure you couldn't create one in another d-mod's folder.
Ah, yeah.
: : You know how it basically sets &dinklogo back to was it already was? It seems to me it would be a slightly better check to set it to that plus 1.
: Yeah, I get that... but I still don't see how adding one would do anything. I feel stupid
: : I meant in furture commands. For example if you made a cammand to dynamically create scripts or soemthing, you'd have to make sure you couldn't create one in another d-mod's folder.
: Ah, yeah.
Argh... There's going to be a small second map in LT, but the first one wasn't created using WinDinkEdit... Does that mean I'm screwed? (the first is completely filled, the second only 1/4th).
: Yeah, I get that... but I still don't see how adding one would do anything. I feel stupid
: : I meant in furture commands. For example if you made a cammand to dynamically create scripts or soemthing, you'd have to make sure you couldn't create one in another d-mod's folder.
: Ah, yeah.
Argh... There's going to be a small second map in LT, but the first one wasn't created using WinDinkEdit... Does that mean I'm screwed? (the first is completely filled, the second only 1/4th).
: Argh... There's going to be a small second map in LT, but the first one wasn't created using WinDinkEdit... Does that mean I'm screwed? (the first is completely filled, the second only 1/4th).
Well, merely the act of opening and saving the map in WDE should re-order the map file... and I'm still not sure if DinkEdit doesn't do that.
Well, merely the act of opening and saving the map in WDE should re-order the map file... and I'm still not sure if DinkEdit doesn't do that.
: : Argh... There's going to be a small second map in LT, but the first one wasn't created using WinDinkEdit... Does that mean I'm screwed? (the first is completely filled, the second only 1/4th).
: Well, merely the act of opening and saving the map in WDE should re-order the map file... and I'm still not sure if DinkEdit doesn't do that.
And does it have to be the same size or not? What are the restrictions and what can be done with it exactly? I'm confused, you and Paul say contradicting things.
: Well, merely the act of opening and saving the map in WDE should re-order the map file... and I'm still not sure if DinkEdit doesn't do that.
And does it have to be the same size or not? What are the restrictions and what can be done with it exactly? I'm confused, you and Paul say contradicting things.
: : : Argh... There's going to be a small second map in LT, but the first one wasn't created using WinDinkEdit... Does that mean I'm screwed? (the first is completely filled, the second only 1/4th).
: : Well, merely the act of opening and saving the map in WDE should re-order the map file... and I'm still not sure if DinkEdit doesn't do that.
: And does it have to be the same size or not? What are the restrictions and what can be done with it exactly? I'm confused, you and Paul say contradicting things.
No, but basically yes. (less confused now? No?)
Okay, Dink.dat is a list of all the map squares and what if any screen (from map.dat) is there.
So if map.dat changes the old dink.dat is going to be pointing at the wrong places in map.dat.
It should (in theory at least) be possible to make a smaller map compatible with the full one though. The easiest way would probably be (I've not tested this mind you) to put the small map at the top of the screen and fill in the extra lines with blank screen (so the top half or so are all screens, real or not) in WinDinkedit. Since WDE recreates map.dat each time and puts all the rooms in order the half map should match the top half off the big map (if also saved in WDE).
DinkEdit on the other hand only adds new rooms to map.dat, leaving the rest in any old order. You could take advantage of this if you don't want to waste space on the second map, here's how: (again, untested)
Start an new map and import the screens from the large map that cover the same squares at the small map. Now open and save the new map and the small one in WinDinkedit (now the begining the dink.dats match) now in DinkEdit import the rest of the screens from the large map to the new one. The begining still matchs the small map so they should be okay. Important: never save this map in WinDinkedit or it won't match anymore.
(less confused now? I don't know if I would be either.
)
: : Well, merely the act of opening and saving the map in WDE should re-order the map file... and I'm still not sure if DinkEdit doesn't do that.
: And does it have to be the same size or not? What are the restrictions and what can be done with it exactly? I'm confused, you and Paul say contradicting things.
No, but basically yes. (less confused now? No?)
Okay, Dink.dat is a list of all the map squares and what if any screen (from map.dat) is there.
So if map.dat changes the old dink.dat is going to be pointing at the wrong places in map.dat.
It should (in theory at least) be possible to make a smaller map compatible with the full one though. The easiest way would probably be (I've not tested this mind you) to put the small map at the top of the screen and fill in the extra lines with blank screen (so the top half or so are all screens, real or not) in WinDinkedit. Since WDE recreates map.dat each time and puts all the rooms in order the half map should match the top half off the big map (if also saved in WDE).
DinkEdit on the other hand only adds new rooms to map.dat, leaving the rest in any old order. You could take advantage of this if you don't want to waste space on the second map, here's how: (again, untested)
Start an new map and import the screens from the large map that cover the same squares at the small map. Now open and save the new map and the small one in WinDinkedit (now the begining the dink.dats match) now in DinkEdit import the rest of the screens from the large map to the new one. The begining still matchs the small map so they should be okay. Important: never save this map in WinDinkedit or it won't match anymore.
(less confused now? I don't know if I would be either.
)
