SmaugFUSS + Area Editor
Posted by Twistit
on Thu 02 Mar 2006 12:25 PM
— 19 posts, 86,653 views.
Hey Nick,
Was just wondering if we could expect an update for the area editor to work with SmaugFUSS anytime soon?
Would be great if we could start making our areas with your editor..
I am considering the future of the Area Editor, an announcement should be made within the next couple of months.
You know, on first glance I was all set to cheer over that.. then after a moment's pause to rethink it, that's an amazingly well worded statement of absolute neutrality. With no indication whatsoever what sort of consideration is being deliberated... I certainly am eager to learn what changes you've planned for the next release of Area Editor, but I am also very sincerely hoping that you're talking about another release rather than a ceasation of support for a wonderful program that has but a few minor failings. :(
OK, let me put it a bit more strongly ...
In view of the very slow trickle of actual sales of the Area Editor I am considering releasing it as Open Source (or some similar concept) so that you would be free to modify it to meet your own needs.
That wouldn't be nearly as bad as what I was afraid you'd meant. In fact, if it became open source, a version could be made that would accomidate the new reset system that SmaugFUSS is now using and we could possibly find a way to shift some of the flag controls to allow more than 32 possible settings.. other than those two relatively minor issues, I think it's pretty damn nice the way it is.
Maybe opening up an upload section and opening up for a patch or whatever its called. When you have an add-on to a program to add functionality to it (memory went blank on that) so that people could upload a translator or something so that Area Editor could read SmaugFUSS area files and then maybe save them to a temp file to work on (giving an option to delete the file or keep it as a back-up) and then save it back in standard Smaug format. Anyways, just an idea :)
Kudos to you nick if you open it up, i know i would make mods for it to support my area file format and have it for download along side the codebase.
I know doing this wont pay the bills for you, but the warm and fuzzies will hopefully compensate.
I am looking at the new SmaugFUSS resets right now, looks complicated, but I think I can do something with it. :)
If it will help at all I can grab some doc information I was working on for AFKMud and get something together for the FUSS resets. They are the same commands, just presented in a different location.
Oh Yay! Nick, if you hadn't decided to make Area Editor freeware I'd have still been thrilled with a new version that offered the new reset system support, even if I'd had to 'renew' my registration, but this is almost too much to ask for, please let us know if there is anything we can do to help you with this knowing that Samson and myself and others will be more than happy to help you however we can. :)
I can only speak for myself, normally, but I just read Samson's post offer to help out already, so I feel safe in 'volunteering' him too this way... and I can't imagine that there are others out that who want to see support for SmaugFUSS's new reset system added that wouldn't be willing to help if they can...
Quote:
They are the same commands, just presented in a different location.
Let me see if I understand this properly.
- The new resets system replaces the #RESETS section.
- As part of the #ROOMS section, resets belong to rooms introduced with a leading "R" character.
- Apart from the "R" the rest of the reset format is much the same as before.
- In cases where the room number is mentioned, like this:
R M 0 21037 8 21005
The room number in this case is 21005, however when parsing it you ignore the room number, because it is part of the room 21005 resets section. Conceivably a warning might be issued if it was a different room number?
- The resets are added to a list of resets for the room, rather than a list of resets for the area.
- Under some circumstances, you call renumber_put_resets to renumber the resets (not sure what this is doing exactly, but it seems to be nesting them).
I assume that the renumbering is supposed to associate a reset with its owner (eg, put flask in bag, which is inside chest).
Yes, you seem to have a pretty good grasp of it already. I left the room number thing in for the outside possibility that someone, for whatever reason, might want to have a reset in one room do it's thing in another. I personally can't think of why this would need to be done though. It isn't needed for any kind of compatibility obviously.
Samson being the author of this code in question would be the expert, but overall, yes, that looks about right to me.
Quote:
I left the room number thing in for the outside possibility that someone, for whatever reason, might want to have a reset in one room do it's thing in another.
At present, in the Area Editor, I generate a list of "references" to a room (resets, and program references) by scanning all open areas, looking for resets and referencing programs.
I am amending it to also look at the resets list for the target room. I am reluctant to scan every room in every area (including nested resets), sounds messy and an overkill to me.
Samson, when writing out the area (in fold_area) you seem to be handling nested resets with loops within loops. This seems to be nested 3 deep like this:
for( pReset = room->first_reset; pReset; pReset = pReset->next )
{
switch ( pReset->command ) /* extra arg1 arg2 arg3 */
...
for( tReset = pReset->first_reset; tReset; tReset = tReset->next_reset )
{
switch ( tReset->command )
...
for( gReset = tReset->first_reset; gReset; gReset = gReset->next_reset )
{
Is there some reason this is done this way and not (say) recursively? And why 3 nests? Would you never need 4?
Yes, I admit it's not the most elegant way to have done it, but it does work.
The reason it only nests 3 deep is because it doesn't really need to get deeper.
If you have an M reset, that's the 1st level. Then a G or E would be the second. A G or E can also have P's, which don't need to nest recursively below that because P resets use their first argument as the nesting level.
The M reset is considered a parent, with the G and E being its immediate children. If for some reason, the M reset doesn't activate, the resets which depend on it won't either. In turn, the G and E can have P reset children which will not activate if for some reason the G or E fail.
That's why the loops are the way they are.
O resets are handled in a similar manner.
It's confusing, yes. But so far hasn't caused any problems that I know of. We've been using it live on Alsherok for some time now and all of the old area files converted successfully from the old #RESETS section format. The system has also been in wide release long enough that I'm fairly confident any major issues would have surfaced by now. Early problems were mostly minor and have been corrected.
I am of course open to any suggestions on improving the code itself.
As for room referencing, it sounds to me like it wouldn't be necessary to go through all that on a per-room basis for FUSS areas. The resets are part of the room structure like the 'E' and 'D' sections for extra descriptions and exits. Perhaps it could be done the same way for resets too?
I am working on expressing the saving of resets in fold_area more simply, but compatible with what it currently does. Right now it doesn't work, time to fire up gdb. :)
Well this seems to work. I can't claim the area files are identical afterwards, but that seems to be because the mob progs change their sequence. However the resets seem to match. This is the recursive reset-saver:
void save_reset_level (FILE * fpout, RESET_DATA * start_reset, const int level)
{
int spaces = level * 2;
RESET_DATA * reset;
for( reset = start_reset; reset; )
{
switch ( UPPER (reset->command) ) /* extra arg1 arg2 arg3 */
{
case '*':
break;
default:
fprintf( fpout, "%*.sR %c %d %d %d %d\n", spaces, "",
UPPER( reset->command ),
reset->extra, reset->arg1, reset->arg2, reset->arg3 );
break;
case 'G':
case 'R':
fprintf( fpout, "%*.sR %c %d %d %d\n", spaces, "",
UPPER( reset->command ), reset->extra, reset->arg1, reset->arg2 );
break;
} /* end of switch on command */
/* recurse to save nested resets */
save_reset_level (fpout, reset->first_reset, level + 1);
/* where we go next depends on if this is a top-level reset or not - for some reason */
if (level == 0)
reset = reset->next;
else
reset = reset->next_reset;
} /* end of looping through resets */
} /* end of save_reset_level */
And you replace the reset saving stuff with this line:
save_reset_level (fpout, room->first_reset, 0);
Basically that kicks off saving the first level of resets, and the function above saves the subsequent levels.
Very nice. Very nice indeed. I'll have to play with that once I get to work.
That does look pretty slick, Nick. Nicely done. :)