Bay 12 Games Forum

Oh, is that the name for when you put a simple loop of track across the middle of your fortress and power one end of it to get the cart to go around and around?

I did that experimenting with arcing airborne physics -- buncha rollers, a dip down and ramp back up... would probably have worked better with a ramp up from the ground level and no dip, but the real issue was the way my dwarves could not be made not to walk across the deathline.

To be honest, I have yet to get the hang of using minecarts to actually make hauling more efficient -- seems like you'd still need to have everything in more or less a finite number of places, each with certain sorting applied, and my biggest hauling problem was the time it takes to gather everything into one place in the first place. *shrug* It seems like they might help for forts with well organized production cycles though, I'm just not that good at being well organized about it.

Anyway, I think I prefer to call the cyclotron the "Blameless, Unbiased, Random Dedwarfinator", or BURD for short.

A question: is the actual parsing of Toady's raw files just something he came up with, or is there some library out there he's using or building off of?

I have a utility I've been working on (er, was working on earlier this year...) that needs something similar, and I just read a thread here about making a better raw editting tool (better inasmuch as it translates the options the raws can have into a user interface form instead of just helping you browse and see syntax while you edit the text yourself)...

...And I thought, if this raw thing happened to have a certain well-defined way to parse it, I'm sure that would help people like us handle them -- and build our own configurations using the same syntax, so DF modders who aren't as used to XML as they are to the raws will find our configurations easy to work with. In either case it would make it easier for us to make the parsing safe and correct.

So, I looked through the thread a bit and saw that this is indeed open source, and I was able to make some modifications and compile them. See below for DFFD links.

---1---

First off, a guide to compiling modifications without being able to build the whole ant thingy. Because...

Er, did that work? If not, hard link: http://memegenerator.net/instance/32409495

Go to build.xml in the source. Find the "classpath" line that has something like "./lib/jl1.0.1.jar;./lib/freetts-1.2/freetts.jar;./lib/commons-codec-1.4/commons-codec-1.4.jar;./lib/autoUpdater.jar;./lib/jansi-1.8.jar". Copy this.

Copy the folder soundsense/lib to [source folder]/lib. If you want, copy the existing soundSense.jar to it if you don't want to recompile all the parts but only the modified ones.

Open the command prompt. Go to the source folder. Enter (pasting [try right-click...] the path from build.xml):
>javac -classpath "./lib/jl1.0.1.jar;./lib/freetts-1.2/freetts.jar;./lib/commons-codec-1.4/commons-codec-1.4.jar;./lib/autoUpdater.jar;./lib/jansi-1.8.jar;[./lib/soundSense.jar]" ./src/cz/zweistein/df/soundsense/[paths/files you wish to compile, in order of dependency]"

If this doesn't work, you need to have a java compiler properly installed -- it's been so long since I set that up that I couldn't tell you how to do it... last I recall Java versions and compiler setup was a scarey place I don't feel like revisiting, but if all else fails and you're not already part of some Java project that would connect you with expertise in the matter, you can always uninstall everything Java you have and install the latest JDK and it ought to wind up right. (Sorry I can't be more helpful there.)

Anyway, repeat this last step as necessary to compile all changed parts, keeping in mind to do the ones that are dependent on others only after the ones on which they depend.

Open up soundSense.jar -- for those of you who don't know, a jar is just a zip by another name! Remove the existing class files for the part(s) you modified. Copy in the parts you just compiled in their place(s).

Make sure this modified jar gets back in the soundsense folder and you're good to go!!

I would recommend putting such instructions on the wiki. Possibly along with instructions in compiling the whole thing properly using ant or whatever so that it gets the build designation updated. Might want to put instructions in that as to how to tag it as a modified branch. I manually opened my jar and changed the version.properties inside it to list it as release 36-mod, increment the build number and update the date/time built.

---2---

While we're talking about that, more stuff that should go on the wiki:

The playing of a random seasonal music upon fortress load is not hardcoded! It's under system, and is triggered by fortress loading log messages. The start of a new fortress happens to trigger the same list of stuff as Spring, nicely. 8^) Furthermore, you can look through the list of seasonal messages, find the one for the current season, click it, and click the play button at the bottom, and Soundsense will behave correctly for that season for the remainder of the season! Sure it's a manual trigger, but it's handy to know.

(I had the idea to add some functionality to allow things like fortress loading to somehow redirect to a random one of the seasons. While it was feasible, it turned out to be more trouble than such a feature is worth. Just copy-paste all the seasonal listings into the fortress loading sound when you're creating/updating a pack, at least for now.)

---3---

I have uploaded some modifications to the DFFD [see below], both the source and the updated jar file.

One thing I did was allow an xml file to have an includeDirectory tag with a "path" attribute specifying another pack or part of another pack to include in this one. Basically this allows you to mix and match pack parts much more easily: you can leave the official pack alone (perhaps just move it to soundsense/packs/OfficialPack) and build your own, entirely separate packs and pack pieces, then you can point to a particular directory that just contains a list of pack pieces to combine!

Example of new format: let's say I have the official pack moved to soundsense/packs/OfficialPack, and my current pack path pointed at ./packs/FireflyPlusActionLines/, then...
soundsense/packs/FireflyPlusActionLines/combine.xml could contain:
<includeDirectory path="./packs/Firefly/"/>
<includeDirectory path="./packs/ActionLines"/>

This brings me to another point: I made the directory loading add a / if there is niether / nor \ at the end of it. So if you forget to end in / or \, no big deal!

Here's another example: let's say that the official pack separated seasons into seasons/music and seasons/announcements; then, I could have...
soundsense/packs/Bare/include.xml contain:
<includeDirectory path="./packs/OfficialPack/seasons/music/"/>
<includeDirectory path="./packs/OfficialPack/weather/"/>
[and maybe a few things like discovering vast caverns underground]
...and soundsense/BarePlusActionLines/combine.xml contain:
<includeDirectory path="./packs/Bare/"/>
<includeDirectory path="./packs/ActionLines/"/>

(By the way, I imagine this "action lines" custom pack would be made of clips from famous movies... but frankly, I'd like to hear Rainseeker record a martial trance announcement, "I came t' pulverise elves wi' their own pointy ears, an' to eat opposum cheese... Ach, an' I be all outta opposum cheese!")

I do recommend the official pack separate seasonal announcements and music into separate directories so things like this can be done without regard to threshold settings -- I might want to have my own seasonal announcements in ActionLines with normal threshold settings even if the seasonal announcements weren't on the same priority as the weather (which they are by default, so...).

Anyway, the point here is that you can mix and match packs and pack pieces without having to extensively modify the sound listing xmls in any given pack, especially the default.

I also made it prevent infinite loops by tracking the absolute paths of directories it's parsed and refusing to parse the same one twice. This is helpful even without the inclusion of packs and pack parts because a devious OS user could achieve similar effect with symbolic links (but this is difficult to do and comes with more problems/limitations, so). It's just a good safety feature.

ETA: Now in version 2.0 you can also use <includeListing filePathAndName="pathto/sounds.xml"/> if you don't want to deal with separating everything into directories; would still require, say, seasonal music and announcements be separated into two .xml files, but not the whole directory separated. One thing I'm using this for is to include adventurer/enviroment.xml without the rest of the adventure mode sounds.

---4---

Of course, what's mixing and matching packs good for unless you can easily switch which one or which combination you're playing with? So now, the configuration xml's soundpacks tag, instead of expecting "path", expects "defaultPath" and "allowOverride". Set allowOverride to false to always use the defaultPath. Set it to true and Soundsense will ask you to confirm or change the path when it loads or reloads. Handy, no?

ETA: I just noticed that it was still saying "Done loading [configuration directory]..." rather than "Done loading [chosen directory]..." if you selected a different directory than the default. I changed configuration.getSoundpacksPath() in that line to soundsXML.toString() and uploaded this last tweak to the DFFD file. This probably doesn't matter in the long run unless you're zwei and are planning on putting the allow-user-to-choose-pack-directory-on-load/reload feature into the... uh, "main branch"? ;^)


---5---

It's not source code, but I also fixed Achievements.xml to use the mining message log pattern for the mineral deposit achievements (had been using the cat butchering log pattern!), and fixed the two cmds to run Achievements and MissingMessages so they'd include ./lib/jansi-1.8.jar and would actually work. ;^)


---DFFD---

With JAR.
Without JAR.


---FIX FOR MUSIC NOT PLAYING---

This may or may not solve all everyone's music not playing issues, but it solved mine...

Go to http://www.javazoom.net/mp3spi/sources.html

Get version 1.9.5 of mp3spi.

Open up the zip.

Copy mp3spi1.9.5 to soundsense/lib/MP3SPI and delete mp3spi1.9.4 from that folder.

Go to "lib" in the zip.

Copy jl1.0.1 to soundsense/lib/MP3SPI and delete jl1.0 from that folder.

If you can figure out how to recompile the exe to use these, do so. I can't. But read on!

Edit soundSense.cmd: where it points classpath to mp3spi1.9.4, change that to mp3spi1.9.5, and where it points to jl1.0, change to jl1.0.1. You can now run Soundsense using soundSense.cmd and have everything work! I have added the updated soundSense.cmd to the zip downloads on DFFD, but it won't do you any good unless you replace the jars from http://www.javazoom.net/mp3spi/sources.html

This upgrade should probably be incorporated into the main release at some point, obviously.

Wild question: I see you have the source bundled with the download... I have a few ideas for changes to improve the ability of a user to set up his own packs and switch between them and/or mix and match parts without having to edit the xml trigger/sound/music listings themselves, to improve the handling of the unknown starting season thing, and possibly do something about adventure mode. Would you be interested in a detailed but concise report of suggested modifications/additions to the code based on my reading the source and these ideas for improvements? (And/or actual modified code, but the reliability of that would depend on whether I can get it to compile, which I might not figure out even using the code as-is. [Rant about problems I've had trying to compile Java projects redacted.])


ETA: Turns out most of what I would like for the whole seasonal thing is there, the wiki just doesn't say much about it -- if you want I can make suggestions about that too. ;^) I did figure out how to make another change or two I think would make it way easier to throw together custom sound packs and mix and match them, possibly including parts of the official pack, without meddling with the pack itself. If it's alright with you I can post the changed files on the DFFD along with explanations and related suggestions... I haven't been able to compile so far but I _think_ that's more not being set up properly for it than the changes themselves.

I haven't had a chance to experiment with Adventure Mode yet (or, for that matter, to do all the experimenting I'd like to do with regard to music relating to game status in Fortress Mode), but I may or may not have any particular suggestions once I have (it may come down to ideas for arranging the pack listings more than anything else).

Is there a way to set the direction of a ramp -- as viewed by probe? Tiletypes doesn't seem to support it. I can't find the lua stuff to read/write that data for a tile, though I'm sure it must be in there and I've been using this technique to explore (pro tip to anyone new to the lua options exposed through dfhack).

I somehow messed up a river ramp -- or at least, I think I did -- and am trying to use dfhack to fix it. So far I've got it to be just like the other river ramps again except for the direction. First time using dfhack extensively -- not so much that I think "hacking" a game with no competitors and no high scores is inherently wrong, but I tend to prefer the vanilla experience and don't really want to use hacks to get stuff done unless it's something I A) kinda need and B) don't have another way to accomplish (for example, I've used drybuckets or whatever it was back when the bucket water bug plagued my fortresses, and I might apply clean judiciously if I felt it mattered -- is there a way to clean the map, but only the tile under the cursor?)... not that I mind if anyone else likes to, obviously... Anyway, this just happens to be one such thing, correcting a mistake that affects something that game doesn't give you much way to revert (unlike, well, a lot of the stuff in DF that can be reverted or at least rerandomized). But it's the first time I've really wanted to do that, so I'm a little flummoxed how to get all the details.

It would be nice, by the way, to have a version of tiletypes/probe that set tiletypes to match the results of a probe. I'd code it myself if I knew how...

Oh, if only I had embarked in a freezing biome where it wouldn't flow in the first place unless I heated it, that would be a pretty nifty thing to be able to control... set up a nice end pool outdoors but heated by magma, but with a release to shut off the heat...

If I have a setup like this side view...

~ = water
# = natural wall
X = water + hypothetical location of enemy when this system is unleashed

        ~~
 #######~#
 #######~#
 #~~~###~#
~~~#~~X~~#
##########

...so the water above is forced by pressure over the hump and out in the end, will enemies crawling along the bottom inside at X be pushed over the hump and out, or get stuck there under the water but not washed out? Does it make a difference whether there are up ramps on either side of the hump?

It's what's in the side and top-down diagrams...

I'm still not sure what's up, but I'm going to savescum and see if it happens again -- if so I can upload a save and see if anyone can figure it out.


ETA: Not reproducible. Still no idea what happened before, but it seems to be fine now. *shrug* Let's hear it for savescumming! (Well, in limited circumstances like getting something like this to work, anyway. Not so much for forcing the RNG to favor you.)

Leaving the thread unlocked in case anybody has had this happen to them and has a decent idea what the cause was.