Print

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

[CLA]

would like permission from the pack maintainers.

You're free to use, modify and distribute CLA for testing and debug purposes as needed.
File changes, from my notes:

Spoiler (click to show/hide)

Code: [Select]

-------------
item_tool.txt
-------------
changed wheelbarrow tile to 158
changed minecart tile to 170
removed [INVERTED_TILE] from minecart


-------------
init.txt
-------------
4x replace with CLA
[GRAPHICS:YES]
[TRUETYPE:YES]
[FPS:YES]


-------------
d_init.txt
-------------
[AUTOSAVE:SEASONAL]
[ENGRAVINGS_START_OBSCURED:YES]
[SHOW_FLOW_AMOUNTS:YES]

changed TRACK_NSEW to 182; swapped N/S and W/E trackstops:
[TRACK_N:210I]
[TRACK_S:208I]
[TRACK_E:181I]
[TRACK_W:198I]
[TRACK_NS:179I]
[TRACK_NE:192I]
[TRACK_NW:217I]
[TRACK_SE:218I]
[TRACK_SW:191I]
[TRACK_EW:196I]
[TRACK_NSE:195I]
[TRACK_NSW:180I]
[TRACK_NEW:193I]
[TRACK_SEW:194I]
[TRACK_NSEW:182I]

[SKY:39:2:1:0]


replaced colors.txt


Write me a pm if you need anything else.

Edit:
Also, just tested it out. used a 40.10 install and directed the client to the directory of DwarfFortress.exe. DF was colored red, pressing update did nothing, pressing it again crashed the client.
Restarted, pointed the client to the parent directory. pressed launch, worked, pressed update, updated successfully to 40.13. A better communication in that regard would be nice. Tell the user to point the client to the parent directory, or do it automatically. I.e., if the game finds DF.exe in the selected directory, select the parent directory and notify the user of it.
The other components don't do anything yet, but I guess that's to be expected.
Feedback:
A Legend for the background color would be nice. Alternatively, another column with status information (up to date, not installed, etc). It's sort of intuitive (green is good, red is bad, etc), but more accurate information would be good.
Some sort of status bar at the bottom telling me what the application is doing is very important. Tell me that you're downloading the game right now, how much of it you got, when you failed your connection, and so on.

An option to transfer saves would be great, too. Not sure whether that should be a separate function or a box you tick when you update DF.

[salithus]

You're free to use, modify and distribute CLA for testing and debug purposes as needed.

Write me a pm if you need anything else.

Thanks! I've added an issue to do so here, and will keep you updated on progres: https://github.com/salithus/MountainHome/issues/24

Also, just tested it out. used a 40.10 install and directed the client to the directory of DwarfFortress.exe. DF was colored red, pressing update did nothing, pressing it again crashed the client.
Restarted, pointed the client to the parent directory. pressed launch, worked, pressed update, updated successfully to 40.13. A better communication in that regard would be nice. Tell the user to point the client to the parent directory, or do it automatically. I.e., if the game finds DF.exe in the selected directory, select the parent directory and notify the user of it.

Added this: https://github.com/salithus/MountainHome/issues/20 - What you described makes sense and should be simple enough to implement.

The other components don't do anything yet, but I guess that's to be expected.

From a technical perspective, it is because I haven't added any Releases for them on the mountainhome website. I can probably do something to make this clearer because in retrospect it might be useful if someone wants to subscribe to a planned project such as the dwarf visualizer thread. I'll have to think some on how I want to handle those.

A Legend for the background color would be nice. Alternatively, another column with status information (up to date, not installed, etc). It's sort of intuitive (green is good, red is bad, etc), but more accurate information would be good.

Added this: https://github.com/salithus/MountainHome/issues/21 - Thinking perhaps an optionally visible sidepanel with a color legend? I'll mock something up and post it later to get feedback.

Some sort of status bar at the bottom telling me what the application is doing is very important. Tell me that you're downloading the game right now, how much of it you got, when you failed your connection, and so on.

Added this: https://github.com/salithus/MountainHome/issues/22 - Note that as of this build, I've got a much more user-friendly Upgrade button process (progress bar for downloading and status text for progress/speed/unpacking), but I haven't put it on DFFD yet. I added the issue anyways, because I hadn't considered what to do about being offline or otherwise unable to phone home to the MountainHome site, so that definitely belongs in the status bar somehow.

An option to transfer saves would be great, too. Not sure whether that should be a separate function or a box you tick when you update DF.

Added this: https://github.com/salithus/MountainHome/issues/23 - It's definitely on my list to do, but before I get to that I'm trying to work out managing the transfer of game settings. So far it's been either copy/pasta your old init.txt/d_init.txt and hope for the best, or do it by hand (at least in my experience with both vanilla and PE's Starter Pack). I'm trying to set up a settings management system that stores the user's preferences and has handling for new/changed options on the DF side and functionality to either mass-update or transfer specific settings to the new install. Once that's handled, save migration is probably next on the list.

Thanks for the feedback!

[CLA]

By the way, are you planning to include a command line version, so I can just type "mountainhome -Um" and it upgrades all components and migrates saves for example? What about a checksum function, so I can verify something has downloaded properly and uncorrupted?

While we're at it, I figure some useful flags (as well as options for the GUI client) would be
*verbose
*migrate saves, don't migrate saves (not sure which should be the default here)
*only upgrade DF, not components (basically a vanilla install)
*don't upgrade DF, only components (as far as they support the old version)
*only upgrade specific components (dependency checking?)
*don't apply user init profile
*specify a path to a user init profile which to use
*specify a path where to put the upgraded version



Some other advanced stuff for the future:
*An option to view file changes.txt, change log.txt and the change log on the bugtracker before installing.
*Include an optional background service that uses the RSS release feed to automatically update or notify the user.
Component creators/devs could add their own RSS release feeds.
On that note, do you have some sort of API planned out for component creators? I.e. a specific way they should pack their components,
and which auxiliary files we should include? I'm thinking of naming schemes/file hierarchies, as well as preview images, description files, changelogs, file changes, etc.


You probably have half of these planned already, and it's too soon in development for the other half, but I figured I post it anyway.
Do you prefer me posting in this thread or opening issues on github?

[UristWoodie]

Support for Torrent d/l as well as browser d/l (where available).

[salithus]

Ok, stripped out the stuff I made issues for. Re: that, feel free to open issues, but the attention the thread gets from being bumped doesn't hurt I've gone through the rest and added my notes in bold.

While we're at it, I figure some useful flags (as well as options for the GUI client) would be
*migrate saves, don't migrate saves (not sure which should be the default here) Saves don't migrate by default, should be a post-upgrade option for DF. See this planned feature: https://github.com/salithus/MountainHome/issues/23
*only upgrade DF, not components (basically a vanilla install) The general idea is that, once I get past handling vanilla DF, an upgrade to a given component (DF or otherwise) would list the other impacted components, broken down by "must upgrade" in order to support upgrading the selected one, and "optional upgrades" which would have checkboxes defaulted to checked you could unselect
*don't upgrade DF, only components (as far as they support the old version)
*only upgrade specific components (dependency checking?)
*don't apply user init profile This is what I'm working on now - I want to save these settings independent of the actual init.txt/d_init.txt files. Then, post-upgrade will be the option to apply them individually or all, along with a process to handle new settings (like when STRICT_POPULATION_CAP showed up).
*specify a path to a user init profile which to use

Some other advanced stuff for the future:
On that note, do you have some sort of API planned out for component creators? I.e. a specific way they should pack their components,
and which auxiliary files we should include? I'm thinking of naming schemes/file hierarchies, as well as preview images, description files, changelogs, file changes, etc. Going with the path of least-resistance here, where I'll have to stay on top of upgrades and manually keep the database up to date. Once the system is in place and working, I'll shift focus to automating that part. RSS feed would be the easiest for me to pick up changes from, but I'm open to any options here for getting that data into the system faster. For example, I could use RSS to pick up new DF versions, but I can't get the download link without some scraping so I haven't gone down that road yet.

Support for Torrent d/l as well as browser d/l (where available).

Added to the list, but I have done 0 investigation into how to embed a torrent client so any pointers would be appreciated.

[UristWoodie]

I am not a programmer...however...

http://en.wikipedia.org/wiki/Libtorrent
libtorrent is an open source implementation of the BitTorrent protocol. It is written in and has its main library interface in C++. Its most notable features are support for Mainline DHT, IPv6, HTTP seeds and µTorrent's peer exchange.

libtorrent uses Boost, specifically Boost.Asio to gain its platform independence. It is known to build on at least Windows, Mac OS X, Linux, and FreeBSD.

It does include support for magnet links too.

[salithus]

I am not a programmer...however...

http://en.wikipedia.org/wiki/Libtorrent
libtorrent is an open source implementation of the BitTorrent protocol. It is written in and has its main library interface in C++. Its most notable features are support for Mainline DHT, IPv6, HTTP seeds and µTorrent's peer exchange.

libtorrent uses Boost, specifically Boost.Asio to gain its platform independence. It is known to build on at least Windows, Mac OS X, Linux, and FreeBSD.

It does include support for magnet links too.

Sweet, I'll check it out.