Print

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

[Putnam]

for some reason, you feel compelled to engage in the question that isn't directed to you

maybe pay attention to the rest of the thread? Every question is replied to in this way by people who feel confident in answering it.

That is off topic to the question and the topic. We are not here to draw scenarios or to speculate on what will happen. That's an argument.

Your question was inherently speculative. "Are you worried/have you given any thought about the the Steam Workshop creating a walled garden and splitting the modding community?" is pure speculation, you drew that scenario, formulating it as a question doesn't change that fact, and you used specific examples in your own question, the exact same way the reply did, so telling other people that they aren't allowed to is either 1. bad faith argumentation or 2. you simply forgot what your original question was.

EDIT: And of course the question was already answered: the creator has no responsibility here. The creator should not have responsibility here, and never should when it comes to modding games.

[Meph]

About the mod community split: Since the only difference in the version is the art, the only mods that get split up would be those that heavily feature the new steam-version sprites.

Lets say you make a gunsmith and copy the forge graphics from Steam, add guns. Done. Legally, this can only be released on Steam. If you'd want the same mod for the free DF version, you either have to release it without graphics, make new graphics, or copy/paste together something from an existing graphic pack.

Tileset authors could make steam-only mods if they really wanted to, but I fail to see why that would be something you'd want. Less people would play your mod.

[Egan_BW]

Either not wanting to upload multiple places or just not knowing that there are other places for mods. It would be easy for a lot of mods to only be officially available on steam because the modder doesn't care to put it anywhere else.

Which would be a little annoying seeing as such mods would still be compatible with the non-steam version, but you can't download mods directly from steam without having the game installed there.

[Shonai_Dweller]

Either not wanting to upload multiple places or just not knowing that there are other places for mods. It would be easy for a lot of mods to only be officially available on steam because the modder doesn't care to put it anywhere else.

Which would be a little annoying seeing as such mods would still be compatible with the non-steam version, but you can't download mods directly from steam without having the game installed there.

But upon being informed of where the community actually is and the existence of the free game, it's trivial for a mod maker to say OK to allowing someone to copy those files over to DFFD (or even do it themselves).
Then the only barrier is people who actively don't want to share their mods outside of Steam, and presumably don't actually want people to play them and certainly don't care to have them discussed.
And...you know those mods probably aren't worth playing in the first place.

[Meph]

I don't think there will be many modders that will know the game only from Steam, not knowing about Bay12. Those people will of course exist, but they will all be new to the game. New players have problems understanding the game, I don't expect many mods popping out of nowhere suddenly. ^^

[Buttery_Mess]

I was out in the boat today and thought up a couple more questions...

Since the UI is getting increased mouse support, does this make a mobile version of dwarf fortress a possibility? The Steam Achievments code could also be wired into Google Play, which IIRC also has an achievements function.

Will there be any possibility of floating/dockable menus and submenus? Will you consider the ability to access menus without having to pause the game?

[PatrikLundell]

:
Will you consider the ability to access menus without having to pause the game?

That's a dangerous thing to do. You select something and issues an order, and while you do that, said something ceases to exist (dorf killed, workshop toppled...). In the best case nothing happens because the reference is recognized as being invalid; in the bad case the action is performed on the wrong target because the reference to the target now is to a different entity; and in the worst case the reference is a pointer to something that used to be the object but now has been reused for something else, causing the action to write "randomly" into it, causing corruption.
It's not impossible to handle, but requires care and extra code.

[therahedwig]

That's a dangerous thing to do. You select something and issues an order, and while you do that, said something ceases to exist (dorf killed, workshop toppled...).

Isn't the squad menu 'real time'(well, flowing time, more)? I know that took me by surprise the first time I used it.

[PatrikLundell]

I think the squad menu works in accelerated time, yes (there aren't many "real time" game that are real time, since most of them have 24 hours to take from seconds to 15 minutes, and virtually never 24 hours. In Fortress mode it's 12 seconds at 100 fps). It can be noted that the squad entity can't "die" (the members can, but not the squad itself), so that reference is reasonably safe to use for orders. With proper safeguards you can do it to perishable things as well, but it requires the implementation of those safeguards (and you can multi thread as well, with proper synchronization mechanisms, but that requires substantial additional efforts).

[Buttery_Mess]

Any memory address can be edited at any time without affecting the code. Once an address has been assigned it doesn't change whilst the game is running. That's why Dwarf Therapist works. You don't have to pause the game for that.

[Magistrum]

for some reason, you feel compelled to engage in the question that isn't directed to you

maybe pay attention to the rest of the thread? Every question is replied to in this way by people who feel confident in answering it.

He's new here, please go easy on him Putnam, he just doesn't know.

[Shonai_Dweller]

With the new graphical capabilities, you'll be bringing a lot of the functionality that TWBT strived to bring to the game to vanilla, which is great. However, one thing TWBT never managed was to allow a separate tileset for the world map.[BlatantSuggestion] Might that be something you have planned for the Steam release? [/BlatantSuggestion].

If not, I'll just get on over to the Suggestions forum.

[iceball3]

Hey Toady, you mentioned a potential concern of melanomas caused by sun exposure. I do think you know the whole sunblock thing already, but did you know that the scalp is rather sensetive to UV, regardless of hair coverage? A sun hat could be a pretty good call!

[PatrikLundell]

@Buttery_Mess:
Most of the time you can cross the train tracks without looking and not get hit by a train too...

As long as the entity whose data you modify isn't moved or removed, you can modify elements of it that are small enough (and suitably aligned) to be updated as indivisible operations without risk (assuming the elements in question are independent, and ignoring the multiple levels of cashing of modern processors). If data is split into multiple indivisible transactions you run the risk of the other process reading data that's partially the old one and partially the new one, which isn't particularly safe if one element is a pointer to an object and the other element specifies what type of object the pointer points to, for instance.

DF retains units in the units list after they've died, so it may be that their data structures are all retained as well until a new save is loaded (which DT detects), in which case modifying jobs on dead units may well be reasonably safe. Making the assumption that all data is safe to manipulate because some carefully selected ones are is rather risky.

Edit:
Response to Shonai_Dweller's next post:
The response to Buttery_Mess' entry did not attempt to comment on iceball3's post. However, unless you're able to travel in time, it's hard to apply sun screen and protective clothing to the children growing up to become Toady and Threetoe, as the main concern is the result of past sun exposure. And I have reason to believe the current versions of these persons do not rely on hair alone to protect their scalps (although the advice may well be a useful reminder for others).

[Shonai_Dweller]

As long as the entity whose data you modify isn't moved or removed, you can modify elements of it that are small enough (and suitably aligned) to be updated as indivisible operations without risk (assuming the elements in question are independent, and ignoring the multiple levels of cashing of modern processors). If data is split into multiple indivisible transactions you run the risk of the other process reading data that's partially the old one and partially the new one, which isn't particularly safe if one element is a pointer to an object and the other element specifies what type of object the pointer points to, for instance.

DF retains units in the units list after they've died, so it may be that their data structures are all retained as well until a new save is loaded (which DT detects), in which case modifying jobs on dead units may well be reasonably safe. Making the assumption that all data is safe to manipulate because some carefully selected ones are is rather risky.

Great points!
But...how does it relate to sun hats?