Print

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

[Panthera Leo]

I wonder if Toady could be persuaded to create a interface (.so/.dll) for DF? I'm sure the functions for accessing the same thing in are in the code anyway... I'd think all that has to be done is to move them and the data structures to their own object, and compile it separately.

It should not make that much slower as every C/C++ function is a pointer anyway. The only difference is if the pointer is hard-coded in the executable or stored in memory at run-time, iirc. It would solve the memory mapping issues, I would think.

The idea being, while a step or three more complicated to compile (though not that hard, _{if the source code is properly maintained >.>}) DFHack is effectively reinventing the wheel anyway. The built in functions already know where the data structures are and manipulate them. DFHack finds them the hard-way and does the exact same thing.

So, Toady One, what are the odds of you refracting those functions into a .h(pp) and (.so/.dll) file? Doing the same thing SDL does for you currently. (Though I think SDL is written in assembly from the start.)

It would allow programs like Runesmith or Dwarf Therapist to be updated in real-time. Beyond the first step of moving said functions to be publicly accessible (as DFHack makes them again away) and altering the 'make' file(s), I'm not sure it would change anything.

(Well, it would be nice to have documentation to go with it, but given that fact someone already pics apart your program byte by byte, I'm not sure that would be a issue.)

[NW_Kohaku]

Green text doesn't summon Toady One to your thread, that's just for the Future of the Fortress thread.  It's very rare that he ever respond to suggestion threads at all anymore.

Also, you want limegreen, not just green.

Anyway, what you are talking about is making a backdoor into Toady's code to allow memory-accessing tools better access to the inner workings of the game's code.  This sort of proposal has come up several times in the past, and Toady has directly responded to this when it involved the talk about making a full third-party interface:

Spoiler (click to show/hide)

Which for me (and granted, I'm picking a recent post -- I've read the thread, but don't remember when this came up first in this thread) is along the lines of what Jamuk said.  I'm being asked to assume risk.  I don't accept assessments of the risk as extraordinarily slight -- I've seen no sound basis for those assessments here.  I also don't think the currently proposed licensing/obfuscation method of putting the cat back into the bag would work -- with a principal downside being that it requires me to turn into an asshole who, after initially sanctioning the process, breaks everything that people have been working on.  Publishing an API and then trying to reel it back in just seems completely unworkable and irresponsible to me.  So the point is to assess risk upfront and then make a decision I can live with.

And right now, I have no idea what would happen.  This isn't the same as leaving my math job or adding the Z coordinate.  The first was a decision I had to make personally for my quality of life, and the second was a calculated risk which I didn't really have strong misgivings about (though some people are still pro-2D version, I think I can get most of them what they want over time in terms of gameplay difficulty, etc., though it'll never feel like it's quite on that rail again most likely).  Do I accept that third parties could improve the interface?  Of course.  Do I think I could do better than a third party myself, even over time?  No, not at all, though I can certainly improve on what I've got now to a large degree even without external input (which I, of course, love to receive).  So, initially, there's some attraction to the third party interface idea.

However, reflecting on the position I'd be in, there are things not to like about it.  How many threads were there about broken utilities when this version came out?  If more than half the player base comes in off a third party interface (and given how much the current interface sucks, and how much it is a source of first time downloaders dropping the game, this is not only imaginable, it is very, very likely), how would it be if it broke at each release?  There's no way to mitigate that without my direct involvement -- imagine a release down the line where you can suddenly move dwarven armies around on the world map, with a tactical view and various options.  That interface can't write itself, and it wouldn't be a quick patch, though certainly dedicated people, assuming that about whoever is maintaining the front-end at that time, can pull things together rapidly.  The pressure on me to work directly with them to get the interface out at the same time as the game itself would likely be immense and disruptive, given what little evidence we have from broken utilities.  That's not to say that I often get requests to work with utility writers (other than from the writers themselves, who I generally accommodate), but this would be at a different order of magnitude.

So what's the exact risk there then?  First, I don't want to work with other people.  So, assuming I don't do that, there's now a constant amount of pressure on me and a general disruption in the forums.  The latter could be mitigated with some announcements/guidelines, etc., but the pressure wouldn't go away.  Monetarily, it's impossible to say what on earth would happen, but if I supported the third party interface directly pre-release, I'd likely make more money, but I'd be unhappy.  If I didn't support it directly, but it was there, I'd still likely make more money, but I'd be unhappy.  That's not to say that I don't want to grow the audience and allow more people play the game, but I want to do it in a way with which I feel satisfied, even if that ends up being slower or just plain worse than a hypothetical third party alternative.  If someone, as a potential donor, thinks that's unreasonably selfish, that person shouldn't send me any more money than he or she thinks I've deserved for his or her enjoyment, just like everybody else.  Despite my dedication to this project, I'm unwilling to sacrifice my enjoyment of working on it for anything, including its quality or even its future release if it comes down to that.  That should be plainly obvious.  I'm not a slave.  Of course I do some things I don't like working on, with the interface and more.  I fulfill requests for features I'm not going to use myself.  However, again, the current proposal is of a different order of magnitude, with the potential of ruining it for me, and the end result is completely uncertain.

Given what I've seen here and there, it seems like a full third party interface might develop even without my involvement (rather than the various utilities we have now), but in that case, despite the same issues that might come up, at least it won't be a situation of my own creation that I feel a strong obligation to deal with, although the pressure would still be there.

Incidentally, in the proposed model, I still don't think I'd be able to bring code back in to the core project -- the first Kobold Quest port attempt showed that people bringing in code don't necessarily check or care about the licenses of the code they are swiping, and I can't assume that responsibility for them (it has stuff from Wine which shouldn't have been there).  Problems come up here with tilesets and so on too -- I know there've been a few cases where a contributor used somebody else's art and then it was put in a game, causing some legal trouble, though I don't have them at my immediate disposal.

I may have missed a lot, both problems I'm not thinking of and ways to handle them, since this gets complicated and is, due to lack of information, somewhat unspecified, but that's what I've got right now.

See this post for an awful lot more on it.

Yes, those are about interface, but the way that it was going to be done is the exact same thing.

[Panthera Leo]

Anyway, what you are talking about is making a backdoor into Toady's code to allow memory-accessing tools better access to the inner workings of the game's code.

Has it now? Sorry to waste peoples time, Clearly I need to brush up on my 'Search-fu'. Thanks for the link. Also, thanks for the green info, but I think I'll leave it as is if only to make reading my rambling that much easier.

I wasn't thinking API, was just thinking making what is public as is. If they didn't like it, well they don't have to use it. Then again, I have twisted view of things. The only difference between what is and the suggestion is not everyone's willing to sift though the assembly. (IE, assembly/encryption is not secure in any way shape or form. It just adds to the work that needs to be done to do the same thing. The idea that is , pardon me being blunt, akin to a child's security blanket. It provides zero protection, it just makes one feel fuzzy and warm.) The suggestion expedite what already is.

Edit: That is the only way to secure information is to make it null or of no value once the assembly/encryption is understood. A program can't do that as it has to be plainly laid out for the machine, and assembly has no natural obsolescence. It can me distorted or erased, but in the end it still much be plainly visible at some point to the machine and that's all it takes.

Err, I'm just complaining now. Thanks for the info and link.

[Artanis00]

I wasn't thinking API, was just thinking making what is public as is.

Actually, that is an API, which can be read-only--or even write-only--just fine.

[Panthera Leo]

I wasn't thinking API, was just thinking making what is public as is.

Actually, that is an API, which can be read-only--or even write-only--just fine.

Yes, but only by definition would it be a interface; However, what I had in mind barely qualifies in name only. A API is laid out in advances, documented, and some care is given to it. As much as my last few posts give the impression as a "whatever, 'it works', ship it" attitude, I'm a bit more snobbish then that. Normally, I'm of the view if you haven't given it the time to do it right, then you have not done the job at all.

Which is why I never call it a API, I wouldn't regard it as one. The original idea was the only difference between what's happening - and being condoned - now and the idea is on one side of the coin, it happens purely from what amounts to a (hex-editor/memory scanner) in pure assembly. The other is in a formal language I suspect to be C or C++. They both do and accomplish the same thing by the same means.

The only real difference being the time involved, and someone's preconceptions.

However, the question was asked and answered. I'm just clarifying the point.