SVN Repository
-
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. -
Could you please notify if you make any killer changes to the socket connection code - especially if you feel it would break compatability with Biocross and it’s FLHook interactivity.
Other than that, any news on what changes/fixes to expect in the new version?
-
Can you add me so I can see this beta version please?
[email protected] -
Everybody can checkout the latest build here:
-
I copied the SVN to the Starport Forge, please only use this for any further updates.
New SVN URL: http://svn.the-starport.net/flhookplugin
-
Are current plugins incompatible with svn version?
Need to recompile each of them too?
-
You need not only to recompile, you also have to port them.
-
I’ve updated FLHookVC6Strings for the first time in years probably… I needed to use a really obscure function call which returns a wstring and obviously calling that from VS2013 made the whole thing explode.
The good news is that the VC6 project runs just fine provided you can get VC6 (it’s no longer on MS’s site). I’m thinking I should upload it here, provided w0dk4 doesn’t have any objections, since it took me a bit to find a legit download.
