Print

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

[Dricus]

Heyo, sorry about the lack of updates for such a long time. Didn't have the time lately. I'm actually almost finished with implementing the graphics pack functionality. I'll try to finish it up somewhere this month.

[PeridexisErrant]

That's awesome - I just wasn't sure what was happening.

/so excited

[fricy]

Watching with anticipation.

[Dricus]

@PerridexisErrant land @fricy: Could you guys tell me what functionality you would need on top of what is already included in my version to be able to switch to this version?

[PeridexisErrant]

Tricky for me just because the windows-only version works fine on windows - @fricy will give a more useful answer to this than I can. 

Generally, I'd want to avoid losing any of the functions in v16.2 (always launch selcted utilities + the whole v15 GUI functions).  However, I'd make the switch for features including a better graphics switching tool that left settings alone. 

Mostly just looking forward to the finished, feature-comparable version which can be further expanded ;-p

[fricy]

What I'm missing from the Mac gui is the ability to change keyboard layout and color schemes, and the Graphic Pack changing code is bugged. So yeah, I'd need the same functions as the current windows version. I don't know how this version works, but please make it easy to add graphics packs/new utilities, so don't hard code the ones included, but provide a menu/autodetect routine, or store these in a text file that we can edit without too much hassle.

However, I'd make the switch for features including a better graphics switching tool that left settings alone. 
Mostly just looking forward to the finished, feature-comparable version which can be further expanded ;-p

That might be tricky, as the init. files store the Graphic Pack settings and some of the game settings as well, so you'd need to look into the files to copy some of the settings into the main .init file, and not just copy the whole file into a folder. Would be good if you could solve this.

Migrating the init settings, keyboard layouts, savegames, macros from a previous version would be great. I know PeridexisErrant spent a lot of time creating batch files that do the same, but doing it from the GUI'd be better IMHO.

Plus, if you're up to the challenge: I think Meph wouldn't say no to a cross-platform Masterwork Mod GUI, but that's a different kind of beast all together with tons of different worldgen/game settings. And it'd need to be more flexible/modular then what we need, as he keeps adding new optional functions/buildings/units/whatever constantly. But you have to talk with him if you feel like helping out with that.

Thanks,
f.

[Dricus]

Graphics packs and utilities can easily be added by copying them to a folder in the graphics/utilities folder and adding a little bit of configuration to lnp.properties. That is already the case with the utilities included in the current version of the pack.

[PeridexisErrant]

However, I'd make the switch for features including a better graphics switching tool that left settings alone. 
Mostly just looking forward to the finished, feature-comparable version which can be further expanded ;-p

That might be tricky, as the init. files store the Graphic Pack settings and some of the game settings as well, so you'd need to look into the files to copy some of the settings into the main .init file, and not just copy the whole file into a folder. Would be good if you could solve this.

This is stretch goal territory, like the rest of my comments. 

Migrating the init settings, keyboard layouts, savegames, macros from a previous version would be great. I know PeridexisErrant spent a lot of time creating batch files that do the same, but doing it from the GUI'd be better IMHO.

Not that long really, but I agree that getting that function into the GUI would be better for user experience.  It's not a priority, but if anyone wants to have a go I'll improve the commenting a lot at some point - the functions are pretty darn simple.  My solution also only migrates content - your settings have to be recreated, the reason being that I can't be sure if it should actually override the newer version or not.  Knowing what to migrate and what to leave is a puzzle to big for me. 

Graphics packs and utilities can easily be added by copying them to a folder in the graphics/utilities folder and adding a little bit of configuration to lnp.properties. That is already the case with the utilities included in the current version of the pack.

The windows version avoids using a config file somehow.  It does however have a file of exclusions not to list, if that helps at all. 

Bottom line is that Fricy is probably the go-to person for feedback on this, since I've got the current state of the art. 

[Dricus]

The windows version avoids using a config file somehow.  It does however have a file of exclusions not to list, if that helps at all.

I was talking about my version, not the original one. :-)

[Dricus]

Status update: I've finished implementing simplifying graphics packs and started working on the refresh list buttons in the graphics and utilities tab.

I'm using a Trello board to keep track of my todo list, so check that out if you want to know what I'm working on.

[PeridexisErrant]

Just looking over the backlog, where it mentions updating the bundled stuff - would you be interested in having Fricy and I handle that (and find someone to do Linux), so you could just publish the LNP GUI itself?  I'd imagine that you could even copy Falconne and just provide a single download with compiled versions for all three.  Of course, if you want to keep up the full distributions yourself that's cool; I just found that maintaining a component as well as the package added a lot of work. 

Skipping back to basic features for a moment:  what's the current state of auto-detect of utilities (and graphics?), and the handling of spaces in the path?

And is there any chance of having configurable menu items, where I could set eg a link name and destination?  I've added a folder for User Generated content, and the LNP link is hardcoded to the old thread (ie not the pack that a newbie downloaded)  so this would be very nice indeed. 

[fricy]

Bonus feature: DFhack .init editing: some of the settings, like the mousequery plugin could have an added menu item. Maybe the custom shortcuts too. The majority of the setting would be hidden from the user, but not all of them. Maybe we could dedicate a section to the user-configurable data in the init file, and anything in that section would be editable? Do you think it's possible?

About the bundled stuff: the default dfhack r3 darwin package doesn't work out of the box, so don't waste time creating a package with that, only if you have a mac test-bed. Of course if you have, and would like to maintain the distributions, I'm ok with that. As  PeridexisErrant wrote.

[PeridexisErrant]

Proposal:  we call this the "Dwarf Fortress Launcher" (or something), because LNP just sounds condescending and doesn't really fit anymore.  I mean, I play with the default settings from my pack - and it's not laziness that prevents newbies putting together a similar pack, it's the way you need to have spent months following all the utilities and tilesets to keep up!  It's plain unreasonable to expect newbies to be able to do this, and unfair to label them lazy because of it. 

I think that the dfhack idea is awesome - thoughts below - but not a priority, unless it sparks a fey mood or something. 

Spoiler: dfhack.init GUI ideas (click to show/hide)

If there's a dfhack section, it HAS to be end-poweruser-configurable, as well as usable by newbs.  I'd leave this off the board as a goal for v2 of the CP release though, just because there's a lot to get before then - that said, it'd be awesome to have a GUI for dfhack.init; maybe we could have some kind of syntax like

Code: [Select]

#[label:command] (produces a check box with label, if checked inserts <command> on the next line)
command
         or
#[label:keybinding add [key:(default):(@context if relevant)] (field with keybinding, label, context grayed out but visible)
keybinding add default@context
which would work with the way dfhack reads the init. 

It might be easier, and also produce decently reusable code, to do a similar GUI-ification of the vanilla init files. 

Again though, this is just random dreaming and I wouldn't consider it a priority.

For the default button - is it possible to not-hardcode the defaults, and/or pop up a prompt to apply the defaults to saves too? 

Last:  looking at the board again before posting, once the 'backlog' is done this will be significantly better (by graphics/settings change and cross-platform-ness) than the standard LNP; and if some of the menus are configurable that'll be another big advantage.  Thanks so much. 

[Dricus]

Just looking over the backlog, where it mentions updating the bundled stuff - would you be interested in having Fricy and I handle that (and find someone to do Linux), so you could just publish the LNP GUI itself?  I'd imagine that you could even copy Falconne and just provide a single download with compiled versions for all three.  Of course, if you want to keep up the full distributions yourself that's cool; I just found that maintaining a component as well as the package added a lot of work.

That would be awesome! One of the main reasons why I started this project is that I would like the launcher to be cross-platform. Maintaining a pack takes a lot of time indeed, which I don't have at the moment.

Skipping back to basic features for a moment:  what's the current state of auto-detect of utilities (and graphics?), and the handling of spaces in the path?

Utilities and graphics packs are not autodetected. In stead, you need to configure them in lnp.properties. Here's an example:

Spoiler (click to show/hide)

Code: [Select]

# Utilities provided with LNP
lnp.utility.therapist.name=Dwarf Therapist 0.6.12
lnp.utility.therapist.directory=DwarfTherapist 0.6.12
lnp.utility.therapist.executable=DwarfTherapist.exe

lnp.utility.soundsense.name=SoundSense r35
lnp.utility.soundsense.directory=soundsense r35
lnp.utility.soundsense.executable=runProgram.bat

# Graphics packs provided with LNP
lnp.graphics.default.name=ASCII Default 0.34.11
lnp.graphics.default.directory=vanilla-0.34.11

lnp.graphics.phoebus.name=Phoebus 34.11v00
lnp.graphics.phoebus.directory=phoebus-34.11v00

lnp.graphics.ironhand.name=Ironhand 0.73
lnp.graphics.ironhand.directory=ironhand-0.73

And is there any chance of having configurable menu items, where I could set eg a link name and destination?  I've added a folder for User Generated content, and the LNP link is hardcoded to the old thread (ie not the pack that a newbie downloaded)  so this would be very nice indeed.

Configurable menu items in the Folders and Link menus is definitely possible. I'll add it to the backlog.

Bonus feature: DFhack .init editing: some of the settings, like the mousequery plugin could have an added menu item. Maybe the custom shortcuts too. The majority of the setting would be hidden from the user, but not all of them. Maybe we could dedicate a section to the user-configurable data in the init file, and anything in that section would be editable? Do you think it's possible?

Nice one. I'll add this one to the backlog as well.

About the bundled stuff: the default dfhack r3 darwin package doesn't work out of the box, so don't waste time creating a package with that, only if you have a mac test-bed. Of course if you have, and would like to maintain the distributions, I'm ok with that. As  PeridexisErrant wrote.

As said above: I would be very happy to only maintain the launcher and let others maintain the packs. That would give me more time to work on further developing the launcher.

@PeridexisErrant: I'll answer your last post later tonight. Out of time at the moment .

[Dricus]

Proposal:  we call this the "Dwarf Fortress Launcher" (or something), because LNP just sounds condescending and doesn't really fit anymore.  I mean, I play with the default settings from my pack - and it's not laziness that prevents newbies putting together a similar pack, it's the way you need to have spent months following all the utilities and tilesets to keep up!  It's plain unreasonable to expect newbies to be able to do this, and unfair to label them lazy because of it.

I'm okay with the current name. It's a quite funny and well known name. Just don't take it too seriously.

For the default button - is it possible to not-hardcode the defaults, and/or pop up a prompt to apply the defaults to saves too?

Entirely possible and a very good idea as well . I'll make a note of it in the backlog.

Regarding your configurable DFHack GUI idea: I've had some experience creating very generic configurable GUI's and applications and to be honest: in 99% of the cases it's not worth the effort. It will take a lot of time to create and the benefits will almost never outweigh the cost. This is partly due to the fact that the sourcecode of overly generic programs tends to become less and less understandable.

So in short: I'd rather hardcode a DFHack configuration GUI than create a generic one, because it will be a lot less work and will result in better maintainable code.

And before I forget: Thanks a lot PeridexisErrant and fricy for your constructive feedback! It really motivates me to continue working on this again!