SVN Repository
-
Woot! Woot! I’m so excited!
Me too, never really worked with SVN repositorys, but it looks like it can make working together really easy, and since I have been quite lazy on the FLHook dev side, this could bring some new life into it
(and raise my personal motivation^^) -
G-forge also supports svn.
But still cool, what you give good for open development
-
Woo! I look forward to see what you guys can do!
-
hmm I’m not able to commit, do I have to join the project first?
I just added m0tahs blowfish to the source, nothing is better than a good diff editor ^^
I’m no real C++ dev but I’m trying to learn it, could you add me please? e-mail is [email protected]
btw: Add useful commit messages, so you know what you changed where
-
@tai:
hmm I’m not able to commit, do I have to join the project first?
I just added m0tahs blowfish to the source, nothing is better than a good diff editor ^^
I’m no real C++ dev but I’m trying to learn it, could you add me please? e-mail is [email protected]
btw: Add useful commit messages, so you know what you changed where
Added
-
Already have sent a PM to M0tah (I must have oversaw this thread ^^), although you aren’t going to introduce new features, you might want to integrated already existing ones.
Here are the PMs:
BasI heared you are going to build a 1.6.5 FLHook version, I guess you will include your Flak88 specific features (-> F88 Hook version). Since it requires reprogramming for converting features to plugins, I want to suggest you ask around a bit because by this way may more features could get added from different servers (DFLS, Berlin etc. pp.)
M0tah
On the subject of FLHook, your idea is good but when I tried doing this in the past the results weren’t what I was hoping for, so I’m kinda wary of trying something like it again. I’m also not sure if the makers of the other FLHook versions are willing to open-source their code (I want to continue releasing Flak’s FLHook with source code). In addition, I’m thinking about implementing plugin functionality into Flak’s FLHook (similar to w0dk4’s plugin version) so people will be able to add more features via plugins.
Bas
So due to your moment plans FLHook 1.6.5 will be just Flak88 + Pluginversion?
We may don’t know if other FLH coders will release their source code to implent it into the new Hook version, but I believe it shall be worth a try. (And also recall: It will take more work/ressources to re-create them as plugins, and I don’t believe that a other Hook version will be released that soon ^^)It is just the point, if some features can be only added to FLHook by adding them directly in the programm (since nobody voluntarys to convert it into plugins), then this chance shall be used instead of not implenting those features.
My 2 Cents. -
Well, almost anything can be done with plugins. The only features that are not really worth implementing via plugins are features that are not really new but extend the stock flhook features, which is of course wanted/needed. (for example the recent blowfish socket encryption)
Also, it would actually very likely be a lot more difficult to port Flak FLHook code over into the plugin version (if its a new feature) than just writing a plugin.
If Flaks FLHook introduces new hooks or sth like that, that can of course be implemented in the plugin version, thats what it is for.
So I dont really get your point. -
I don’t know C++ yet (<- FLHook coder in spe….will learn C++ in my 2 next schoolyears…then I can develop for FLHook as well…hihi…), but isn’t it easier to implent written/existing Features into FLHook with the main version instead of plugins?
I wasn’t pointing into Flak 88 only, but aren’t there many server which haven’t moved to plugin because then they would lost their features (except they would convert them into plugins which might be more work instead of implenting them into FLHook directly?). Some Coders won’t re-release their features as plugins due to the work needed to do that, but they may would give out the source code so that they could implented into the mian version?Argh…I try in german, I suck in english ^^
Ist es nicht einfacher/ressourceneffektiver (im Sinne von Arbeit), bestehende Features (NICHT als Plugins) in das Hauptprogramm zu integrieren als diese als Plugins neu zu schreiben? Ich meine damit, dass einige Serveradmins/Coder ihre Features NICHT als Plugins neuschreiben werden noch die Pluginversion nutzen werden, da ihre Features mit dieser inkompatibel sind. Aber WENN ihre Features in der neuen FLHookversion enthalten sind, gäbe es für sie auch keinen Grund, nicht zur Plugin/neuen FLHookversion zu wechseln - Ihre Features funktionieren ja nun mit dieser. Nicht nur das FLHook durch deren Features erweitert werden würde, sie würden dann möglicherweise auch anfangen, Plugins zu schreiben. Es würde also im Prinzip der Community/dem Projekt als Ganzem helfen, oder nicht?
(Ist alles nur Theorie, ich weiß nicht, wie der Aufwand wirklich ist, wenn man es direkt in das Hauptprogramm integriert ^^)Evtl. könnte man ja auch eine “Full” und eine “Light” Version des neuen FLHooks veröffentlichen, oder so.
-
Some Coders won’t re-release their features as plugins due to the work needed to do that, but they may would give out the source code so that they could implented into the mian version?
Not really. Most admins dont release their sources. And if they did, there is a high chance it would then be a lot more simple to code them as plugins.
Its not some trivial copy & paste because FLHook versions can differ very much. -
My account: [email protected]
-
I’ve reorganized the rights a little, from now on only Motah and Cannon have comit-rights.
If you have a change you’d like to see in the plugin version, please do the changes on your local copy and then create a patch-file and post it in this thread, or make a new thread for it.
Thanks.
