Bay 12 Games Forum

Quote from: lethosor on September 26, 2016, 11:28:17 pm

Another announcement of sorts:

It turns out Ruby 1.8 (which we use) doesn't actually compile for 64-bit Windows, at least not without techniques that nobody has investigated. Ruby 2+ would compile, but I don't know if it would work, so I'm waiting on jjyg for that.

Besides that, I can't think of any major blockers for a pre-release (there are some for a stable release). Do note that if we did put up a build now, no ruby scripts would work at all in the 64-bit Windows build. (I suppose now would be a good time to convert "multicmd" to a built-in command, before that becomes an issue.)

Hmm.  Just to float the idea, what are the arguments for and against dropping Ruby support?

Keep Ruby:  seriously, it's fine.  Why break what works?  People actually do use it!

Drop Ruby:

• No API documentation at all
• Relatively poor structures API (I think?  Hard to tell when there's no docs...)
• Standardising on Lua would free up developer resources
• Fewer scripts - there are 190 .lua and 38 .rb files in the dfhack repo; 147 to 28 in the scripts repo.
• Fixing and maintaining Ruby support might be a similar amount of work to dropping it and a one-off porting effort; especially if fixing it involves a useful degree of documentation.
• It makes tooling more difficult (number of languages installed, cases for build systems, docs support, etc) for developers and deters new contributors.

To be clear, I'm not proposing that we should drop Ruby support because it's run into a problem here - it's because Ruby has been a second-class scripting language in DFHack for some time now, the total absence of documentation is annoying me, and it makes supporting other things (eg unifying in-console help) more difficult.

Is it possible to butcher a corpse with a script? I know create-unit uses code from the arena to spawn a creature. There is also the arena butchering. You could theoretically make a script that spawns a creature, kills it (blood = 0), butchers it, then erases all non-bone items.

I have no idea... I looked at the offending code, but didn't see any obvious problems. I'll try to reproduce the error when I get home.

You did use the .png tilesheet right? .bmp won't work (but it still shouldn't give that error).

I did do some experiments with the tiletypes command, which let me put dirt walls anywhere except constructions.

What I didn't test, but what I would want this for, was see if trees grow on the resulting dirt.

I want hanging gardens.

Quote from: lethosor on September 03, 2016, 11:30:14 pm

One issue is that overlays don't necessarily have to be rectangles. They usually are, but it's not required, and there's no reason for it to be required currently.

Mifki did come up with a solution that involves rendering the vanilla dwarfmode/adventurer screens to a separate text buffer, overlaying whatever DFHack screens draw (as text, not explicitly to the map) to that, then rendering the result. (At least, that's how I remember it.)

I think that was the code I was editing.  It does seem to be there but doesn't work for the dfhack viewscreens.  I'll make it optional so that its not necessarily on for all views only for ones with the callback implemented.


Ok. Running into issues with Lua forms again.  I'm really confused by the dynamic layout engine for automatically placing widgets/subviews/... .  Sometimes it works as I expect some times it doesn't. 

My issue is that I would like to have the view dynamically size based on the size of the screen.  I suppose I can manually calculate all of the positions but it seems like there was some basic support.  For example, a subview stack might be { Label, FilteredList, Edit, Label, HorizontalRule, Label, HorizontalRule, Label }  where HorizontalRule is a new widget I created to draw a straight line and CustomControl was just something with custom drawing.   I'd like everything but the FilteredList to be fixed size in a vertical layout but the items below the list are relative to the bottom.

Sometimes the labels and edit controls seem to understand their position in the stack sometimes they don't but I'm not sure why.  I was able to workaround the sizing of the edit box by using a pane and forcing a height constraint by using on_layout.  There don't seem to be easy ways of constraining the sizes of some widgets, am I missing something or is the current behavior not anticipating use like this. 

I suppose I can write something myself or force layout but hate reinventing the wheel.  Having said that I do have a nice dynamic layout engine from a couple of decades ago for C that might work reasonably well here.  I'd worry about conflicts with existing widgets or creating a fork of sorts though.

Thanks.  So I've started writing some preliminary scripts like one to just sort by distance of player to quickly show items and filter out junk.   One thing I've run into is I'm not sure how to filter out items that cannot be picked up like coffer, table, throne, ... furniture-type stuff.  I'm sure there are others but I'd just want to show things that normally only show up in the get menu.   

Is there a quick way or do I need to build something based on itemtype and filter it that way which seems more error prone.   For now I'll use the item:isFurniture(false) function but it seems easy to miss other cases like that. 

Next a visibility filter would be nice otherwise will stick to small radius.   Not sure how to do this yet but I guess it would be to check the screen for this somehow on the grid cell.

Is is possible to force focus the df window back to front with focus while running a script from console?  Not sure this is a good idea for production but I keep having focus issues and would use this as a debug aide.   On a related note, moving the mouse to center of the df window would be useful for testing.  ( I will assume no on both counts but just asking)