Reply to Re: Recondite Twenty-Eight: The Sixth Day
If you don't have an account, just leave the password field blank.
@toof:
If max number of global variables is ~ 200, if 4 people participate, each can get 50 globals. So, (available globals) / (number of participants).
I think you might be confusing globals with locals here. I think I have a a somewhat better grasp of how variables are managed by DinkC. As I understand it...
{
Globals always exist and always consume some of the limit of ~200. Locals come and go, according to how many scripts are active at a time. This includes what the main section of scripts for all armed "weapons" and magical spells declares and (potentially) a script for each item on the current screen, plus any that have simply been generated by a call to a currently active spawn() function that was started by other scripts, and those called by the external() function, etc.
}
So perhaps you could say, if then maximum number of variables is ~200, and 4 people participated, each participant would get 20 globals and 30 locals.
Each global variable and each script name, must begin with our nicks, so if both of us make a script called bookshelf.c, your's would be slipDink_bookshelf.c, and mine toof_bookshelf.c.
Okay. But keeping filenames under 8 character limits would be better. That would mean we could use slipbksf.c and toofbksf.c so that external and spawn still work.
Again, same or similar for global vars, since someone will have to stitch it all together at the end. It would be a nice idea that every participant makes a list of his vars, and the initial values, so that the grand-master Stitcher Overseer can just copy them into main.c (scripts into story as well, but those would just be zipped).
Actually, each participant could make their own main.c that contained only what they needed, such as slipmain.c, toofmain.c and each participant would need to update a special section of main.c like what I've shown below.
Also, entry and exit points should be predefined for each section. If someone wants to change that, he can consult with the other dmodder if their sections have intersections
I'm not sure what you are proposing here by "entry and exit points for each section.", but I assume you are talking about conventions about how each screen (or block of 4 or 6 or 9 screens or ???) as designed by one participant can be entered from the screens developed by another participant. That sounds like a good idea. We would need to diagram it carefully or come up with general rules such as ... "All external southern and western edges must permit Dink's entrance without obstruction."
(God, my english vocabulary sucks!!). I'd say, we start small, with four screens (box shaped), or 6 screens (rectangle), so if someone quits, we can easily rearrange them together (copy pasting screens with scripts).
Actually, depending on how people use screens, moving them about could turn out to be a little troublesome. It is not uncommon to refer to the &player_map reserved variable and to assign it to certain values that represent particular screens.
As for importing graphics, I've no idea, I have never done that.
Oh. Well perhaps the rules for that should be that you can do it as long as you do not replace the standard graphics, unless you do so with the consent of all other participants. Not sure what I mean when I refer to replacing the standard graphics? Consider this example: Over the years some people have developed new "status screens" and (generally) those would be implemented by replacing the existing graphics used for that purpose. But if you were to add a new monster, or one from the development section of the DN, then the only rules would be that you could not re-use other graphics sprite sequence that is part of the standard graphics. Still I might use a sequence that another might want, so we would have to work out something with numeric ranges assigned to each participant, or (in your case) if you do not plan any new graphics, then you could just give your sequence range to another participant.
If max number of global variables is ~ 200, if 4 people participate, each can get 50 globals. So, (available globals) / (number of participants).
I think you might be confusing globals with locals here. I think I have a a somewhat better grasp of how variables are managed by DinkC. As I understand it...
{
Globals always exist and always consume some of the limit of ~200. Locals come and go, according to how many scripts are active at a time. This includes what the main section of scripts for all armed "weapons" and magical spells declares and (potentially) a script for each item on the current screen, plus any that have simply been generated by a call to a currently active spawn() function that was started by other scripts, and those called by the external() function, etc.
}
So perhaps you could say, if then maximum number of variables is ~200, and 4 people participated, each participant would get 20 globals and 30 locals.
Each global variable and each script name, must begin with our nicks, so if both of us make a script called bookshelf.c, your's would be slipDink_bookshelf.c, and mine toof_bookshelf.c.
Okay. But keeping filenames under 8 character limits would be better. That would mean we could use slipbksf.c and toofbksf.c so that external and spawn still work.
Again, same or similar for global vars, since someone will have to stitch it all together at the end. It would be a nice idea that every participant makes a list of his vars, and the initial values, so that the grand-master Stitcher Overseer can just copy them into main.c (scripts into story as well, but those would just be zipped).
Actually, each participant could make their own main.c that contained only what they needed, such as slipmain.c, toofmain.c and each participant would need to update a special section of main.c like what I've shown below.
make_global_int("&dinklogo", 0);
// Add your own globals here. Remember, you only get about 200 of them
// total, so be sure you don't go overboard.
make_global_int("&story", 0);
external("skrnmain", "main");
external("slipmain", "main");
external("toofmain", "main");
Also, entry and exit points should be predefined for each section. If someone wants to change that, he can consult with the other dmodder if their sections have intersections
I'm not sure what you are proposing here by "entry and exit points for each section.", but I assume you are talking about conventions about how each screen (or block of 4 or 6 or 9 screens or ???) as designed by one participant can be entered from the screens developed by another participant. That sounds like a good idea. We would need to diagram it carefully or come up with general rules such as ... "All external southern and western edges must permit Dink's entrance without obstruction."
(God, my english vocabulary sucks!!). I'd say, we start small, with four screens (box shaped), or 6 screens (rectangle), so if someone quits, we can easily rearrange them together (copy pasting screens with scripts).
Actually, depending on how people use screens, moving them about could turn out to be a little troublesome. It is not uncommon to refer to the &player_map reserved variable and to assign it to certain values that represent particular screens.
As for importing graphics, I've no idea, I have never done that.
Oh. Well perhaps the rules for that should be that you can do it as long as you do not replace the standard graphics, unless you do so with the consent of all other participants. Not sure what I mean when I refer to replacing the standard graphics? Consider this example: Over the years some people have developed new "status screens" and (generally) those would be implemented by replacing the existing graphics used for that purpose. But if you were to add a new monster, or one from the development section of the DN, then the only rules would be that you could not re-use other graphics sprite sequence that is part of the standard graphics. Still I might use a sequence that another might want, so we would have to work out something with numeric ranges assigned to each participant, or (in your case) if you do not plan any new graphics, then you could just give your sequence range to another participant.
