Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[salithus]

Unofficial releases should always use a different release string to avoid incompatibilities and so that if people have problems they can accurately report what version they have, which is impossible if they have the same name as an official release.

If I understand the build/load process correctly, we'd need less stringent version checking for loaded modules. fricy and I have to compile DFHack as a .40.12r1 release because the latest .40.12 TwbT was compiled as that release. If I compile as r0, TwbT won't load.

[expwnent]

Extra plugins can just be recompiled for different releases.

[salithus]

Extra plugins can just be recompiled for different releases.

Not if we don't have the source, like fricy mentioned.

[lethosor]

Unofficial releases should always use a different release string to avoid incompatibilities and so that if people have problems they can accurately report what version they have, which is impossible if they have the same name as an official release.

If I understand the build/load process correctly, we'd need less stringent version checking for loaded modules. fricy and I have to compile DFHack as a .40.12r1 release because the latest .40.12 TwbT was compiled as that release. If I compile as r0, TwbT won't load.

The compatibility check is essential - if there are any structure changes between pre-release builds and r1, plugins built with the older structures could crash when using the official r1 structures. It would be safer to recompile TwbT (changing the release number of an existing binary might work, assuming it was built for the same version of DF, since I don't think TwbT relies on specific structures).
Edit: Ninja'd

[salithus]

Unofficial releases should always use a different release string to avoid incompatibilities and so that if people have problems they can accurately report what version they have, which is impossible if they have the same name as an official release.

If I understand the build/load process correctly, we'd need less stringent version checking for loaded modules. fricy and I have to compile DFHack as a .40.12r1 release because the latest .40.12 TwbT was compiled as that release. If I compile as r0, TwbT won't load.

The compatibility check is essential - if there are any structure changes between pre-release builds and r1, plugins built with the older structures could crash when using the official r1 structures. It would be safer to recompile TwbT (changing the release number of an existing binary might work, assuming it was built for the same version of DF, since I don't think TwbT relies on specific structures).
Edit: Ninja'd

It would be better than to version the structure/API changes and check plugins against that (yes I realize that would be a large undertaking). The upside would be that you wouldn't have to have a separate compiled DLL for each DFHack release, which would I hope mean troubleshooting plugins would be easier.

[lethosor]

It would be better than to version the structure/API changes and check plugins against that (yes I realize that would be a large undertaking). The upside would be that you wouldn't have to have a separate compiled DLL for each DFHack release, which would I hope mean troubleshooting plugins would be easier.

Isn't this what the existing system accomplishes?

[salithus]

It would be better than to version the structure/API changes and check plugins against that (yes I realize that would be a large undertaking). The upside would be that you wouldn't have to have a separate compiled DLL for each DFHack release, which would I hope mean troubleshooting plugins would be easier.

Isn't this what the existing system accomplishes?

No? The existing system assumes nothing can be forwards compatible, ever, as illustrated by the issue with TwbT. Despite the code being exactly the same, I have to have a version # that matches the build of DFHack. If I understood what I did above correctly, I'm using the exact same structures/API as .40.11 but with symbols.xml for .40.12 and building from source with a .40.12.r1 version number.

Versioning your structures/APIs allows you to be selective about what is/isn't compatible. The TwbT plugin, for example, would load because DFHack would see it using structure/API version that's compatible with the current code, rather than seeing that it wasn't built with the exact same version # specified in a makefile.

(fakeedit: also any input on my q above about adding text from the automelt/stocks/autotrade plugins?)

[LeoCean]

Well mifki is on now and it'd be easier for him to just add that change so you can have dfhack r0 but twbt does release source code if you look at the latest release builds.

[lethosor]

I think Fricy is referring to Mifki's modifications to other plugins (e.g. mousequery) to make them work better with TwbT.

[breadman]

e2: I got the Hotkeys plugin working with this release too (literally did nothing except figure out where the source was and how to add a plugin to the cmake jaunts):

e3: I also got automelt working HOWEVER - there's got to be a better way to find spots to add text than what I did.

It appears that we have duplicated effort; sorry for not being more vocal about the latter progress.  (At least this provides more evidence of their desirability.)  For automelt, I rearranged the lines again to put it and autotrade together, and made the two merge at the bottom when there isn't enough room for the stockpile links.

[salithus]

I think Fricy is referring to Mifki's modifications to other plugins (e.g. mousequery) to make them work better with TwbT.

Either way, there's no good reason (other than, as I conceded earlier, the effort required to make the change now), for plugins to have to be compiled against a specific version of DFHack as a whole. Without that requirement, the same exact twbt.plugin.dll could load against .40.11r1 or .40.12r0 without any work by anyone, which in turn means that people compiling starter packs and whatnot won't have to wait for as many updates with each release of anything.

Current process:
* DF updates.
* Symbol updates.
* DF hack updates.
* 3rd party plugins updates.
* Starter pack release.

New process could (should) be:
* DF updates.
* Symbol updates.
* IF new/changed symbols, DF hack updates to structs/API.
* IF DF hack updates to structs/API, 3rd party plugins updates.
* Starter pack release.

In this case, unless I just don't understand something about the symbols update process, I'm effectively running the exact same code as DFHack 0.40.11r1 with symbols from DF 0.40.12. I'm completely at a loss as to why, if only symbols.xml updates were really what was needed in the first place, I had to jump through so many hoops to get to TwbT on DF 0.40.12 in the first place - I should be able to just update the DFHack 0.40.11r1 with the new symbols file and go, not recompile every plugin just so it can convince DFHack that everything is 0.40.12r0.

e2: I got the Hotkeys plugin working with this release too (literally did nothing except figure out where the source was and how to add a plugin to the cmake jaunts):

e3: I also got automelt working HOWEVER - there's got to be a better way to find spots to add text than what I did.

It appears that we have duplicated effort; sorry for not being more vocal about the latter progress.  (At least this provides more evidence of their desirability.)  For automelt, I rearranged the lines again to put it and autotrade together, and made the two merge at the bottom when there isn't enough room for the stockpile links.

No worries! I've done 0 development on plugins - just got to the point today where I know enough to be dangerous.

[mifki]

Sometimes there can be changes that break compatibility, there was such between 0.34.11r3 and r5 not so long ago.
However of course I'd prefer not to recompile twbt for each minor dfhack update.
So in general version check is good but probably it should include only major changes.

That said, all other plugins are included in dfhack source tree and built together with it, so it's a problem for twbt only, so I don't expect anything to change here.

[salithus]

Sometimes there can be changes that break compatibility, there was such between 0.34.11r3 and r5 not so long ago.
However of course I'd prefer not to recompile twbt for each minor dfhack update.
So in general version check is good but probably it should include only major changes.

That said, all other plugins are included in dfhack source tree and built together with it, so it's a problem for twbt only, so I don't expect anything to change here.

Yeah I don't expect it will change either, but I'm still right that my way is better

Actually, I wonder how big of a change it would to just change DFHack's version to be separate from DF itself. That way you could do regular major/minor/revision versioning for DFHack (I'd call it 6.whatever at this point and consider 0.34.11r5 5.0) and then the DF version check would go against the contents of symbols.xml.

[mifki]

Sometimes there can be changes that break compatibility, there was such between 0.34.11r3 and r5 not so long ago.
However of course I'd prefer not to recompile twbt for each minor dfhack update.
So in general version check is good but probably it should include only major changes.

That said, all other plugins are included in dfhack source tree and built together with it, so it's a problem for twbt only, so I don't expect anything to change here.

Yeah I don't expect it will change either, but I'm still right that my way is better

Actually, I wonder how big of a change it would to just change DFHack's version to be separate from DF itself. That way you could do regular major/minor/revision versioning for DFHack (I'd call it 6.whatever at this point and consider 0.34.11r5 5.0) and then the DF version check would go against the contents of symbols.xml.

I will have to update twbt for each df version anyway (but not dfhack release).

[salithus]

Sometimes there can be changes that break compatibility, there was such between 0.34.11r3 and r5 not so long ago.
However of course I'd prefer not to recompile twbt for each minor dfhack update.
So in general version check is good but probably it should include only major changes.

That said, all other plugins are included in dfhack source tree and built together with it, so it's a problem for twbt only, so I don't expect anything to change here.

Yeah I don't expect it will change either, but I'm still right that my way is better

Actually, I wonder how big of a change it would to just change DFHack's version to be separate from DF itself. That way you could do regular major/minor/revision versioning for DFHack (I'd call it 6.whatever at this point and consider 0.34.11r5 5.0) and then the DF version check would go against the contents of symbols.xml.

I will have to update twbt for each df version anyway (but not dfhack release).

Things like the Hotkeys plugin, though, wouldn't - source I used for that was from before DF 0.40 so there's really no reason the dll from before shouldn't work, other than the version check that fails.