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

[Crossroads Inc.]

Are we perhaps making this TOO hard?

Would be easier, instead of trying to "create" or "Draw" items, to simply have small packets of information onbored every unit that says "UNIT-X Posses the following items!" And if it dies, the items materialize and appear?

[CobaltKobold]

Thanks, Footkerchief. Layers make everything much easier (and it was really easy to make that animation, since it's...draw order...which is layer order...)

a little insomnia and the magic of layers yield a kobold diplomat (with or without alpha shadow)

...is the toga obvtoga enough? Scepter feels good, as does scroll he's presenting. Tempted to go fullcaesar and ditch the scepter for a laurel crown, but that'd be a bit harder to draw.

@Crossroads: Point was to lay the groundwork for an equipment-drawing mode rather than a draw-by-profession mode.

[Mike Mayday]

I think the walking animation is fine, what I did notice though is that the torso is too long for a dwarf, I fixed it real quick to show the difference.

Ah yeah, I wanted to keep the head big enough to have distinguishable features, then the torso a bit smaller to fit the details for identification and the legs even smaller since they usually have no identifying features. I'll mess with the proportions a bit but I'm actually happy with how it looks now.

[Puzzlemaker]

I don't know exactly how hacking works, but wouldn't it be easier to update the changes instead of scanning everything every single time?  That way item updating could be done a little reasonably, at least.

[KaelGotDwarves]

I don't know exactly how hacking works, but wouldn't it be easier to update the changes instead of scanning everything every single time?

I'm not a memory hacker by any stretch of the imagination, but that's not how it works bro.

Ugh, I tried my hand at ballistae and catapults but, I'm such a crappy pixel artist.

[Jonathan S. Fox]

I don't know exactly how hacking works, but wouldn't it be easier to update the changes instead of scanning everything every single time?  That way item updating could be done a little reasonably, at least.

In an ideal world, yes, but it would involve either sending information to Stonesense every time something changed, or having a convenient list of changes sitting in memory. The first is impossible here since Dwarf Fortress isn't sending anything to Stonesense, and the second is very unlikely, handy though it would be.

Generally speaking, if you're only getting information on the game state by looking up the game state in memory, then the only way to find out what the changes are from last time you looked is to manually compare everything in the current game state to the previous game state to see what's different. At that point, it's easier to just entirely replace the old data with the new.

Put simply, you can't only update what changed because you don't know what changed until after you scan everything.

[soup]

I think the walking animation is fine, what I did notice though is that the torso is too long for a dwarf, I fixed it real quick to show the difference.

Ah yeah, I wanted to keep the head big enough to have distinguishable features, then the torso a bit smaller to fit the details for identification and the legs even smaller since they usually have no identifying features. I'll mess with the proportions a bit but I'm actually happy with how it looks now.

yeah you're right, yours definitely looks better... I suppose it looked awkward because it was missing arms, but then again anything looks awkward without arms lol.

also I was wondering, what editing programs do you use for your sprites?

[Sean Mirrsen]

Why do you have to scan all the items to know what changed?

This is something that's been bugging me in real life as well. Real life isn't a perfect system, but this process should be relatively fail-safe (I'm speaking of the real-life situation)

1. Count everything you have in stock.
2. Monitor for when someone takes or puts something in the stock.
3. If someone does put or take something, update your record.
4. Goto 2 unless X time has passed since 1.
5. Goto 1.

Basically, don't scan the horrendous item list except very rarely to make sure the items are still where you think they are. Instead, look for dwarves changing inventory, digging events, dwarves eating and other things - in other words, all events likely to generate or remove items. But I don't know whether it's possible currently or not...

[Footkerchief]

2. Monitor for when someone takes or puts something in the stock.

This is the hard part, of course, for reasons John S. Fox just explained.  It would be possible to make guesses about when items should appear and disappear, but it would be utterly insane to implement -- you'd end up duplicating a good deal of the game logic.

[kaypy]

2. Monitor for when someone takes or puts something in the stock.

This is the hard part, of course, for reasons John S. Fox just explained.

Its the hard part in real life, too 8-)

And to fill up my screencap quota for a bit longer:


I'm working on making the various terrains more configurable. Its still kinda broken in many places, but it worked enough for my glass statue to show up as actual glass for once.

Hmm. We need borders on the edges of walls as well as the tops...

[Sean Mirrsen]

Alright, then a question: Presuming the item list is a table of indices, then if an item is destroyed, will the empty index that's left behind be occupied by a newly-created item?

Because if it isn't, you can only keep scanning the end of the list, seeing if any more items appeared since you last looked. Item movement can usually be replicated using game logic. Monitoring creature inventories doesn't seem like that hard of a task, comparatively. Other cases of items being moved include collapses, flow pushes, ranged weapons firing. These are harder, of course.

Even if we'll be going the simple'n'hard way, sorting through the item list doesn't need to happen instantaneously. Make it a resource-sensitive process, updating only as many items at a time as would be comfortable for the user. I don't know a thing in how such stuff is done, but it seems a reasonable alternative to having periodic pauses while the whole list of a few thousand items gets sorted through. Think how content gets updated in MMOs gradually, sacrificing looks for smoother movement (well at least that's what it seemed like in Lineage).

[CobaltKobold]

The other thing to look at would be the item count, of course.

As for updating, it hit me-an option to check the dwarven frame count first, and only update if it changed (else, nothing has!) 'course, this requires locating it, but something that increases by 1 each time you hit "." doesn't strike me as one of those variables that would be difficult to find by memsearch.

...might want to embark on a mountain with hungerless/aleless/etc. people first though, or those counters would too, thinking. And station them far from each other so they don't talk.

[Jonathan S. Fox]

The other thing to look at would be the item count, of course.

As for updating, it hit me-an option to check the dwarven frame count first, and only update if it changed (else, nothing has!) 'course, this requires locating it, but something that increases by 1 each time you hit "." doesn't strike me as one of those variables that would be difficult to find by memsearch.

...might want to embark on a mountain with hungerless/aleless/etc. people first though, or those counters would too, thinking. And station them far from each other so they don't talk.

Checking the frame count to save scans could be useful if the frame rate of Stonesense exceeds the frame rate of Dwarf Fortress. I can only speak for myself, but Dwarf Fortress normally runs at 100 frames per second for me, which is greater than any display ever needs to run. I believe that the highest rate Stonesense can update without altering the init file is 20 frames per second, and that's plenty. This is a good solution, but it will only improve the speed of the visualizer if you have the visualizer updating faster than the game is.

Alright, then a question: Presuming the item list is a table of indices, then if an item is destroyed, will the empty index that's left behind be occupied by a newly-created item?

Because if it isn't, you can only keep scanning the end of the list, seeing if any more items appeared since you last looked. Item movement can usually be replicated using game logic. Monitoring creature inventories doesn't seem like that hard of a task, comparatively. Other cases of items being moved include collapses, flow pushes, ranged weapons firing. These are harder, of course.

Even if we'll be going the simple'n'hard way, sorting through the item list doesn't need to happen instantaneously. Make it a resource-sensitive process, updating only as many items at a time as would be comfortable for the user. I don't know a thing in how such stuff is done, but it seems a reasonable alternative to having periodic pauses while the whole list of a few thousand items gets sorted through. Think how content gets updated in MMOs gradually, sacrificing looks for smoother movement (well at least that's what it seemed like in Lineage).

Items might be enumerated with a unique identifier over the life of the game (LCS uses a similar system for people), but even if that's the case, it's very unlikely those would actually be indexes into an array. That would result in a giant memory leak as new memory has to be continuously allocated while previously used memory isn't released. There are data structures that can simulate this sort of indexing while not actually using an array, and therefore not hemorrhaging memory like this, but Dwarf Fortress doesn't tend to use these; it uses mainly just lots of STL Vectors. I say this because 1) the same is true of Liberal Crime Squad, and 2) he's said as much.

Assuming that it is possible to scan the end of the list for new items though, that would only work for items being created, not destroyed or moved, as you know. The problem then becomes that it's not plausible to simulate every event that can influence item movement or destruction. Maybe you can assume items currently in inventory will remain so, but when people grab items out of stockpiles or drop things for any reason, or eat food or booze "explodes", the visualizer will become desynchronized. This is just too common of an event to assume it won't happen with any frequency. (Edit: Okay, maybe booze explosions aren't that common...)

I don't mean to be a complete naysayer on your ideas though, it's good thinking, it's just that the difficulties inherent in getting your information by scanning memory with an external program severely limit our options here. I do agree that if the overhead is too high to smoothly scan the item list in a single frame, checking the list piecemeal over multiple frames is better than having a hitch in the frame rate, assuming that the item list is sufficiently stable to allow this without really strange behavior.

[Sean Mirrsen]

Well, if the visualizer is desynched, you can always recheck the entire item list and put things in the right places. It's like any game being played over the net - you optimize by only sending basic commands and letting the client figure it out, but every once in a while you do send the whole lot of stuff so that the clients remain in sync.

[Jonathan S. Fox]

Well, if the visualizer is desynched, you can always recheck the entire item list and put things in the right places. It's like any game being played over the net - you optimize by only sending basic commands and letting the client figure it out, but every once in a while you do send the whole lot of stuff so that the clients remain in sync.

That's true for networking, but:

1. The programs are sending event information, which DF does not do.
2. The programs share actual game logic, and so can simulate events.
3. The programs can tell if there's a desynch by comparing RNG seeds.

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.

Assuming that items in inventory remain in inventory is common sense if you're not scanning the item list every frame, but otherwise there's not much you can simulate through the client side in a case like this. It's just not like networking where they can duplicate the game logic in both of the programs.