1

Topic: Generic Mod structure

Hi all,

has anybody noticed that in order to correclty apply all changes easily it would be better to state the mod lines in reverse order?
That is, instead of:

#
#---------[ 5. FIND (line 127) ]----------------------------------------------
#
    $cur_closed = $_POST['closed'][$id];
#
#---------[ 6. AFTER, ADD ]---------------------------------------------------
#
    $cur_locked = $_POST['locked'][$id];
#
#---------[ 7. FIND (line 141) ]----------------------------------------------
#
    if ($cur_admmod_only != '1') $cur_admmod_only = '0';
#
#---------[ 8. AFTER, ADD ]---------------------------------------------------
#
    if ($cur_locked != '1') $cur_locked = '0';
#
#---------[ 9. FIND (line 146) ]----------------------------------------------
#
    $db->query('UPDATE '....
#
#---------[ 10. REPLACE WITH ]------------------------------------------------
#
    $db->query('UPDATE '...
#

writing it so:

#
#---------[ 5. FIND (line 146) ]----------------------------------------------
#
    $db->query('UPDATE '....
#
#---------[ 6. REPLACE WITH ]------------------------------------------------
#
    $db->query('UPDATE '...
#
#---------[ 7. FIND (line 141) ]----------------------------------------------
#
    if ($cur_admmod_only != '1') $cur_admmod_only = '0';
#
#---------[ 8. AFTER, ADD ]---------------------------------------------------
#
    if ($cur_locked != '1') $cur_locked = '0';
#
#---------[ 9. FIND (line 127) ]----------------------------------------------
#
    $cur_closed = $_POST['closed'][$id];
#
#---------[ 10. AFTER, ADD ]---------------------------------------------------
#
    $cur_locked = $_POST['locked'][$id];
#

This way you make sure that when people reach line 127 (after editing lines afterwards), the target code will still be there.

Of course, everyone can do as it pleases him/her, but assuming it's all the same for developers, and if and only if nobody oposes, I propose changing the order in future releases.

If there's a reason why it's done like it's done, I'd like to hear it, since I am curious and I've already learnt a lot about PHP browsing through the code of punBB and some of its mods. Learning doesn't hurt... too much wink

Greets,
Marc

2 (edited by Louis 2004-02-13 22:06)

Re: Generic Mod structure

MarcB wrote:

Has anybody [else] noticed that in order to correctly apply all [the] changes easily, it would be better to state the mod lines in reverse order? [That] way you make sure that when people reach the first lines (after editing [the previous lines]), the target code will still be [on line number specified].

Of course, everyone can do as it pleases him/her, but assuming it's all the same for developers, and if and only if nobody opposes, I [would] propose changing the order [of the instructions] in future releases.

If there's a reason why it's done like it's done, I'd like to hear it, since I am curious ...

Hello Marc.

I would say the reason is obvious: No one thought much about it ;)

The most logical way for humans who are used to reading up-to-down is to start from the top and work down though your source code, noting changes as you go. Perhaps a more adventurous developer would use a diff program and then reformat it by hand or with a script. The order is not standardized in any fashion, so it's up to the individual mod developer to decide.

I would, however, agree with your "reverse order" idea. Another idea would be to adjust the line numbers to where they would be when the person installing it gets to the line, so for example, with 10 new lines inserted above, the next change should have its line number offset by 10 lines. Of course, for each, it would simply place extra burden on a mod developer to change their script.

Perhaps it would be easier to tell people to start from the bottom and work their way up? ;)

3 (edited by Frank H 2004-02-13 22:11)

Re: Generic Mod structure

Well in that second example of yours, the line is most probably not 146 (if it was that for the first example and they are alike), but something lower. What, depends on the number of lines one have to add in the other places.

When writing a readme, the lines one put in the files will be the lines the code is at in the finished mod, then you don't need to backtrack how many lines you have added when doing the mod etc, to figure out the correct line to write down in the 'reversed' way ... writing a readme is pretty hard even now, and it takes quite a long time to do aswell, when the lines start to increase, and extra work for the modders, is probably not welcomed wink

Actually I don't see any advantage in adding mods backwards, what's so bad having it like it is now?


Edit: And also, when adding the mod, if you follow the readme, the line numbers should aswell be correct, as you have pasted the stuff earlier, and pushed down the rows abit ... if it starts to differ alot, one might have forgotten a step in the readme wink

4

Re: Generic Mod structure

Frank H wrote:

... writing a readme is pretty hard even now, and it takes quite a long time to do aswell, when the lines start to increase, and extra work for the modders, is probably not welcomed ;)

Considers re-inventing the wheel with my newly installed Visual Studio .NET 2003.

Anyone feel like some kind of "PunBB Mod Builder" with an automatic packager and integration with the PunBB Resource website? Since my main programming language is C# with some PHP, I can't quite conceive of this as cross-platform or native code, but even as a Microsoft .NET app, it should be useful ...

5

Re: Generic Mod structure

@Frank: Hmmm what you say makes lots of sense. I just didn't think it through this way, maybe cause when I set up the changes, I leave the "old" code commented out, and this way I can reverse a mod (cough, cough) easily, or at least I can reverse it wink

@Louis: sounds like a CVS repository to me... wink

Marc

Re: Generic Mod structure

Yes, the mod readme thingy definately needs to be looked over. Simply releasing the output of e.g. hdiff is one possible solution. It sure as hell makes it a lot easier for mod developers. One might even consider including both the raw output of GNU diff together with a formatted version from hdiff (or any other suitable diff "beautifier").

"Programming is like sex: one mistake and you have to support it for the rest of your life."