This leads to fairly subtle breakages, as a lexical sort of tag names usually matches the date, but not always (eg changing a leading v, moving a decimal, etc).

I need to rework the metadata protocol for GitHub-based components to use either assets or source zipballs from the latest release, instead of splitting this by release or tag. (chose the wrong abstraction, I think)

GPL3 for the code, and CC-BY-SA for the pack I distribute (or not-licensed if you make one using this code); should also list/clarify upstream licenses.

See https://github.com/Lazy-Newb-Pack/LNP-shared-core

It would be good to use as much of the shared core as possible. This includes making sure more of my setup goes 'upstream'.

From here

Hey, I am trying to make prepackaged versions of my mod (including DFHack) for all 3 OSes, but am running into a snag: I cannot extract the linux version because it has symbolic links. Any way around this other than telling the user to manually install DFHack themselves?

From here, it sounds like extracting the archives on Windows and re-packaging them would break symlinks upon extraction, even on OS X and Linux, which would break things that depend on those symlinks (Stonesense) completely.

As I mentioned in that thread, it would be possible to replace broken allegro symlinks with working ones in the DFHack launcher script. However, since I don't think there's a way to tell which files are broken symlinks and which are just normal files, it's not a great solution in terms of maintainability (if we add more symlinks, etc.).

Wrong memory layout file format for the latest version of Therapist.

https://developer.github.com/v3/#rate-limiting

Currently starter-pack only creates a complete cache, and deletes the cache when it's older than one hour. Since increasing the GH API ratelimit from 60 to 5K requests/hour is useful when testing, starter-pack can currently use a _CRED file with user\npass for HTTP basic auth, but this breaks for users with two-factor auth.

Supporting OAuth or conditional requests would be nice, but both look complicated enough to be log priority. Reasonable solutions gratefully accepted!

So, replacing the r06 PyLNP.exe with the r05 PyLNP.exe allows the launcher to run, but when trying to start the game you get this error (sorry for the comment spam)

Currently, the tool just collects the latest version of everything. This works very well in the long stable periods before a major DF release, but not so well when things are changing rapidly and (eg) a new DFHack version may target a previous DF release.

It would be nice to have an interface to specify which DF version should be used, rather than hand-editing _cache.yml (this works, but it's a real hack). For bonus points, this could auto-detect the target based on DFHack version, and collect older releases of graphics packs etc from github.

Status: wishlist, but unlikely to be implemented. There's no way to automate this and guarantee a coherent pack, so I prefer to force doing it by hand.

Back before you used a script, the contents of the ASCII graphics pack were kept to a minimum; now they contain complete raws. I'm guessing this was meant to be a temporary implementation while you were still trying to get everything in the script working initially.

I thought you might consider making it so that the script doesn't put so much stuff in the ASCII graphics pack, or at least maybe delete the "raws" folder afterwards.

For an example of the format you used before, you can refer to the ASCII graphics pack included with Dwarf Fortress 40_24 Starter Pack r19. It came with only 5 files:

• art/font license.txt
• art/font.ttf
• init/colors.txt
• init/d_init.txt
• init/init.txt

https://docs.dfhack.org/en/stable/docs/about/Removed.html#fix-diplomats

The corresponding DF Bug 3295 was fixed in DF 0.40.05.

https://docs.dfhack.org/en/stable/docs/about/Removed.html#fix-merchants

Humans can now make trade agreements. This fix is no longer necessary.

Probably requires a separate --release flag if it's to be automatic.

In this case, updating base/changelog.txt with a date, compressing the pack, and (new) adding a new entry afterwards could all be automatic.

Note: should also go through history and add dates to all as possible.

To start, I’d like to say no related settings have been fiddled with, and this seems to be an issue with the pack itself. While playing, I noticed that workshops aren’t being displayed correctly, picks are /‘s, wheelbarrows are minecarts, nestboxes are books, U/D stairs are X’s, etc. It would be greatly appreciated if this issue was resolved, as it likely affects everyone who uses the starter pack and Phoebus. It has been present for at least 3 releases.

Furthermore, TV4Fun told me that “This is an issue with the LNP and Phoebus. In recent versions, Phoebus has started packaging the TWBT files separately from the vanilla files. To get the nicer graphics, after you install Phoebus, go into your data and raw folders and copy the files from twbt_* into their respective non-twbt folders.” but after doing this, all entities have a “glazed” appearance to them. Any help?

Requires

• deleting folder
• logging warning
• removing from components list (to avoid listing in contents later)

Low priority, as packs rarely if ever build with this problem, but nice for correctness.

The Armok Vision binary is called 'Armok Vision Linux.x86_64' on Linux, but is referred to as 'Armok Vision.x86_64' in the code.

The latest mac pack is a bit old and not updated frequently, it'd be great to have a tool to generate it.
I've tried to use this to generate the mac version but I get some errors.

First I had to add the extract_to for PyLNP:

        os-osx:
            extract_to: |
                PyLNP.app:build/starter-pack-launcher

and TwbT:

        os-osx:
            extract_to: |
                {DFHACK_VER}/mousequery.plug.dylib:plugins/
                {DFHACK_VER}/twbt.plug.dylib:plugins/

The builder now runs and I get the following error:

ERROR:  Could not extract: Dwarf Fortress, curr_baseline, graphics/ASCII, Legends Browser

Configuring pack...
Traceback (most recent call last):
  File "main.py", line 19, in <module>
    stage.main()
  File "/starter_pack/starterpack/build.py", line 419, in main
    build_lnp_dirs()
  File "/starter_pack/starterpack/build.py", line 318, in build_lnp_dirs
    overwrite_dir(paths.lnp('extras'), paths.df())
  File "/starter_pack/starterpack/paths.py", line 64, in df
    return build('Dwarf Fortress ' + df_ver(), *paths)
  File "/starter_pack/starterpack/paths.py", line 44, in df_ver
    ver = component.ALL['Dwarf Fortress'].version
KeyError: 'Dwarf Fortress'

And I also get a warning: WARNING: "PyLNP.app" not found in "PyLNP_0.12b-OSX.zip", I guess the extract operation doesn't accept folders?

Has anyone succeeded building the mac pack?

Thanks!

This issue records all the config updates that I don't have time to do and debug before handing in my thesis. Expect fixes in June.

• enhanced gameplay DFHack option
• expand DFHack bugfixes option
• fix Soundsense config
• add / use date in changelogs
• sort out standing issues noted in code

Build is failing with the error below. I checked that the missing file is actually in the directory below.

~/Projects/starter-pack$ ls build/LNP/utilities/Armok\ Vision/
Armok Vision Linux_Data Armok Vision Linux.x86_64 Changelog.txt Credits.txt manifest.json Pugins Readme.txt

Python 3.5.2
Linux Mint 18.3 x86_64

python3 main.py --os linux --bits 64 --stable

Component: Age: Version: Filename:
TwbT 17 v6.41 twbt-6.41-linux.zip
DFHack 19 0.44.09-r1 dfhack-0.44.09-r1-Linux-64-gcc
Armok Vision 21 v0.19.1 Armok.Vision.0.19.1.Linux.zip
Dwarf Fortress 23 0.44.09 df_44_09_linux.tar.bz2
GemSet 36 44.07a DFgraphics_GemSet_44.07a.zip
Obsidian 41 44.07 DFgraphics_Obsidian_44.07.zip
Ironhand 41 44.07 DFgraphics_Ironhand_44.07.zip
Phoebus 41 44.07 DFgraphics_Phoebus_44.07.zip
Meph 41 44.07_v2.3.0.3 jecowa_Meph_44.07_v2.3.0.3.zip
Spacefox 41 44.07 DFgraphics_Spacefox_44.07.zip
Legends Browser 44 1.17.1 legendsbrowser-1.17.1.jar
Mayday 45 44.06 DFgraphics_Mayday_44.06.zip
CLA 102 44.xx-v25 DFgraphics_CLA_44.xx-v25.zip
PyLNP 152 0.13 PyLNP_0.13-linux-x64.tar.xz
DungeonSet 665 1.03 DungeonSet.zip
Soundsense 772 2016-1 soundSense_2016-1_196.zip
Stocksettings prese 1236 2 stocksettings-presets-v2.zip

Extracting components...
df_44_09_linux.tar.bz2 -> Dwarf Fortress 0.44.09
Armok.Vision.0.19.1.Linux.zi -> LNP/utilities/Armok Vision
df_44_09_linux.tar.bz2 -> LNP/baselines/df_44_09
df_44_09_linux.tar.bz2 -> LNP/graphics/ASCII
PyLNP_0.13-linux-x64.tar.xz -> starter-pack-launcher
jecowa_Meph_44.07_v2.3.0.3.z -> LNP/graphics/Meph
DFgraphics_Mayday_44.06.zip -> LNP/graphics/Mayday
legendsbrowser-1.17.1.jar -> LNP/utilities/Legends Browser
DungeonSet.zip -> LNP/graphics/DungeonSet
DFgraphics_Spacefox_44.07.zi -> LNP/graphics/Spacefox
DFgraphics_Phoebus_44.07.zip -> LNP/graphics/Phoebus
DFgraphics_Ironhand_44.07.zi -> LNP/graphics/Ironhand
DFgraphics_Obsidian_44.07.zi -> LNP/graphics/Obsidian
DFgraphics_GemSet_44.07a.zip -> LNP/graphics/GemSet
soundSense_2016-1_196.zip -> LNP/utilities/Soundsense
DFgraphics_CLA_44.xx-v25.zip -> LNP/graphics/CLA
twbt-6.41-linux.zip -> Dwarf Fortress 0.44.09/hack/plugins
dfhack-0.44.09-r1-Linux-64-g -> Dwarf Fortress 0.44.09
stocksettings-presets-v2.zip -> Dwarf Fortress 0.44.09/stocksettings

Configuring pack...
ERROR: pack version must start with DF version.
Traceback (most recent call last):
File "main.py", line 19, in
stage.main()
File "/home/dan/Projects/starter-pack/starterpack/build.py", line 406, in main
create_utilities()
File "/home/dan/Projects/starter-pack/starterpack/build.py", line 240, in create_utilities
os.chmod(exe, 0o110 | os.stat(exe).st_mode)
FileNotFoundError: [Errno 2] No such file or directory: 'Armok Vision Linux.x86_64'

• Disable TwbT dfhack init settings if DFHack is installed but TwbT is not
• Omit TwbT from contents if it's not installed (note that this happens during extraction - maybe an up-front check is needed?)
• Automatically pull DFHack nightly if --unstable is passed and there's no stable DFHack for this version yet

There's probably more which I'll discover soon...

Some components must be extracted after others, as they replace some files. Examples:

• DFHack after Dwarf Fortress
• TwbT after DFHack
• Stocksettings after Dwarf Fortress
• PerfectWorld XML after PerfectWorld

Extracting in the correct order is non-trivial; but should be decidable. I'm just hardish-coding it for now.

Noticed that the latest build is getting flagged as Malware by a couple of anti-virus vendors. (Sophos did for my PC).

Generic ML PUA detected at C:\Users\Tom\Desktop\Df\Starter Pack Launcher (PyLNP).exe

VirusTotal shows others have the same issue

ZipFile

https://www.virustotal.com/gui/file/911fb049de1b115d308bb152f3518120f6e23d1b71d9cce8a62b66cfc198d2d1/detection

Starter Pack Launcher (PyLNP).exe

https://www.virustotal.com/gui/file/5d4ae798961baa4b3bf1eb3d6df30ac411b289b4ce9d9e781e2c057aafede5f2/detection