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

[Neonivek]

They probably WOULD Soup but the program cannot recognise attacks so they couldn't do it if they wanted.

Heck I am sure they would allow you to play the game from stonesense if they could.

[soup]

Ah, that's too bad... I assume the program detects movement though, are there any plans to make the animation one-shot and then restart once when something moves?

[Neonivek]

The Program doesn't detect movement exactly.

It to my knowledge it just scans the map constantly. So I guess if Cow 7 was in one location in one scan and then was in another location in another scan... It could maybe extrapolate movement... but it cannot tell if something moves as far as I am aware.

[Keita]

That would make sense if it says 'scanning every 2ms'

[Neonivek]

That would make sense if it says 'scanning every 2ms'

It would only need to scan everytime there is a change.

[Winterbrass]

Another bit of a peeve is that glass windows are so thin and are without corners, and glass blocks, like all other masonry-based walls, appear exactly identical. Either I have an opaque dome, or I attempt to fake it with windows and have to deal with overhanging floor tiles.

I need to have another look at options for reading in wall tiles, but it currently isnt looking hopeful for being able to detect glass walls.

I'd help out instead of 'complaining', but I lack in the graphics-fu.

Some things are just plain oversights, so complaining can be helpful, too.

edit: Do your floodgates work better if you grab the latest floodgate config from
http://code.google.com/p/stonesense/source/browse/trunk/buildings/Floodgate.xml

My floodgates work perfectly now, yes, thank you. I actually did a little bit of testing, too, and a north-south path will dominate an east-west path in a cross formation. Not a complaint, just an observation.

[soup]

Even if the program can't detect movement, if they made it so that an object reloads its animation every time it moves to a new tile that would work as well... if it was made so each object only executes the animation once.

[Puzzlemaker]

So why can't stonesense detect items?  Is it just impossible to do with the way DF is set up to memhack it?

[Footkerchief]

So why can't stonesense detect items?  Is it just impossible to do with the way DF is set up to memhack it?

We were discussing item detection a few pages back:

As for items themselves, this was another feature that Lifevis had.  Presumably he'd found a reasonably efficient way of handling it.  You can see items (blue blobs) lying on the ground in that demonstration video.

"Is there an object here" is relatively easy- theres an occ flag for that, so I had it on a branch a few weeks back. Anything beyond "an object" eg "what kind of object" suddenly becomes much harder.

Ah, gotcha.  What makes identifying them so difficult?  Is it just expensive to iterate over the item vector, or is the item format not understood?

I think DFHack is getting item support, but the expense is the big factor. If we can get items at a specific location it would be much easier, but I dont think we have that info yet.

Otherwise we may have to resort to only reloading the object info when we really *really* need to, because it will be worse than when you hit 'stones' in your stockpile screen.

[CobaltKobold]

well, in the current implementation now... does it reload the sprite resource when it moves to a new tile?
like for example, does the animation start over when it moves to a new tile or is it the same cycle of frames?

Currently, its a 6 frame cycle, and mostly independent of the map reload loop. So critters will keep their place in the loop while moving. The animation frame is global, updating at a configurable rate. Sprites are redrawn when either the frame changes or the map is reloaded. Each critter has a fixed offset from the global frame to keep things from being to much in lockstep (so 1 in 6 critters will be in any given animation state).

ah I see... any plans to implement an action-based or one-shot based animation system?

well, I was thinking about it- there's another thread that I keep losing track of in which Mayday proposes a simple manner of animating things.

Ah, that's too bad... I assume the program detects movement though, are there any plans to make the animation one-shot and then restart once when something moves?

Problem: Fliers would stop flapping.

[soup]

well... could one-shot animation be implemented as an option, rather than a replacement...? then objects/creatures could be flagged with the attribute of one-shot animation as either 1 or 0.

[CobaltKobold]

Anyway, I was thinking about it- there's another thread that I keep losing track of in which Mayday proposes a simple manner of animating things.

Should probably fork animation discussion off, but...I'm unsure whether suggestions or modding is better for that.

[Jonathan S. Fox]

Unless it's a suggestion for how Toady can improve Dwarf Fortress, I'd stick with the modding subforum.

[CobaltKobold]

If someone wanted to work nearly FOREVER on a future visualiser they could make each bodypart of each creature individually (with visual injuries) so you can see how injured someone is by looking at them. That would be awsome [but it won't happen :"( ]. Heck even equipment could be visualised using that method.

Of course it would take forever, and is currently impossible, and would only be worth doing when DF nears completion

Well, the reason to do it is that making each part and piece individually means you only need to multiply items by poses (with some clever tricks you may e'en get away without this), directions, and creatures, rather than the factorial combinatoric explosion of equipment.

Kobold:

Okay, going from this...a demonstration of how you can do individual equipment pieces. (Forgive my horrible koboldhelm.)

Spoiler: master draw order-bold is in this animation (click to show/hide)

I got bored in class.
Before creature, we get floor, shadows, and any item/building here. (Hmm, gif won't alpha a shadow layer. drat. Still, illustrative. Took ground texture from Jadael's first stonerenders- smoothed silver ore.

• Overgarb(cape/cloak) (Back): red-dyed ornate cape
• worn Shield (back)
• Held item (back):Large steel dagger
• Hand/arm (back)
• Sleeve(back)
• Glove(back):Adamantine left gauntlet
• Drape-legging(back) (i.e. skirt-type, or bellbottom)
• Foot/leg(back)
• Fitted legging (back) (i.e. like pant leg, hose)
• Tail
• Footgear(back):Adamantine boot
• Foot/leg(front)
• Fitted legging (front)
• Footgear(front):Adamantine boot
• Draped legging (front)
• Torso
• Torso Garb: Gray(cave spider silk) tunic
• Headgarb(back) (In case of hood, say)
• Head
• Headgarb(front):Iron Helm
• Held item (front):Large Steel Dagger
• Hand/arm (Front)
• Sleeve(front)
  
• Glove(Front):Adamantine Right Gauntlet
• worn Shield (front)
• Overgarb(front)

This draw order works for all 8 facings, if you understand it right. In facing-away-from-viewer, both arms/legs are drawn at (back). Multigrasp items should be drawn at held item(back), similarly.
In case facing directly at viewer, both sidelimbs/held items get drawn at (front) instead, as would multigrasped item.

Anyway, the demopic.

You could either bumpmap or repalettize (depending on artistic style/taste) to get different materials/dyes. (Here, I'm using default colors: bright gray for steel, dark gray for iron, bright cyan for adamantine).

This also allows for severs, at least primitively- though that would entail expanding to the proper BPs (upper arm, lower arm, etc)

[Footkerchief]

^^^ That's really cool.  Good job working out the draw order etc.