Print

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

[Urist McCheeseMaker]

Hey, I'd like to suggest looking at some form of interprocess communication for DF, so that the various visualizers and tools we have could get data in a proper manner instead of having to read specific memory locations that change every version.

There are three big advantages and a minor one:
1: Tools will usually be up-to-date the moment a new version of DF arrives.
2: Toady could offer more data, and possibly even more complex data than any tool could provide.
3: Visualizers could read the clothes a dwarf is wearing, and with some luck, Dwarf Therapist could even query for a path between two points and give the user insight into his fortress.
Minor: Toady could somewhat regulate which data is available. By offering data this way, it's clear that it's okay to use it for anything. By not offering specific data, it's clear that that isn't supposed to be known. The tool coders could still mess around and read those things from raw memory, but there'd be less incentive since there's an "official" way to get the data you actually need.

Sockets seem to be used a lot for this kind of thing. UDP, preferably with a rather careful interpretation (just drop faulty requests, don't handle them) so that it doesn't affect DF's own stability.

[WarttHog]

I was thinking about this a little with my post about Generic Queries: http://www.bay12forums.com/smf/index.php?topic=75629.0

You forgot another really interesting feature: Bots!  Interesting but possibly game-breaking.  :-/

[Urist McCheeseMaker]

Actually, yours suggests that Toady implements a complete editor inside the game, including menu's to keep up to date and various other things. Front-end and back-end, in other words. Mine is just the back-end. Tool-writers could write the UI, which tends to lead to better programs anyway, see Dwarf Therapist.

Also, bots.. if you mean automated scripts, they'd definitely be useful. To mine out whole veins, for example, while keeping a minimum of 1 wall between mined-out vein and your living quarters. Or to watch the surroundings of a minerdorf, and check for possibly dangerous situations (collapses and such).

[WarttHog]

Yes, my suggestion is primarily front-end but here's what I meant.  My suggestion recommends that the DF game thread should query an off-thread database which is responsible for data integrity and management.  Once that was in place, you could have a DB interface thread which responds to some kind of IPC.  Sockets work fine for requests but if responses are too big, maybe some shared memory would be helpful -- but that's an implementation detail.  This way tools could properly query the database instead of peeking and poking and the database could programatically ensure critical integrity.  That's what I meant.

Scripts to make your commands smarter are great but I was also thinking of scripts that automatically handle some situations for you.  Eg. As soon as someone's injured, remove all non-medical jobs from my medical dwarf.  A siege just started: Station my squads in their "attack coming from north entrance" positions.  These would be set up by the player but triggered automatically.

Of course then someone might try to make a complete DF AI which would be fun to write but may or may not be as useful otherwise.  If the game ever goes multi-player, the database could just disable external query access to make sure nobody's cheating.

[sockless]

There are already plenty of hacks for DF.
It doesn't matter if someone hacks in the game, since they are only cheating themselves. It's not multiplayer and there's no leaderboards, so it doesn't hurt anyone else.

[Urist McCheeseMaker]

My main point was not limiting hacks.. It's about allowing the good ones like Therapist to access data in a more standardised way, so that there's less memory-seeking to be done and tools could eventually be better integrated.

[Talas]

OP

This is a wonderful suggestion (in fact I registered here just to post in this very topic).


However I know some more possible benefits:

Minor: Depending on implementation this could allow for 2 or more players controlling the same fortress (All data sent through sockets) (Also it would only lag if you have high ping or the server is overworked).

But, more importantly this would allow the DF devs to concentrate their efforts on the game mechanics entirely..

Leaving the GUI (graphical user interface) to the hands of the community..
And also split the GUI and game logic code into 2 bins.. Which from my experience is always good for the project (both performance and readability wise).

This way, those capable and interested could start up projects to make nice (fully featured) interfaces for DF, hopefully open source (but not required to).

This would also partly eliminate the fps issues on big scenes, as the GUI would run in a separate process, simply drawing all it can get from DF.

[NW_Kohaku]

There are already plenty of hacks for DF.
It doesn't matter if someone hacks in the game, since they are only cheating themselves. It's not multiplayer and there's no leaderboards, so it doesn't hurt anyone else.

The thing is, it's kind of hard on the hacks to keep updated, since every new version requires a new version of the hacks to keep up.  The constant clamoring for updates is why chmod abandoned Dwarf Therapist, one of the most useful of those hacks.

The thing is, however, that Toady has said that he doesn't really want to have to care about what the people who do the hacks are doing, and so he doesn't want to give them anything, even if what they do are really necessary for getting many people to be able to enjoy his game (like with Stonesense or the like).

[Lord Shonus]

More accurately, he feels that, if he were to officially support them even in such a small way, he would be assuming the responsibility of keeping htem working. Thus, he will not do so.