Print

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

That's right

That is right

[Sean Mirrsen]

We can make logical assumptions, and correct when resynch comes. Slightly wasteful, and therefore it would have to be optional, but there's no other way to actually have shot projectiles displayed in the visualizer. Either way we'd have to somehow intercept the "host" function calls and get data from them.

[CobaltKobold]

We can make logical assumptions, and correct when resynch comes. Slightly wasteful, and therefore it would have to be optional, but there's no other way to actually have shot projectiles displayed in the visualizer. Either way we'd have to somehow intercept the "host" function calls and get data from them.

...um, you could maybe look at the combat eventlogs(however that works) to generate flying projectiles. Not necessarily where they go if they miss, but at least for a combat-movie-vis (which I was brainstorming a bit on)

anywy, having an isokobold broken up into its proper layers makes building new ones messes easier than not.

additionally, do brooks crash stonesense? I think that's what's making mine come down (...and take linux with it. Funnily, music continues to play until loop point...)

[Puzzlemaker]

Okay, I get what the problem is.  Would it be possible to keep track of the previous state in a smaller format using some form of CRC or something?

[Jonathan S. Fox]

Okay, I get what the problem is.  Would it be possible to keep track of the previous state in a smaller format using some form of CRC or something?

The short answer is no, unfortunately. A CRC (or another hash function) will, after scanning both data sets, tell you if the new data and old data are different. BUT, you have to scan the new data first, which defeats the purpose for us. Furthermore, if there were changes, it doesn't tell you what changed, only that changes occurred.

That's more useful than it might sound, even if it doesn't solve the problem we're talking about. It's often faster do this than to directly compare everything in each of the data sets. More importantly, it gives you a quick and dirty way of making sure any sized amounts of data come through a network intact -- you send the data's hash along with the data, then have the receiving computer recompute the hash value on the data it receives. If the computed hash matches the hash you sent, the receiver can be confident that the data came through uncorrupted. If it doesn't match, the receiver knows some corruption occurred, and can send a message back asking the sender to send the data again. This is useful for individual network packets all the way up to entire files. Since hash values are very small, the scheme provides a very bandwidth-efficient way of making networking a lot less frustrating than it would be if computers weren't constantly doing this. There are other uses for hash functions besides network verification, but I'm already going way off topic.

[bartavelle]

None of these apply here. If all you're doing is tracking item creation and creature movement, it's going to desynch almost continually once the fortress gets off the ground, and you're not going to know it. You'll have to scan regularly either way.

I did not read what you guys are specifically talking about, but it is entirely possible to get events from DF by instrumenting it. It is however a complicated task.

[Footkerchief]

Okay, I get what the problem is.  Would it be possible to keep track of the previous state in a smaller format using some form of CRC or something?

The short answer is no, unfortunately. A CRC (or another hash function) will, after scanning both data sets, tell you if the new data and old data are different. BUT, you have to scan the new data first, which defeats the purpose for us. Furthermore, if there were changes, it doesn't tell you what changed, only that changes occurred.

Too bad it's not possible to access the RAM's own checksums.

[strich]

I actually tried to do a little research on this when I first heard about Stonesense. We know what memory space the map occupies, among a few other things. So I wondered...
Work with me here as I'm no pro debugger here:
1. Monitor the CPU registers themselves for changes to the address space - I know its possible, I've done it. But I'll guess its the most performance intensive way to do such a thing, or anything for that matter. I don't actually propose this solution, but maybe it'll spawn a better idea.
2. Hook the code that does the writing, either DF itself (Though I'm guessing that's messy as hell) or whatever process handles writing to memory in Windows.

[Footkerchief]

either DF itself (Though I'm guessing that's messy as hell)

Yeah.  I think this is what bartavelle was alluding to above.

whatever process handles writing to memory in Windows.

Kernel mode hooking is apparently possible, but not for the faint of heart.

[jonask84]

Guys, this is really much more a dfHack discussion maybe we should start a thread for dfHack?

[Footkerchief]

Guys, this is really much more a dfHack discussion maybe we should start a thread for dfHack?

Oops.  Yeah, here's the DFHack thread.

[Jotaf]

Well, I may as well say this while it's slightly on-topic: it wouldn't help with items, but for updating the state of tiles, you only need to check around some special locations, namely around water, lava, and dwarves (since they can dig and place stuff). It could be a huge performance benefit compared to re-reading the whole map...

[CobaltKobold]

Well, I may as well say this while it's slightly on-topic: it wouldn't help with items, but for updating the state of tiles, you only need to check around some special locations, namely around water, lava, and dwarves (since they can dig and place stuff). It could be a huge performance benefit compared to re-reading the whole map...

grass. shrubs. trees. These all grow away from those things you mentioned, and are supported in currentSS.

[Deon]

Vermins, creatures (building destroyers), temperature (ice melting) etc. Too many things to account for.

[Jadael]

But maybe you could figure out what's visible onscreen and only update those tiles? Or does it do that already? Not occlusion, obviously, but like, things that are off the edge of the view.

[Winterbrass]

But maybe you could figure out what's visible onscreen and only update those tiles? Or does it do that already? Not occlusion, obviously, but like, things that are off the edge of the view.

I think that this, perhaps, was the stroke of brilliance that was being waited for.