[X] My Assistant

Well, congrats you two.

On the script topic, i'd like to vote against a collection thread. It's a lot of busy work for any one person to do, and that person, as we saw with f4tal, will most likely be the one constantly messaged if any script has issues, or s/o has a problem with any script.

Is there an option to "moderate" a thread, so posts have to be approved? In this case script writers could make a post there, with a short description/list of their own scripts and then update that post with new versions. We'd still have the script thread for general questions and new feedback then with a short thread just for listing.

If it's something like that, I can do it.

But people making scripts should help, telling me by PM/post when and what they updated.

It would be great if you could make a slimmer compendium, starting from the old one to pick up the still useful things and adding new stuff.
For what i updated, you can see in my signature, for the rest we mostly would have to browse the script thread from the date after when the compendium was made to see them, i guess, but if the other script makers would help it would be even better.
Attachments can be easily seen by clicking on the clip at the side of a thread by the way, so maybe it wouldn't be too difficult, even without the help.

That's a very good first step. As far as I understand, you won't be able to do much, so I think that you're seeing things a bit too big for the moment. If you cannot pin, can you lock threads? You see, there are a few things around here that have been... around for too long now. *gets erased* (IMG:[invalid] style_emoticons/default/ph34r.gif)

Yes we can do that.
But... i think i know what threads you are talking about, so if i'm right unfortunately those are there to stay (IMG:[invalid] style_emoticons/default/heh.gif)

So I'm wishing both of you good luck and... to stare your screens 10 times more so that you shall not pass, flamers, spammers and the like.

I'll try i guess (IMG:[invalid] style_emoticons/default/laugh.gif)

Congratulations to the both of you. Now i can blame you two for everything, instead of tenboro (IMG:[invalid] style_emoticons/default/biggrin.gif)

(IMG:[invalid] style_emoticons/default/duck.gif)

Please no (IMG:[invalid] style_emoticons/default/tongue.gif)

There are quite some reloaders, but most have quite some differences, so it would be difficult to merge them.
There are:
- Reloader 1.1.1 (Vanilla)
- Reloader 1.3.3b (Sapo's)
- Reloader 1.3.3b chrome (Sapo's with swapped NoBlinking (put in Tatarime's) by me for making it work on chrome)
- Reloader 1.4_beta (Sapo's, fully refactored, lots of changes)
- Reloader 1.3.5d (Mine, lot of changes to MouseMelee from 1.3.3b chrome)

duh. are really all of them needed? (IMG:[invalid] style_emoticons/default/huh.gif) what about a v1.5c (chrome)/1.5f (firefox)?

i'm genuinely asking since i don't know it too much (IMG:[invalid] style_emoticons/default/heh.gif)

If it's something like that, I can do it.

But people making scripts should help, telling me by PM/post when and what they updated.

of course. i mentioned about coders posting in that thread whenever one release is completed while keeping script thread as a place to speak about anything else. basically a thread for end-users and a thread for coders.

So what kind of dictatorship will you be leading? Will you force everyone to post one cleave per post?

as much as i'd like to, i guess i'll have to be a bit more serious this time (IMG:[invalid] style_emoticons/default/heh.gif)

As far as I understand, you won't be able to do much, so I think that you're seeing things a bit too big for the moment. If you cannot pin, can you lock threads? You see, there are a few things around here that have been... around for too long now. *gets erased* (IMG:[invalid] style_emoticons/default/ph34r.gif)

yes, we can.

As for what should be done now... yes I agree with the compendium being remade entirely, with something light that does contain links to the main scripts in the first post. Let's get rid of all the things that don't work and became entirely useless. I bet that the really useful scripts can be counted on both hands.

we're still discussing. for now, it seems everybody agrees on a slimmer one. further details, WIP

On the script topic, i'd like to vote against a collection thread. It's a lot of busy work for any one person to do, and that person, as we saw with f4tal, will most likely be the one constantly messaged if any script has issues, or s/o has a problem with any script.

i'd also add a link to author's PM page. it won't do wonders, but it'll still lower the amount of work for the caretaker.

Is there an option to "moderate" a thread, so posts have to be approved? In this case script writers could make a post there, with a short description/list of their own scripts and then update that post with new versions. We'd still have the script thread for general questions and new feedback then with a short thread just for listing.

not that i know...

On the script topic, i'd like to vote against a collection thread. It's a lot of busy work for any one person to do, and that person, as we saw with f4tal, will most likely be the one constantly messaged if any script has issues, or s/o has a problem with any script.

It worked with the first compendium by F4tal, trying it again wouldn't be too bad, i hope.

Is there an option to "moderate" a thread, so posts have to be approved? In this case script writers could make a post there, with a short description/list of their own scripts and then update that post with new versions. We'd still have the script thread for general questions and new feedback then with a short thread just for listing.

Posts would have to be moderated after posting, and not before, as far as i know.
The idea of making a thread full of only a script for every post is a good idea, but that would be kind of like the script thread, it wouldn't be something like a compendium divided by sections for stuff, instead it would be all mixed up.

This post has been edited by gianfrix94: Feb 19 2017, 21:34

Okay then I'm doing it.

Now I'm going to eat dinner, then I'll figure out a slim version of the code, and open a new thread for that.
Any help (link to the posts that should be included, new versions, what should be excluded, etc) it's appreciated, either here or via PM


P.S. I'm not worried about the complaints I could receive, I'm not the script maker (IMG:[invalid] style_emoticons/default/laugh.gif)

This post has been edited by End Of All Hope: Feb 19 2017, 21:33

Pinned. And, yeah, I'm looking around here if you need me.

As for the scripts/script thread one think that I was looking into is a github group. I actually [github.com] created one already but has not been using it 'cause was worried about some code there (am not worried anymore though).

With a github organisation contributing to one another's scripts is easier, and there is a pretty good search function in there. On the other hand people need to know git.

Just an idea.

i'm not against github, but however it will be developed i'd prefer for it to be organized in sections - like interface, item shop, shrine, combat, etc etc. like compendium and wiki are, just to be clear.

On the other hand people need to know git.

If you don't care about versioning you can just upload the files from the web interface.

Anyway, we briefly discussed Github organization here.
Pretty much agree it's the best way to proceed.

also, i'm not an expert here, but afaik there are many versions of reloader. is there the chance to merge them into one/two, and linking only that/those?

That's not how open source works (IMG:[invalid] style_emoticons/default/heh.gif)
Also I don't think it's possible to have less than 3 versions:
Vanilla
1.3 + forks
My refactor

The 1.3 forks are literally a couple of commits different.

That's not how open source works (IMG:[invalid] style_emoticons/default/heh.gif)
Also I don't think it's possible to have less than 3 versions:
Vanilla
1.3 + forks
My refactor

The 1.3 forks are literally a couple of commits different.

open source is a good thing. having customizations too. but official releases should be only one or two, imo - then everyone will customize official release as they want. but 3 is still better than 5.

but as i said, i was asking (IMG:[invalid] style_emoticons/default/laugh.gif) i'm not an expert coder, only giving a few hints too. if the interested people agree they are all needed and provide a reason (*), i'm fine.

(*) oh yeah, possibly a brief description both in gith and in the script. people who will have to use it will undoubtly wonder if that's the proper version for them, and what that particular version does. one more line of comment may spare many questions imo.

This post has been edited by Scremaz: Feb 19 2017, 22:07

open source is a good thing. having customizations too. but official releases should be only one or two, imo - then everyone will customize official release as they want. but 3 is still better than 5.

Just list the most used one and write in a very small font size the other alternatives.
Like ubuntu and the other thousand releases with the same DE, it's good to have more choices and it's even better if the user doesn't need to read pages of description to get the recommended version.

Btw, just did a quick upload of how a Compendium repository could look like.
[github.com] https://github.com/Sapo84/Reloader/tree/Compendium
Literally 3 minutes of work.
It would be very easy to organize the scripts in section, add a very brief description and that's it, very easy to browse even from Github.

If you don't care about versioning you can just upload the files from the web interface.

Anyway, we briefly discussed Github organization here.
Pretty much agree it's the best way to proceed.

I concur (always wanted to say that)

What would be the best way to organize this? 1 Script = 1 Repo seems kind of wasteful and honestly overkill for our single file scripts. One big repo for everything seems like an organizational disaster waiting to happen. One big one with submodules might be better but would put more pressure on maintainers iirc.

I never understood anything to github, and I fear that it's the same for all the random people around here.
As long as we have direct links in the first post, I'm fine with it.

Just list the most used one and write in a very small font size the other alternatives.
Like ubuntu and the other thousand releases with the same DE, it's good to have more choices and it's even better if the user doesn't need to read pages of description to get the recommended version.

hmm... it does make a sense.

Btw, just did a quick upload of how a Compendium repository could look like.
[github.com] https://github.com/Sapo84/Reloader/tree/Compendium
Literally 3 minutes of work.
It would be very easy to organize the scripts in section, add a very brief description and that's it, very easy to browse even from Github.

seems nice.
btw, i don't know too much of this so i don't have clear one thing: who has the permission to modify those github folders? only the owner? a ristricted number of users? anyone?

I concur (always wanted to say that)

What would be the best way to organize this? 1 Script = 1 Repo seems kind of wasteful and honestly overkill for our single file scripts. One big repo for everything seems like an organizational disaster waiting to happen. One big one with submodules might be better but would put more pressure on maintainers iirc.

i'd say one folder (one repo?) per purpose. item shop section, forge section, etc etc.

I never understood anything to github, and I fear that it's the same for all the random people around here.
As long as we have direct links in the first post, I'm fine with it.

maybe a hybrid? organized in sections here, plus direct links to github folders?

i mean, something like this:

CODE

script compendium (link to github archive)

-> equip-themed (link to github equip folder)
-> inventory-themed (link to github inventory folder)
...

This post has been edited by Scremaz: Feb 19 2017, 22:32

maybe a hybrid? organized in sections here, plus direct links to github folders?

Do as you want, as long as noobs and nerds can live together in a happy world full of ponies and cleavages. (IMG:[invalid] style_emoticons/default/ph34r.gif)

btw, i don't know too much of this so i don't have clear one thing: who has the permission to modify those github folders? only the owner? a ristricted number of users? anyone?

Any user can send a commit in which he tries to do something, and the master has to accept the change for it to happen, if i don't remember wrong.
Have to brush up on git (IMG:[invalid] style_emoticons/default/heh.gif)
And would need to make a second account, i guess.

What would be the best way to organize this? 1 Script = 1 Repo seems kind of wasteful and honestly overkill for our single file scripts. One big repo for everything seems like an organizational disaster waiting to happen. One big one with submodules might be better but would put more pressure on maintainers iirc.

Aren't the first and last options the same?
To have submodules you still need 1 repo for each script, and there is no central control over the repos containing the scripts.

I would say a main repo with all the scripts only updated via pull-requests.
And if you pull-request a modification of other scripts (meaning not your own) you lose the ability to merge pull-requests.

For the scripter that are not interested in git another user could do the PR, copypasting a file and doing a PR it's 2 minutes work.

This post has been edited by Sapo84: Feb 19 2017, 22:40

What would be the best way to organize this? 1 Script = 1 Repo seems kind of wasteful and honestly overkill for our single file scripts. One big repo for everything seems like an organizational disaster waiting to happen. One big one with submodules might be better but would put more pressure on maintainers iirc.

From personal experience I'd say that we would need to divide the entire body of scripts into two groups:

1. Create a bunch of coding rules (nothing big something like linux kernel coding standards), e.g. "do not pollute the global namespace, use a single object where you expose an API". And separate the scripts that follow these rules into as few repositories as we can, e.g. all mods of a single script try to be implemented in the same repo.

2. All script that do not follow the coding standard can be splattered across the group. And making a script migrate from the "unorganized" version into the "organized" version would be a valid contribution.

who has the permission to modify those github folders? only the owner? a ristricted number of users? anyone?

In a simple repo only the main user can modify, but he can approve pull requests by others.

The advantage of an organization is that all admins of the organization can change all repos (and approve pull requests). If we can put together a list of names (and respective github accounts) I can simply add everyone to that group and we can test it out.

There's also nothing wrong with keeping some scripts in personal repos and others in group (organisation repos). Some people may with to keep full control of what features do come into their scripts. On the other hand, this does not prevent people from forking these same scripts as organization repos and then changing them.

Figuring out how code should grow is not an easy task and never has been. You can't be as defensive as say csh and die because other people supersede you, but you can't either fall into the tragedy that zsh is (zsh is a shell that can't be used anymore in embedded because everyone added so many features that the performance is shit).

And would need to make a second account, i guess.

And this, of course. EH is anonymous, don't use your main github account for this. You can create a git account with a 10 minute email.

This post has been edited by blue penguin: Feb 19 2017, 22:42

Any user can send a commit in which he tries to do something, and the master has to accept the change for it to happen, if i don't remember wrong.
Have to brush up on git (IMG:[invalid] style_emoticons/default/heh.gif)
And would need to make a second account, i guess.

In a simple repo only the main user can modify, but he can approve pull requests by others.

The advantage of an organization is that all admins of the organization can change all repos (and approve pull requests). If we can put together a list of names (and respective github accounts) I can simply add everyone to that group and we can test it out.

There's also nothing wrong with keeping some scripts in personal repos and others in group (organisation repos). Some people may with to keep full control of what features do come into their scripts. On the other hand, this does not prevent people from forking these same scripts as organization repos and then changing them.

Figuring out how code should grow is not an easy task and never has been. You can't be as defensive as say csh and die because other people supersede you, but you can't either fall into the tragedy that zsh is (zsh is a shell that can't be used anymore in embedded because everyone added so many features that the performance is shit).

And this, of course. EH is anonymous, don't use your main github account for this. You can create a git account with a 10 minute email.

well, my concern is that if we'll organize such a thing, we should be sure that there will always be someone working on that. so yep, creating a shared github account may be a good thing. a few users will have the password, a bit of turnover when needed and so on.