Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - hermes

Pages: 1 2 3 [4] 5 6 ... 61
46
Merge logic should not present the user with choices beyond the list of mods and load order - if the logic cannot produce a known correct result, the merge should be refused.  This protects users from broken raws; put another way it's the difference between a mod loader which does some merging and a mod merge tool.  Details on what happened could be written to a log file, but probably shouldn't be shown to all users - remember that the target audience is people who are still new to DF and would otherwise avoid mods.

But that's the point!  If any mod removes something from vanilla raws, any other mod, whether applied before or after, could clash with that removal and with a blind diff patch there is no way to guarantee no clash... so you have to refuse the merge.  The diff patch should spot where a mod wanted to edit that removed entry, but it would never detect where that removed entry was referenced somewhere else by another mod.

I went though the exact same thought processes before making my mod loader, and that's why I just went with file overwrite detection.  You either do that, or go all the way and build the data structures.  Half way just lands you in all kinds of problems.

47
I thought of something while I didn't have access to my machine.  There are two reasons why N-way merged files break.

Case 1: Mod A adds or deletes lines before mod B tries to change something.  Mod B's changes end up in the wrong place, which may or may not cause issues.

Case 2: Mod A and mod B try to change the same line.

....

This should ensure that changes land where the modder thinks they will based on a vanilla diff.  Won't ensure that the changes are compatible, but at least they won't be off in some other object.

Does that make sense to anyone other than me?

... Which is exactly why I'd go the route of Valdemar's stuff.  First flatten everything, then read/index all the objects/entities into structures, then do the diff patch generation on an object by object basis.  It's basically the same thing but with with the added bonus of the program being able to say explicitly what objects were deleted, what's been added and so on.  You have two levels of differences - the objects present difference, and the difference between equatable objects themselves.  The process to resolve conflicts becomes much more mechanical then, rather than holding hands up and saying, "well, it doesn't work and we don't know why".

In case 1 you'd know that the added lines of B would at least be in the correct object, and if the program was smart it could drop those lines in right after the correct preceding line.

In case 2 you'd know in what object the conflict arose and could prompt the user with relevant information.

This way would make this basic stuff easier, and open the door for more advanced stuff like making connections throughout the raws to entirely remove problem objects.  The two pass method Dirst suggests is essentially the same thing but done in a roundabout way.

The diff patch stuff is a good start and totally necessary, but IMO it'd be pointless to do this without going the route of interrogating the raws in a raw-language manner.  PE said he was adverse to an "advanced mod loader", which I understand... But I feel this way is the minimum, not an advanced feature.

48
Just a quick question... Valdemar's mod manager looks like it does the comparison in a better way by pulling out all the entities from the raws and comparing them on an individual basis... Since the code is already available, and this way would make resolving conflicts clearer and easier, why don't you guys use this instead of a text comparison that is, in computational terms, relatively meaningless?  I don't see the long term use of a diff patch.

49
Just want to chime in with a hope for this great project...  Please make the process of integrating/formatting mods into this system very very easy.  I feel that over the years the DFHack and Masterwork projects have basically turned modding into programming, taking away what made it accessible and fun in the beginning.  It's be a shame if there was yet another barrier to entry in the form of a standard which everyone had to learn and comply to. 

50
Donate button is a good idea I should do.

Launching other utilities... I've looked at before, and fiddled around with implementation but it's not something I can really get behind.  In part for the same reasons as the modding issue...

I saw your mod browser program (haven't tried it yet) and I think it's a great idea.  But the main problem with mods, and I think this stands for utilities as well, is the lack of a standardised format.  Mods are packed with different directory structures and often include multiple versions/options in one package. 

There are two ways to overcome this I think.  The first is for the community to agree upon a standardised header file which would identify the mod, creator, version number, directory structure and install options which the installer would parse.  This would probably require some auxiliary program or net code to have the modder fill out a form and generate the necessary file.

Secondly, which is probably better but more work, would be to raid DFFD for most of that information, which it mostly has, and then spend time developing algorithms that analyse the mod's file structure and try to install in a smart manner.  And hope that modders don't create labarynthine zip files.

On top of all that you have DFHack scripts and raw clashes and... It makes my head hurt thinking about it!  On second thought, you'd probably want a combination of the above two methods, and ignore mods on DFFD that don't comply to the format...?

That said, I use Mod Manager (I think) for Skyrim, and they have clearly done a great job of a complex install process linked to online resources.  It is possible.  But you'd need to spend a lot of time planning for every eventuality. 

51
DF General Discussion / Re: Future of the Fortress
« on: August 16, 2014, 03:21:19 am »
The Suggestions phase begins, woot!  I'm pretty excited to see what stuff Toady implements here, big or small, because even with this first batch there is stuff which I never read/thought about before but seems cool and would like to try in game.  "New Arrival" tag sounds really useful.

52
DF Modding / Re: k33n's Elves (16x16 character set) version 1.2
« on: August 15, 2014, 03:17:26 pm »
Spoiler: Elves hanging out (click to show/hide)

I think I might be an ASCII traitor and keep using these.  Something about just the character models on the ASCII tiles which works well.  Still love these elves, thanks!

53
I was kind of beginning to invest in a fortress, but Toady seems to really be on a bug-fixing streak and each release is getting more bombproof than the last.  I'm gonna wait for the streak to come to an end, where we'll have a diamond strength DF that'll never crash and never make a mistake in a decade of runtime.  Kind of like the programs NASA puts on satellites they fling out of the solar system.  The next one won't have the gold plate, just a screen and a keyboard running DF.  So, er, I'd wait if I were you.

54
Any particular objections to releasing the source?  There's a lot of discussion at the moment about a good way to add mods to something like a Starter Pack (including toggling them etc).  This seems to be both philosophically different and the best example we have!

I saw that discussion, and recalled that I offered the source to someone (dricus or fricy?) some months ago but they didn't follow up.  The offer is still open, but to be honest I think those guys are putting a whole lot more planning and careful thought into what they're doing and will probably come up with something much better!  But if they want to see what I did for mods or other stuff I'd be happy to show them.  (Main objection to releasing the whole source is it is spaghetti code I did in two weeks and was not planned out at all.)

edit - Oh and I forgot, did those guys look at Valdemar's mod manager?  It's in Python and the source code is linked.

Can you add an option for print mode?  Perhaps have an advanced settings tab [...] I'd prefer to have every init option in there, or at least an init editor, but whatever you can do is fine.
I agree with that.

Hehe, big requests!  The graphical display options... doable.  Adding other options also doable.  The main reason I haven't done that already is it is a slippery slope towards chucking everything in there.  I feel the important options are already there, SDL options aside, is there anything in particular you think is important?

I don't really see the need for having all options/a text editor when you can just open the file in notepad.  A button for that might be useful, though.

Making it look for "dfhack" instead of "df" on Linux would be a nice addition.

Sorry, Nopenope I don't quite follow this... you mean the DF OS recognition file?  It doesn't find your linux version of DF?  If you meant that you should be able to change it from the launcher's init file.  Or did you mean something else?

55
So Imma gonna have to update this for the new popcap system and probably add a couple of DF2014 mods.  If anyone cares to chime in, what kind of control would be good for the popcap?

The new system is, IMO, a bit ugh.  Basically there are two caps now; they both stop migrants, one doesn't stop births and the other does stop births.  There is also still the baby %age cap which works with both.  It just seems like too much control over the fort demographics, which I don't like.  I'm inclined to make the "Pop Cap" in the launcher just mean the immigration cap, and not stop births.  It isn't a problem to add controls for all the caps, but it seems a little obtuse and non-user friendly.  Any thoughts on this, lemme know.

Any other new init options that deserve launch controls?

56
DF Modding / Re: Wanderer's Friend [0.97b]: Now with elixirs.
« on: August 11, 2014, 11:07:07 am »
That's good to know.  Just been reading through the WF readme, and I would be inclined to cut the added animal materials and the fortress mode stuff and just focus on the adventurer interactions.  If those would work reasonably with stock animals and materials, that would be great.  And I have yet to look at butchering sentients, but taking trophies from kills has been something I've wanted to do properly for ages so... I might take a stab at this.

The pertinent section reads...

Quote from: Lofn
A more in-depth explanation of the material mod
-----------------------------------------------
With this mod, new materials are added via creature variations, resulting in a decrease in imaginary materials like 'worm fur', 'blue jay hide' and the like, which occur due to the standard material and tissue allocation tokens giving products to creatures that cannot actually be butchered.  Variations are also easier to modify and maintain than individual assignments, and faster to apply to new creatures.

So not using the Wanderer's Friend materials (which would be ideal as it is kind of a workaround in itself, and I like mods that change vanilla as little as possible) relies on 0.40.1+ butchering animals more properly.  Which according to the devlog...

Quote from: Toady
All jobs that affect body components (anything that uses bone, for example) will now carve away pieces of the body component, which'll leave a "partially butchered" wound type on the limbs etc. that were used in jobs if the skeleton is animated. Leather from skins is still not computed according to size, though -- that's a slightly more difficult problem since they use a custom product tag for tanning.

...Should be the case. .. ..... ... ?

57
DF Modding / Re: Wanderer's Friend [0.97b]: Now with elixirs.
« on: August 10, 2014, 08:13:00 pm »
Well Deon's mod looks cool, but it really isn't Wanderer's Friend at all.  I think there must (?!) be a lot of people looking for a pure WF update, so... erm... is one in the works?  I didn't realize that WF changed the creatures, so I guess this might be a bigger job than I thought, but perhaps all the changes required would be regular/uniform?  e.g. all the Reactions now need x, all the Creatures now need y, and so on.  I have no idea what these new things would be so I would only really do this if I HAD to look into it...  :'(

58
Has the sale of Twitch been officially announced/confirmed?  This could a way to drive down the sale price..??

59
Other Games / Persona 5
« on: August 06, 2014, 08:35:53 pm »

To be released in December/Winter (early?) this year 2015 on PS3 and PS4.  And probably coming to Vita sometime I imagine, but that's not announced yet.

2014/9/1 - New teaser trailer!
2014/9/1 - Director posts a message on the Persona Channel

Dude is just thanking a lot of people a lot of times.

2015/2/4 - The Persona channel is having some "live" streaming events on NicoNico TV.  Kuma (Teddy) introduced them at 1pm in a short message that was pretty cute.  The "Main Programme" starts at 18:25 on Thurs 5th Japan time.  Then at around 9pm there is some mystery programme.  I have no idea, but I guess there might be a Persona 5 announcement coming.   :-\  The 2 minute Kuma pre-announcement was weird, but whatever they show will be better for having Kuma involved.
2015/2/6 - It was!  New promo video with in-game footage on the Persona 5 site.  There is a lot of info in there, most notably I guess was the use of real place names that puts the setting in Tokyo.  The style is very Cat's Eye, IMO, which is great because I love that.  Also some references to Persona 2??  (Trying to get into that game right now).  There's another message from Hashino where he talks about the themes being a mix of "Juvenile School" and "Picaresque Romance" (which also sounds awesome) and how the party members might have bad manners and find themselves in situations where they are being chased.  The graphics look stylized enough that a Vita port might be possible...??  No release date yet.

60
DF General Discussion / Re: Future of the Fortress
« on: August 01, 2014, 12:06:07 am »
Quote from: Trophy Log
Reactions will also trim away pieces of bodies properly. All jobs that affect body components (anything that uses bone, for example) will now carve away pieces of the body component, which'll leave a "partially butchered" wound type on the limbs etc. that were used in jobs if the skeleton is animated. Leather from skins is still not computed according to size, though -- that's a slightly more difficult problem since they use a custom product tag for tanning.

Woah woah woah... does this mean scalping is now possible?  Trophy taking?

Pages: 1 2 3 [4] 5 6 ... 61