SVN Repository
-
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.
-
Since most of the active developers have since retired, I have decided to shutter FLHook development from the Forge.
The project is now available on Github: https://github.com/Friendly0Fire/FLHook
Merge requests are welcome by anyone who wishes to. This includes new plugins that may be distributed alongside FLHook itself.
Note that the version on Github has also been modified since the last SVN commit.
