Actually - *IF* Toady wanted to do anything even remotely like support this - he would build in callable functions to the program. It would represent a change in design strategy - and could even lead to splitting the UI from the 'core' program which would in turn open the door for 3rd party graphical UIs. In other words - he wouldn't bother to support memory hacks, he'd go ahead and support data manipulation tools. Or he'd directly code in cheatie bits and side step the need for all this.
Problem with this (same idea comes up every so often, prolly's been mentioned before in this thread) is that if you have 3rd parties maintaining the interfaces / 3rd party tools, what happens when DF significantly updates? The 3rd party tools have to update as well.
WARNING: Programming rantWell, if we want to get into programming paradigms... not exactly.
If there's anyone here (besides me) who programs in an object-oriented language, you'll know the concepts I'm thinking of. When a person writes a library or a chunk of code (at least following OOP paradigm), they try to separate interface from implementation. This means that they create a unified interface for the code that controls how the code's users will be able to access that code, and the people who will write stuff based on their code only need to know how to operate the interface. They don't need to know what steps the interface parts take to get the job done (the implementation that powers the interface); only the code writer need worry about that. By sealing the implementation off from the users of your code, you ensure that they can only access it in ways that you can control. This also means that, if you decide to change your code, the users of that code don't need to rewrite their programs, because your interface didn't change (even if the things that that interface does to your internal code have changed). Of course, sometimes the interface has to change to accommodate new stuff, and that's how it goes.
It's like driving a car. When you drive a car, you hop in, put on your seat belt, and then you have a series of controls to operate the car: steering wheel, pedals, various other systems, etc. You don't need to know the exact specs on the car, and who was responsible for milling the third piston cylinder in the engine block, because these things are irrelevant to you. All you need to know how to do is operate the car (its interface), and you trust that the car itself (the implementation) will do the rest. If the car maker decides to switch from one engine type to another (four stroke to two stroke, who knows), you don't need to learn a whole new way to drive a car and get a whole new license, as long as the old system can still operate this newly changed engine.
Of course, there are times when you will want to understand some of how the car works. If you need to move big cargo, for example, it's good to know how much torque your engine can output, because you need to know if you can move that stuff with the car. (This is like a sorting algorithm; the implementation of the sorting algorithm makes a big difference in speed.) And sometimes, you need to just do things from the ground up. A racecar driver probably has a team that builds the car with him/her, or contracts out special parts from manufacturers and assembles the car independently, because they need to optimize and perfect every little bit, to squeeze every drop of oomph out of their car. They can't afford to get some consumer car because the implementation, in such a case, is simply too important to let someone else handle it.
As an even more relevant example, look at DF itself. We don't have to care how DF works, as long as we know how to play. As long as Toady makes sure that certain keys have certain effects, we don't worry about how exactly he codes those functions of the game, because they do what we want. Toady can change the code itself, and as long as the controls are the same, we can still play the game. Of course, as new concepts are added to the game, new controls are added in for players to work with these elements, and these are things we have to learn. For example, back in the days of 2d DF, the leap to 3d DF was quite significant. *big* changes like this would obviously require a bit of a reboot.
In this case, we are worried about more than the interface, because we want to manipulate things that aren't available in the interface (that's the point of tools like Runesmith). In addition, we don't want DF to lag so much that it's unplayable, so we need to know "enough" about its code to be assured that, when we open up our fort, it won't crash instantly from the two thousand kittens we have wandering through it.
tl;dr Good programming for this kind of situation separates the interface from the implementation, so updates would not break the interface layers (unless they were truly groundbreaking updates, in which case it's justified). Maxima or Mathematica work in this way - you have a kernel underneath that does the work, and interchangeable interfaces for users to operate the kernel.
Of course, Toady has the last word, and if the system isn't already programmed to work like this, we're talking about an explosive revision - months of refactoring and re-engineering to code that (currently) works pretty well for the end user. Converting all your code to make it fit a whole new system is... an intense task, to say the least. It would be awesome if it happened; personally though I'd prefer that the game's arc development continue as it's going, because there's some interesting stuff coming up as I understand.
Just a rant from a semi-experienced hobbyist programmer.
Poll
288 (45.6%)
Author
Topic: Runesmith - A DC like tool (Read 366070 times)