Changes for shipped LUA scripts in local files?

Asked by DjSlash

I want to make some changes that are specific for our hub in the LUA scripts that are shipped with the trunk. But I also don't want to hassle with these changes if the shipped LUA scripts have changed in trunk. Can I override things in local files?

Question information

Language:
English Edit question
Status:
Answered
For:
ADCH++ Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
poy (poy) said :
#1

depends on the type of changes that you want.

best case, you can create your own script and handle events like signalReceive before / after standard scripts. before if the custom script has non-evasive additions of its own, or if it wants to block some events from ever reaching other scripts. after if the custom script would prefer to simply add its data in addition to that of default scripts.
the same applies if the script wants to customize the handling of events simplified by access.lua (events received thanks to access.register_handler).

if however modifying current scripts can't be avoided, it would be better if you kept a patch rather than a completely modified version of the standard script, so that the patch can be applied whenever a new version comes around.

what changes do you need? perhaps we can accomodate current scripts to avoid the custom script altogether. :)

Revision history for this message
DjSlash (djslash) said :
#2

Thanks for the answer, poy. At this point, I don't have much changes, but I'd rather know what the best approach would be if I would want to make big changes that are specific to our hub. I've diffed our current scripts against the latest revision:

http://pastebin.com/QMpTqWGF

Something that I also want to do is changing (or removing) some of the aliases.

Revision history for this message
poy (poy) said :
#3

regarding the changes in your paste:
- the registration limitations make perfect sense; i've applied them in rev 615.
- ucmd_sep happens to be a global value, so it may be easily changeable by loading a new script and running "autil.ucmd_sep=...". however, the user command separator is well-defined in ADC (see <http://adc.sourceforge.net/ADC-EXT.html#_ucmd_user_commands>) so that's not a wise change to be doing just to accomodate old clients.

Revision history for this message
poy (poy) said :
#4

about aliases, please keep in mind they were hastily written so if you can think of reasonable changes, let's do them directly in the repo.

Revision history for this message
DjSlash (djslash) said :
#5

Apparantly I need to dig a bit more through some docs. :)

Rev 615 is looking nice, I'll update to the latest in a couple of days.

What's the best way for adch++ to propose new changes? I'm used with git/github and pull requests, but not so much with bzr/launchpad.

Revision history for this message
poy (poy) said :
#6

the easiest is to run "bzr diff > patch.patch" and send that patch here.

the most complete way of doing a load of changes is to create a branch, register it so it appears on <https://code.launchpad.net/adchpp>, commit changes into it then ask for a merge request. that creates a diff which is aware of the individual commit history, links to bugs etc. it's heavy, but great for large changes.

and my personal favorite, in-between: create a local branch, commit changes then call "bzr send -opatch.patch". that creates a patch aware of the commit history.

Can you help with this problem?

Provide an answer of your own, or ask DjSlash for more information if necessary.

To post a message you must log in.