Print

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

Me

16 (22.9%)

Me!

54 (77.1%)

Total Members Voted: 69

[Putnam]

Hugo: they dissolved into smoke because slayrace uses two methods to kill:

1. Remove all the unit's blood.

2. If that fails due to unit having no blood, set the unit's vanish_countdown (usually used for bogeymen) to 2 so that it vanishes in 2 ticks.

[WillowLuman]

While fun, what does that test?

They were all hostile. I did it in the wrong order, though. I should kill everyone first, then force invasion, so there's no risk of loyalty cascade. They didn't even encounter the ones within the monastery before they attacked themselves, but the cascade was still probably the result of the already present units somehow.

They still haven't appeared in the non-hack game I'm running in the other window. Can't force them either unless there's already a unit of their civ on the map.

What would a POISON_IMMUNE creature class be good for?  Supernatural Creatures, such as angels and demons, for one.

It's redundant. If you don't want a poison to affect those, just give it [SYN_IMMUNE_CLASS:ANGEL], or [SYN_IMMUNE_CLASS:SPIRIT].

[Halfling]

If the goal is to see whether they come in a hostile fashion on their own, forcing a siege would probably be counterproductive anyway.

There's also class DEMON used by exactly two creatures: fiends and wisps of rage at this time.

[Zanzetkuken The Great]

What would a POISON_IMMUNE creature class be good for?  Supernatural Creatures, such as angels and demons, for one.

It's redundant. If you don't want a poison to affect those, just give it [SYN_IMMUNE_CLASS:ANGEL], or [SYN_IMMUNE_CLASS:SPIRIT].

That could be done, but there is a problem, what if someone wants to create something with an advanced enough immune system that nothing affects it.  SPIRIT wouldn't really make sense on the creature, but POISON_IMMUNE does.

[WillowLuman]

While I wait for them to show up on their own (if they even do), I want to see just how their invaders would behave.

@Zanz: except you'd have to go back and add it to every single syndrome. If you want something completely unpoisonable, make it [CREATURE_CLASS:INORGANIC]. Why classify them as organic if they're not affected by things that only affect organics?

[Halfling]

I think you may have to wait a long time. I was wondering about whether you've reached their progress triggers and it turns out that if you're using the same Putnam raws as I just re-downloaded to make sure, they don't actually have any in these.

[Zanzetkuken The Great]

@Zanz: except you'd have to go back and add it to every single syndrome. If you want something completely unpoisonable, make it [CREATURE_CLASS:INORGANIC]. Why classify them as organic if they're not affected by things that only affect organics?

Being immune to poison does not equal inorganic.

[WillowLuman]

But as the only purpose of the classes if for more precise syndromes anyway, INORGANIC just makes them un-targetable by any organic syndrome.

[vyznev]

OK, I think it's time to let the rest of you guys know about the GitHub repository I just finished setting up for this project at https://github.com/vyznev/dfscratch

Basically, I've imported all the .zip (and .rar) archives listed in the first post (except the graphics packs, which I still need to deal with) into the repository, and I've volunteered to try and keep it up to date as new patches are released.  I've talked with Halfling, and he's basically said he'd be OK with using this repo as the official place for publishing our raws from now on, obviously assuming that it works and meets our needs.

Anyway, all the raws are there, and I've written some instructions for:

• downloading and installing the latest release for playtesting and
• contributing patches and new features.

The way all this is set up, no-one (except me) needs to use Git -- to get your code into the repo, just send it to me somehow (post it here, put it on DFFD and post a link, etc.) and I'll take care of merging it in (after getting approval from the current turn holder, if needed, of course).  You might want to give Git a try, though: it's quite useful for this kind of collaborative development, once you get the hang of it.

Ps. If you notice any problem with the Git repo or have trouble getting it to work, please let me know.  Also feel free to ask if you have any questions; if this post seems kind of vague, it's because I've tried to put all the important stuff on the GitHub project wiki.  (Yes, we now have yet another wiki. )  Oh, and if you already know how to use Git and would like direct push access to the repo, just ask -- I'd be happy to have other people to help with maintaining it.

Pps. Stuff I'd still like to do:

• A lot of the old releases still have bugs that have been fixed in the later releases.  It'd be nice to backport those fixes to the release branches.
• I'd like to make a separate branch (or branches) for sackhead's Obsidian graphics.  I've actually got them imported into my local Git repo, but they're still kind of a mess, with a whole bunch of vanilla stuff mixed in. I need to untangle that stuff somehow, unless someone (sackhead?) could send me a "bare-bones" version with only the new/modified files.
• The data file decoding/encoding scripts I posted earlier should be added to Git.  In fact, it might be nice to store plain-text versions of all the compressed data files, and have a script to regenerate the compressed versions from those as needed.
• I've also been thinking of trying to write a script to run some basic consistency checks for DF raws, both for basic stuff like misspelled tags or duplicate raws, but especially for anything that DF itself doesn't always report in the error log.  That's going to take some work, but it ought to make merging in changes a lot easier and more reliable.

[WillowLuman]

Why bother fixing previous releases?

[vyznev]

Also (and I'll make this a separate post because it's completely unrelated to the Git stuff), my personal opinion on these recent arguments about creature classes and such is that all the trouble could be avoided if we just agreed to add new classes if and when they're needed.

Basically, my proposal would be that:

• We should avoid adding any [CREATURE_CLASS] or similar tokens unless we're actually going to use them.
• Adding new [CREATURE_CLASS] tokens to existing creatures for use in targeting new syndromes should be explicitly allowed.

OK, I guess I was wrong about this being completely unrelated to Git, because the thing is that using a proper version tracker like Git lets us do this cleanly: when you submit your new syndrome raws, just submit the necessary changes to existing creatures too, so that they can be merged into the repo in a single commit.

This does require that, if you're not submitting your changes via Git (or otherwise as diffs), you should let me (or whoever's maintaining the repo) know which version your raws are based on, so that we can easily merge in only the changes you intended to make.  Of course, I'm going to try to review and test any commits anyway before pushing them to GitHub, and I'll hopefully catch any accidental regressions that way, but it's still better to make sure they don't happen in the first place.

[Gnorm]

I'm not too keen on fixing the bugs of previous versions. Little quirks and glitches are what makes occasionally revisiting past versions of games fun.

[kero42]

I'm not too keen on fixing the bugs of previous versions. Little quirks and glitches are what makes occasionally revisiting past versions of games fun.

Seconded.

[vyznev]

Why bother fixing previous releases?

Somebody might want to try playing them, too.  Or I suppose somebody might want to fork them and try taking them in some different direction.  Or maybe not, but it could happen.

At least I'd say that's true for Halfling's original "version 0" minimal raws, which really do play quite differently to the later, more diverse versions, and which also make a nice potential starting point for other mods.  Certainly I think those at least should have any applicable bugfixes backported to them (and I think they actually pretty much do have that).  The other versions, I suppose, aren't that critical -- as Gnorm notes, the glitches might be considered a valid "historical" element.

[Poldon]

I seem to have missed much of the topic while it lasted, but I would be in support of very powerful, non-aggressive Adherents because that's a cool concept that I've not seen before. As long as it is confirmed that they do not attack Lizardmen or other future races, I think Hugo has put a lot of effort into them and also tried very hard to make them rare and work.


On the bugfixing old versions, I think only some bugs should be fixed. Say someone wants to come and play each iteration as it was made, but can't because several major bugs render a couple of iterations difficult or impossible to play well. I think they should be made playable and then maybe ignore most minor bugs.