Print

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

[Dirst]

Hi, I'm having a hard time jamming my mod into the Mods tab of the launcher.  (This is all happening on the Windows version of Starter Pack r16, if that makes a difference.)

I know that a raw/graphics or stonesense folder is not supported directly, so I was going to instruct players to fish those out and drop them onto the root DF folder.  Works for Stonesense assets, but the graphics folder gets nuked when installing the mod.

Neither the Pre-merge Graphics button nor the Extract Installed button seems to do anything, so I'm not sure how to protect the two helpless little sprites that come packed with the mod.  Even dropping them onto the 40_24 baseline doesn't help.

I thought I'd be clever and drop the graphics into their own graphics pack, hoping you can instruct the pack to load two different graphics packs (there are no collisions, so order wouldn't matter).  I can't make my mini pack appear on the Graphics tab at all 

Dropping them into an existing graphics pack works, but that seems counter to the LNP's purpose of making this stuff modular.

Hopefully you can look at this and see my glaringly obvious error, and everyone will be happy

[PeridexisErrant]

Hmmm.  I've just gone through the merging code to ensure it's as I remember - and it should indeed handle any graphics or stonesense files under /raw, including images.

Can you post the whole mod to DFFD?  Ideally I could look at your development format, whatever you've tried to get it recognised, and maybe an installed version.

[Dirst]

Hmmm.  I've just gone through the merging code to ensure it's as I remember - and it should indeed handle any graphics or stonesense files under /raw, including images.

Can you post the whole mod to DFFD?  Ideally I could look at your development format, whatever you've tried to get it recognised, and maybe an installed version.

The mod in question is the one in my signature, and the reason I thought images were not allowed is because (1) potentially out-of-date documentation at the repository says they aren't supported and (2) I sometimes saw it fail at graphics_tesb_creatures.txt in the stderr file.  Being able to manage creature graphics on the Mods tab would simplify things a lot.

Stonesense assets aren't under raw, so they will require some special handling no matter what.  They could be treated like speech files (a raw-sibling folder that gets moved as well), any Stonesense assets in a mod are guaranteed to collide with at least one file.  The author can't make a visible change without overwriting at least one image and/or index file.

Stonesense essentially ignores unused assets, so for all practical purposes a one-way import ought to work just fine.  But I can come up with an idea where that would cause problems (a mod that puts beards on female dwarves).

[darkflagrance]

I just wanted to say that I'm also having problems installing the Fortress Defense Mod linked in my signature using the merge feature of PyLNP. Do I need to create an "objects" folder inside the "raw" folder as well?

Edit: I understand, thanks!

[Dirst]

I just wanted to say that I'm also having problems installing the Fortress Defense Mod linked in my signature using the merge feature of PyLNP. Do I need to create an "objects" folder inside the "raw" folder as well?

Yes, it should reproduce the structure of the raw file, though you omit any files that are unchanged from vanilla.  If an entire folder is unchanged, you can omit that, too.  Cade in point you can't merge creature graphics anyway so leave out the graphics folder.

[PeridexisErrant]

I just wanted to say that I'm also having problems installing the Fortress Defense Mod linked in my signature using the merge feature of PyLNP. Do I need to create an "objects" folder inside the "raw" folder as well?

The best way to think of it is that if you copied the mod files over a vanilla install of DF, that would install your mod.  So you need the same folder structure, filenames, etc.  Any files you want to delete should still exist, but empty.

Just putting an installed copy in place and using the simplify mods button might be easier.

[Zanzetkuken The Great]

Outside of having to mirror the raw file structure, is there anything else required for the mod merge function to work?  I keep getting 'no mods were merged to install' despite seeing the folder the mod is within in the merged section of the mods tab.

[Pidgeot]

Outside of having to mirror the raw file structure, is there anything else required for the mod merge function to work?  I keep getting 'no mods were merged to install' despite seeing the folder the mod is within in the merged section of the mods tab.

Try starting PyLNP from the command line with the -d parameter, attempt the merge, and then check the log files. It should provide a bit more info on what went wrong.

[Pidgeot]

So, since we're expecting a DF release in a couple of days, and I still don't have access to my main PC, here's what's going to happen.

Once the next DF release happens, I will be downloading it and checking it against 0.40.24 to see if any changes are required for the new DF.

If this is the case, you can expect PyLNP 0.10c very shortly after the DF release - hopefully within 24 hours.

Pack maintainers, take note: If 0.10c happens, I will only be able to provide Windows builds. Linux and OS X packs will need to prepare their own builds.

I should be getting my PC back in January, and if all goes well, the *next* PyLNP release - currently expected to be 0.11 - should be ready around early February. No guarantees, of course, but that's the target.

[lethosor]

I can try to build on OS X and Linux, although I can't guarantee that the builds will work on the same machines yours do.

[Pidgeot]

I can try to build on OS X and Linux, although I can't guarantee that the builds will work on the same machines yours do.

Much appreciated Any build should still be better than no build.

Not sure which Linux builds you'll be able to do, but 32-bit Linux is most likely to cause problems (my builds only need glibc 2.3, which required quite a bit of tweaking to achieve), but hopefully most of the people who need that can still get by with source code. 64-bit Linux and OS X should hopefully not cause too much trouble.

I might also do a "proper" set of builds when my PC gets back to me, in case people need them.

[lethosor]

Oh, I actually only have a 32-bit Linux environment set up at the moment (I may have an old 64-bit Linux VM lying around, but it would take more effort to set up). Has anyone tried running a 32-bit launcher build on 64-bit Linux, out of curiosity?
I can definitely do an OS X build, although my main concern is that compiled libraries like Pillow won't be compatible with older systems. I could recompile them and play around with compiler flags, I suppose.

[Pidgeot]

It *ought* to work (32-bit launcher on 64-bit Linux), since you need 32-bit support for DF anyway, but I provide both anyway. Of course, that's no longer going to be the case once 64-bit DF is ready, but I strongly doubt we're getting that now, so it's *probably* fine with just x86.

Which OS X version are you using? I think fricy might have some older versions - assuming he's willing to share, of course.

[fricy]

I use my 10.7 system for this stuff, python 2.7 is compiled with a modified brew formula to target 10.6. However pillow/ttk support is problematic, I could never solve png support in the launcher: The logo shows up on 10.7 and I assume on 10.6 as well, but never past 10.8+: neither pip installed pillow, nor brew installed pillow works. Same problem Pidgeot's release. Minor problem for now, (until preview is implemented) but I'm willing to give lethosor a chance.

And Xposting this for posterity:
//Peridexiserrant: The legends processor script has a trouble with recognizing filenames, when the save game folder is not the default. Eg: region2 works ok, but region2-mod won't play nicely. I assume this means there's a similar problem with seasonal saves as well.

+Feature idea: Currently the graphics/customize tab shows both GRAPHIC_FONT and FONT all the time. This is good when twbt rendering is used, buth when the rendering mode is set to standard/2D it would be better if only one entry window was shown for selecting tilesets.

+Minor bug report, mainly for PerX: The 'installed_raws' text genererates the installed tileset/pack configuration from the directory name, and not from the manifest name, and only accepts directories with the exact same filename. This will cause silent save update failures, like when you update Gemset_1.3 to Gemset_1.4. Some flexibility'd be good in the future. For now my advice is to stick to the directory name, and not to use version numbers in folders when we restart the release cycle for df4?.01.

[Pidgeot]

The new init fields are:

[VISITOR_CAP:100]
[INVASION_SOLDIER_CAP:120]
[INVASION_MONSTER_CAP:40]

These all seem relevant to put in the UI, IMO. Unless anyone has major objections to that, I'll be doing just that and uploading a new version tomorrow.