Print

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

[milo christiansen]

Yup, that, change-build-menu, and if-entity.

[lethosor]

Here's alpha2 (finally). Sorry for the many delays there.

Ruby should work everywhere now! (At least in theory - hopefully scripts work, but we haven't tested all of them, so please report anything you find.)

[jecowa]

Sorry for the many delays there.

It's okay. But if you keep it up, we'll dock your pay. :p

It must take lots of time to maintain this, especially with the last two updates. Hopefully toady won't ever have to double the bits or switch compilers for at least another ten years.

[PeridexisErrant]

How would I go about submitting scripts for inclusion in DFHack? What repository should I use? (I assume the process is fork>add script>submit pull request)

Don't forget to document it!  Check other scripts for examples, and read the documentation on how to do documentation (yo, I heard you like...)

[Warmist]

Can somebody help with html side of things (e.g fancy javascript and stuff like that)? I've made a way to play df multiplayer-ish: server builds the fort and clients can see what their dwarf does and limits its burrows and labors.
However my html is rusty and i'm not very interested in improving it so it currently looks like this:

Spoiler (click to show/hide)

Also (almost)everything is in lua so it's easy to change

also: script - here
plugin dll from WINx64 this archive here

Edit: you can try it here: http://dwarffort.duckdns.org

[necrotic]

That seems outside of the scope of this thread. You may be able to get some help if you start a fresh thread for it specifically, and maybe with some cleanup such that the HTML isn't generated in the Python directly.

[lethosor]

It's a DFHack-based project. (Also, that's Lua, not Python.)

This was discussed on IRC some, but in case I didn't mention it there, I'm interested in helping with it (to the extent that I can, being busy IRL and all).

[Wegwerf]

What are we missing for a full release of dfhack for the 64bit version? How can I help developing or researching memory layouts etc? I searched for answers on the forum for an hour, but could not find a good starting point. Could someone please provide one? Sorry about the openness of my question. If someone has written a guide for this then it is well-hidden. I would really like to start contributing

[Bumber]

What are we missing for a full release of dfhack for the 64bit version? How can I help developing or researching memory layouts etc? I searched for answers on the forum for an hour, but could not find a good starting point. Could someone please provide one? Sorry about the openness of my question. If someone has written a guide for this then it is well-hidden. I would really like to start contributing

http://dfhack.readthedocs.io/en/stable/library/xml/how-to-update.html

You should probably practice on an old 32-bit version (with known layouts) before attempting 64-bit.

[lethosor]

That document pretty much just covers globals. Most of the globals (except a few debug flags, I think) are already located.

To answer the original question, we need to check most tools and make sure they don't crash. It's also helpful to explore structure layouts (e.g. with gui/gm-editor) and make sure that doesn't crash either. Also, there are a couple other things to fix, like 64-bit Stonesense (which is mainly just missing allegro libraries).

Part of the delay is due to a lack of time spent testing. Out of the 247 people that have downloaded the 64-bit Windows build, I've seen exactly one report of a crash that occurs with the majority of Ruby scripts (exterminate, etc.). If only one person bothered to report an obvious crash like that, I'm not entirely confident in that build's overall stability.

[Wegwerf]

Oh boy, that guide was basically in front of me the whole time? Thanks for showing me. Is this the right thread to ask questions about the process?

[lethosor]

Sure, you can ask here. Or on IRC, if you prefer that.

Like I mentioned, though, that page is mostly about globals, which we already have done. The bigger issue now is checking various structures and making sure they're still valid (by poking around in the lua interpreter, in gui/gm-editor, etc.).

[PeridexisErrant]

Part of the delay is due to a lack of time spent testing. Out of the 247 people that have downloaded the 64-bit Windows build, I've seen exactly one report of a crash that occurs with the majority of Ruby scripts (exterminate, etc.). If only one person bothered to report an obvious crash like that, I'm not entirely confident in that build's overall stability.

Okay, it sounds like we really need some automated testing.  I'm thinking that for a start, just trying to run all of the commands in a reasonably sensible context (eg correct game mode) and reporting any crashes would be great.  This will still take a fair bit of work, including maybe a script to navigate DF menus, but the payoff should be worth it.

More complicated stuff can come later.  I'd like command arguments, better context awareness, basic fuzzing, output checking, and so on... but all of that can be built on a basic "run all the commands and see what happens".

This might be my next project   

[Rose]

That document pretty much just covers globals. Most of the globals (except a few debug flags, I think) are already located.

To answer the original question, we need to check most tools and make sure they don't crash. It's also helpful to explore structure layouts (e.g. with gui/gm-editor) and make sure that doesn't crash either. Also, there are a couple other things to fix, like 64-bit Stonesense (which is mainly just missing allegro libraries).

Part of the delay is due to a lack of time spent testing. Out of the 247 people that have downloaded the 64-bit Windows build, I've seen exactly one report of a crash that occurs with the majority of Ruby scripts (exterminate, etc.). If only one person bothered to report an obvious crash like that, I'm not entirely confident in that build's overall stability.

Stonesense is already updated on windows, for both versions.

If nobody else can do it, I can try to update the Linux build process, but it's a last resort because I'd have to set up a dev environment first.

[lethosor]

Oh, right. 64-bit OS X needs to be fixed too. I'll have to look into building allegro again, I guess.

Okay, it sounds like we really need some automated testing.  I'm thinking that for a start, just trying to run all of the commands in a reasonably sensible context (eg correct game mode) and reporting any crashes would be great.  This will still take a fair bit of work, including maybe a script to navigate DF menus, but the payoff should be worth it.

More complicated stuff can come later.  I'd like command arguments, better context awareness, basic fuzzing, output checking, and so on... but all of that can be built on a basic "run all the commands and see what happens".

This might be my next project   

Yeah, testing is something I've wanted to do. I looked at unit tests recently, although those wouldn't be as useful for the DF-related issues. I have a script that walks through all of the structures (well, mostly), which crashes when something is misaligned badly enough, so that might be a decent place to start. Besides that, actual tests that run in DF would have a couple things to sort out (nothing impossible, though):
- Needing to start DF (this takes time, although it might be fast on Travis)
- Needing to restart DF if a test crashes DF (but not restarting unnecessarily, to save time)
- Needing to restart DF (or abort and reload the current game?) if a test does something difficult to reverse (3dveins, exterminate, etc.). Hopefully this isn't necessary often, though.

In short, it could be slow, but it's definitely something I want to look into.