Print

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

[Thundercraft]

And why is it important to keep these packages as close to vanilla as possible?

Because this is a bugfixed version of vanilla DF with GUI plugins. If we started editing the raws to fix lightsabers, egg numbers, skull thickness, etc, it would be a mod: Modest Mod does that exactly. But that's a different beast entirely...[snip] And the other thing is where to stop? Which modification is to fix bugs, and which changes the game balance? That's a slippery slope I don't want to start on.

The main reason I asked that was to encourage someone to state specifically who the intended audience is and what the intended goals are.

I understand why we want to keep these very close to vanilla. There's already an abundance of mods that changes DF gameplay. You're right: It is a slippery slope. If we start down that path, where do we draw the line? Is it making any sort of change to the raws, even to fix obvious bugs in a seamless way? Because the line is anything but obvious, I think it's worth discussing where to draw the line and why.

You said that "this is a bugfixed version of vanilla DF". But then you immediately try to contrast these packs with Modest Mod, which you claim is a mod that tries to be something else entirely. I would say that is a very, very poor example to make such a comparison.

Granted, Modest Mod does call itself a "mod". And yet, it also portrays itself as something very different:

The Modest Mod is a collection of vital bugfixes and tweaks that everyone should be able to use comfortably and without reservation. This mod doesn't add anything new. It doesn't do anything controversial. It's just like vanilla DF, but a little better. French vanilla.

This is a mod for people who don't use mods.

In your example you say that Modest Mod makes changes to the raws in order to quote, "fix lightsabers, egg numbers, skull thickness, etc." Actually, that's not very accurate. True, Modest Mod does change the raws to change egg numbers. (And this is something I begged Igfig to make an Optional Module that one has to activate or install separately.) However, Modest Mod does not have anything as silly as a lightsaber and, from what I can tell, it does not change skull thickness.

If you take a close look at Modest Mod, particularly his "List of Changes", you'll find that over 95% of the changes (aside from the Optional Modules) are strictly bug fixes or simple bug workarounds of one type or another. However, there are a couple minor changes in Modest Mod that I would have done differently or left out (the change to egg numbers being one of them).

But even several of the Optional Modules make such minor changes to gameplay that I can't imagine many players would object if Toady made them a part of vanilla. (The Pedestal is an extra building to give otherwise worthless artifacts and objets d'art a use, adding to room value. Eternal Fashion is a sort of fix to bugs related clothes wearing out and reduces the associated FPS impact.)

Anyway, this Cross-Platform Edition GUI could incorporate some of these changes as "Mods" in the Options tab. Example: As I suggested in my post above, Dricus should consider such a mod button to fix [GRAZER] values in order to make raising grazing animals more feasible and realistic.

Changes to [GRAZER] values should be considered a much-needed bug fix. It's so bad that the largest of these, such as elephants and giant moose, will starve to death and go extinct during world gen, with players never getting see them. Even if elephants survived and you obtained some, they'd have to eat constantly, so it's impractical to train them for war. And large grazers tend to eat up all the grass in your area, so players have to send out their military to kill them quickly just to leave some grass for your pets. (Besides, it'd be frustrating to newbies to have their pets die of starvation, even after they pen them properly and do everything right.)

I'm sure that, one day, Toady will get around to "rebalancing" the grazer values. But, in the meanwhile...

...you said yourself that DF is daunting as it is already, I don't want newbies to have to hunt down what's different from the vanilla... [snip] So this pack is intended to be as close to the vanilla experience as possible, with some fixes, but original raws.

I understand. But I don't see things so black and white. I do agree that keeping things as close to the vanilla experience as possible is important. Having newbies and players confused from their game experience being different from what the wiki or video tutorials describe is something to avoid. But if you do any bugfixing whatsoever, then what you have is technically a "mod" and the game experience already differs from what the wiki and other players describe.

Again, where do you draw the line? And why are you seem so reproachful towards changing the raws to any degree for any reason - even just to fix bugs? I can't see that it hurts anything, as long as the game experience stays as vanilla as possible. But if fixing bugs makes the experience slightly different from the wiki and other players, I think that's an acceptable trade off - especially if your package details exactly what's changed and why.

[Thundercraft]

At least LucasUP's old LNP gave the option of downloading either a small, basic pack or an "Advanced" version with a bit more stuff.

That was a different time: LucasUP's basic version was without Dfhack, only the advanced version had it. Nowdays PeridexisErrant's starter pack and Macnewbie depend heavily on Dfhack, all of the gui changes and plugins need it to work.

LucasUP's Lazy Newb Pack may be a bit outdated now. But it's not exactly a dinosaur. The last release was slightly over a year ago (August 2012). Even so, it's the same Dwarf Fortress 0.34.11 that you have in your packs. DF, itself, has not changed.

Granted, many utilities have changed and come a long way in that time, DFHack in particular. However, as useful and awesome as DFHack is, I would not call it "essential" in the sense that the game is unplayable without it. Again, learning DF is - in and of itself - enough of a challenge for some players and trying to learn anything more (at least initially) could be intimidating.

Consider, also, that DFHack can change significantly between versions. Among other things, it now incorporates Stonesense and DFusion. Also, the semi-official r4 that was released recently completely lacks Stonesense. And scripts that worked for r3 may not work in r4 (and visa versa).

If someone wants to play without dfhack, that means he ->knows<- what dfhack is, so he is a veteran, and this pack is not for him.

So you admit that your pack is geared towards newbies. But wait... I'm confused. I pointed out earlier how PeridexisErrant said that the "newbie" label quote, "doesn't really fit anymore." Also, PeridexisErrant said this about his own pack:

...this new starter pack has an equivalent for Mac and an edition for Linux; these have relatively minor differences.

If PeridexisErrant says the newbie label no longer fits and that there are only relatively minor differences between his pack and the others, then does this mean he feels none of them are geared towards newbies?

Also SoundSense depends heavily on the modified gamelogs --> again this needs dfhack.

Again, that's not very accurate. Soundsense does not depend on the presence of DFHack to function properly. It can work fine without it. The SoundSense homepage does not even mention "DFhack", nor does the SoundSense thread OP. But the wiki page on SoundSense mentions:

...recent versions of soundsense come with dfhack plugins that significantly expand its capabilities.

Among these new capabilities is instantly switching the season music to the current season on game load, rather than waiting for the season to change to switch to the appropriate music. You have to admit, that's a rather minor thing.

What's left? Chromafort? Fortress Overseer? Maybe these could be in a separate add-on pack...

Having a separate add-on pack is an extra installation step and it adds to the complexity. Besides, Chromafort takes up virtually no space and is usually packaged with Quickfort. Fortress Overseer, however, is huge! And instead of having a seperate add-on, players might as well download and install FO from the official thread.

The point is to keep things simple and easy. A better way is to offer two separate packages and let users decide which to download and install.

Anyway, if your pack really is geared towards newbies, then doesn't it make sense to only include stuff that most newbies would bother to learn and actually use on a regular basis?

The point of this pack should be to ease new players into the game. But if they have to read through pages and pages of documentation for a dozen different utilities just to decide which utilities they want to learn and use, that's a lot of extra complication and hassle.

...and there are parts of the world, where internet is slow, and a 50mb download is better than a 100mb, but afaik a ~100 mb download is NOT that big of a problem. Mobile phone games are bigger than this.

Perhaps those of you with 4 GB broadband and terrabyte storage devices are a bit jaded or tend to take such things for granted. Not everyone is so blessed, not even in developed countries. There are wide gaps between the haves and have-nots. Myself, I happen to live out in the boonies. The only internet choices I have are satellite and what I have, which is uber-slow DSL barely one step above dial-up. (The problem with satellite, aside from the high price and contract terms, is that it is not unlimited. And it still requires phone access!) Nor do I have much excess storage space. Fact is, I never had a cell phone until rather recently and it's a pay-as-you-go cheapie kept mostly for emergency use. I've never played a game on a mobile phone in my life.

And also there's the problem when you need to maintain two different packs, and the confusion when a newbie doesn't understand why he didn't has the utility that someone says is part of the pack and should try out.

Look at the two packages LucasUP offered. He did not include as many utilities, so it should be a bit simpler to keep updated. His LNP became rather popular, so he must have been doing something right. Even with video tutorials that recommended LNP to play along, it did not seem to confuse many players that there were two different packs available. And it's a simple matter to say "Advanced" or "Compact" or something when suggesting which one to download.

These new packs seem to be deviating quite a bit from LucasUP's version. And I'm just questioning where you're taking things and who you're trying to please.

IMO: The decision to keep the LNP name was a mistake. Though, to be fair, right now there really isn't anything geared almost exclusively towards newbies.

Maybe keeping the names of the old packs was a mistake. Maybe not. I did choose to use MacNewbie, because it gives credit to the original authors, and makes it easier to find the updated pack.

If these packs really are aimed towards newbies, then I can understand this. Though, even then, keeping the "LNP" acronym or "Lazy Newb" name could very easily confuse someone into thinking you're talking about either LucasUP's packs or his GUI.

Anyway, there's more than one way to give the original authors credit. It's a simple matter to have a "Credits" list. And there's nothing stopping you from saying "Formerly known as LNP" or similar.

What do you propose exclusively for newbies?

I think I've more-or-less explained what I would recommend in a newbie pack. Basically, I'd like something simpler and a bit closer to LucasUP's versions. But, at the same time, I would not hesitate to incorporate whatever bug fixes I could fit into it as long as these did not significantly change gameplay from vanilla. As such, I'd also include a large majority of Modest Mod (though, not all of it).

And last, but certainly not least, I would try to expand on the Lazy Newb Pack - V16.2 Source Code and recompile it for KBasic. It would still be cross-platform, but it would not depend on stuff like .NET or Java to function. Nor would I have it require DFHack.

In fact, I'm seriously considering doing just this and starting my own Newbie Pack. Though, it'd be a lot of work and things are a bit hectic for me right now. Even so, I'll see what I can accomplish.

[PeridexisErrant]

This is great feedback / discussion to have - I'll try to write a longer response tomorrow. More packs are always cool, remember to add it to the LNP wiki page.

For clarity, I meant that while LucasUp's LNP was *only* really for newbs - though it could be modified by experienced players, the whole setup was pretty basic. By contrast, I try for a pack which is fine for newbs, but also good for more advanced players who don't want to keep up with the forums. I provide stuff configured to a much greater extent, so that ignoring as much as possible will still be a good experience for newbs. However, it also has most of the go-to utilities that someone will swear by and works for people who are not newbs. Tl, dr: not just newbs, and wanting a pack isn't lazy.

I can only maintain one pack well, for various reasons. The name change was mostly due to extensive confusion between packs, with so many windows versions (I'd recommend calling yours something original). Lightsaber is slang for the currently unbalanced whips and fails, which routinely sever limbs with every stroke.

Yeah, where to draw the line is debatable, but I picked "no raw edits" for two reasons - it's a very clear rule, and it preserves maximum compatibility with (non hacky/raw only) mods, which can simply be dropped in.

This is longer than I expected.  It reads kinda like a rebuttal, which I guess it is, but I'll try for more constructive engagement tomorrow - it's a lot more work

Thanks for the feedback though - really.

[fricy]

Just one reaction for now, you write a lot of text.

And last, but certainly not least, I would try to expand on the Lazy Newb Pack - V16.2 Source Code and recompile it for KBasic. It would still be cross-platform, but it would not depend on stuff like .NET or Java to function....

Six month ago I'd have said go for it. Now I'm not so sure:
We have Dricus's java launcher, there's another java launcher that can load mods too (forgotten the name ), there's the original LNP, there are a couple forks aimed at mods, etc. While choice is usually good, fragmentation can be an issue too. I'd prefer one cross-platform solution, that can be scaled up-or down according to need, (can load mods, or Rubble addons, etc.) than 5 different half finished ones. If you start working on one, just because you can, it does not mean it will be better, especially if you're not sure how much time you have to sink into it.
I'm not saying you shouldn't do it, (quite the opposite, free work is always welcome ), just that it needs to have a reason to exist. Plus this launcher is -almost- finished apart from a few bugs, imho the logical thing would be to work on this version, than start over from scratch.

...Nor would I have it require DFHack.
In fact, I'm seriously considering doing just this and starting my own Newbie Pack. Though, it'd be a lot of work and things are a bit hectic for me right now. Even so, I'll see what I can accomplish.

Ok, you don't like dfhack. I get it. But what would be the reason behind this pack? As you said LucasUP's LNP is not that ancient, the major difference between that and the newer starter packs is the dfhack plugins. Yours would have a newer DwarfTheRapist? And also raw edits. So it would be an update to ModestMod/Accelerated ModestMod. Those also have a place to exist, but they are not aimed at newbies either. And you should check out Deon's Essential DF, it's not the same what you describe, but pretty close. Streamlined and rebalanced raws.

One thing I realized while thinking how to respond is that you're right, the interface does feel overly complicated at first. I still don't think we should do basic and advanced packs, but doing a basic and an advanced interface could make it easier for newbies to get into the game, while enabling the veterans to play with the settings.

Sorry if some of my comments sound harsh, or negative, your criticism is in fact welcome!

[milo christiansen]

I was mostly just interested in this launcher as a uniform place to launch all utilities AND handle selecting Rubble addons.

I already have a Rubble GUI I could use for a "Ready To Rubble" pack but it would be cool if it was more integrated.

The target audience for such a pack is experienced players who just want to try out this "Rubble thing" without any fuss.

If it's not likely to happen, no problem. I'll just come up with my own solution.

[fricy]

BUMP! The thread shudders, and begins to move.

Hey Dricus, any plans/time for continuing on this, or releasing the source? A new release is coming, dfhack r5 was recently finished, and a few plugins just surfaced that'd need some additional features to be used properly...

[Dricus]

BUMPPP!

Been a long time... Came back here to play some more DF, now 0.40.* is finally out, and see what's up. First of all, sorry for the sudden disappearance, some personal stuff came up which caused me to have no time and motivation to continue working on this for quite a while.

I've been thinking about continuing development on this launcher. But there are a few issues:

• Looking at it now, I'm not happy with the way the sourcecode is set up.
• The launcher is using Swing, which I considered a valid choice when I started development, but looking back, that wasn't really a good decision. JavaFX would have been better, for example.
• In hindsight, I'm having second thoughts on wether Java was the right choice altogether. Reason for this is that projects like this fare best if more people start contributing. For people to start contributing, the design of the sourcecode should be well set up and the chosen programming language and technology should be ones that many people know.

Concluding: For me to continue, there should at the very least be a major rewrite of some parts of the code, to make it more future- and collaboration proof (like replacing Swing with JavaFX).

Thoughts on the issues above are greatly appreciated ;) .

@fricy: To answer your (old) question: The project is open source. Anyone can fork the sourcecode from bitbucket and continue.

[PeridexisErrant]

My thoughts:  Here's a new Python version.

Given the points you've raised above - which I agree with, though the only source I can read is Python - I'd be inclined to go with the python version.  It's as cross-platform as anything else, already has patch-based graphics loading with obvious extensibility to mods, and Python is usable by more new programmers (including me) than any other language. 

[fricy]

@fricy: To answer your (old) question: The project is open source. Anyone can fork the sourcecode from bitbucket and continue.

Hey Dricus, welcome back! I think it'd be best to update the OP with the link to your repo, so if someone decides to work on it it's easy to find, I had no idea where it was until you mentioned bitbucket.
It looks like we'll migrate to Pylnp soon, if you have the time and energy to work on it some ideas are posted in the thread P/x posted below.

[Dricus]

Hmm, I do like the idea of using script languages like Python or JavaScript. Thing with Python however, is that AFAIK there's not really a good GUI editor around. And to be honest, the UI of the Python version is not very appealing to me, because everything is so cramped (no offense, I know it's still heavily in development). Creating nice looking GUI's without a GUI editor is very tedious in my experience.

IMHO, ideally the GUI should be made with a GUI editor, and the code behind the GUI should be script. I've done some experimenting, and I think I came up with a nice middle ground. Since a while Java has scripting capabilities built-in. That way, Java programs can be combined with JavaScript, Python or even Clojure. On top of that JavaFX is a nice cross-platform way of creating GUI's. JavaFX GUI's can be combined with JavaScript or Python.

My current proof of concept loads JavaFX GUI's dynamically from a directory and displays a tab for each GUI it finds (see below for a screenshot). Each GUI consists of a FXML file (created with Scene Builder, quite a user friendly and well-documented tool) and a JavaScript or Python file which implements the logic behind the GUI.

The other part of my experimentation is keeping the amount of Java code to a minimum and coding most stuff in dynamically loaded JavaScript or Python files. That way developers can easily make modifications and test them without the need to recompile/repackage everything. After editing the script or GUI, just restart the launcher and watch the result. Easy peasy.

Nice thing about this is that it doesn't need to be exclusively Python or JavaScript. Both languages can be used at the same time.

Please let me know what you think. In the meanwhile I'll continue experimenting and try to come up with a working prototype.

Some sample Python code:

Spoiler (click to show/hide)

Code: [Select]

# Load init files
globals.put('init', GameConfigFile('Dwarf Fortress 0.40.06/data/init/init.txt'))
globals.put('d_init', GameConfigFile('Dwarf Fortress 0.40.06/data/init/d_init.txt'))

# Make utility functions globally available
globals.put('util', Utility)

# Change listener for a property
def onChange(observable, oldValue, newValue):
    print 'Change!', observable, newValue

# Create an observable property for a setting and add a change listener
font = SimpleStringProperty(init.getProperty('FONT'))
globals.put('font', font)

# Add the change listener using a convenient helper function in the Utility class
util.addChangeListener(font, onChange)

# Print some settings
print init.getProperty('FONT')
print d_init.getProperty('SHOW_EMBARK_TUNNEL')

# Change the observable property and the change listener should be called
font.set('Arial')

Screenshot:

Spoiler (click to show/hide)

[fricy]

Hmm, I do like the idea of using script languages like Python or JavaScript. Thing with Python however, is that AFAIK there's not really a good GUI editor around. And to be honest, the UI of the Python version is not very appealing to me, because everything is so cramped (no offense, I know it's still heavily in development). Creating nice looking GUI's without a GUI editor is very tedious in my experience.

We'll see how it turns out. The design will change for sure, there's a lot on the table.

The other part of my experimentation is keeping the amount of Java code to a minimum and coding most stuff in dynamically loaded JavaScript or Python files. That way developers can easily make modifications and test them without the need to recompile/repackage everything. After editing the script or GUI, just restart the launcher and watch the result. Easy peasy.

That sound very good, but if you use both java and python, won't it mean that the final application will be huge because of dependencies? I was going to propose qt, but the support libraries alone are around 10 mega, while the launcher is only around 2 if I recall correctly. And I'm starting to hate java, but that's mostly because oracle and the fact that java doesn't really work out of the box and always wants to update, and the google's java is not the same as the official one, and on macs it's even more complicated. Ok, rant over.

[Dricus]

That sound very good, but if you use both java and python, won't it mean that the final application will be huge because of dependencies? I was going to propose qt, but the support libraries alone are around 10 mega, while the launcher is only around 2 if I recall correctly. And I'm starting to hate java, but that's mostly because oracle and the fact that java doesn't really work out of the box and always wants to update, and the google's java is not the same as the official one, and on macs it's even more complicated. Ok, rant over.

Depends on your definition of "huge". When I package my current prototype, I get a 15 Mb JAR, which doesn't require any dependencies other than the Java 8 Runtime Environment.

For a sneek peek, you can download it here: click!
The LNP/scripts folder contains all Python scripts.

You can download the Java 8 RE here: click!

Here's a screenshot of my latest expirimentationing :

Spoiler (click to show/hide)

[Dricus]

Tried packaging a simple PyQt application. That results in an executable of 19 Mb. Still not shocking IMHO. Advantage of this over Jython with JavaFX is that it doesn't require any dependencies at all. The PyLNP exe is about 7 Mb.

I don't think it's possible to create a launcher that is both cross platform and small (as in 1 Mb or less, which would be ideal) at the same time. Not without requiring the user to install required dependencies.

Although, the Swing version weighs only about 1 Mb. The large size of the Jython prototype is caused by bundling the Jython runtime with the JAR.

[PeridexisErrant]

19 MB is big in the context of my whole pack currently sitting at ~120MB before compression, but it's not problematically large.  I think not requiring dependancies is absolutely worth it.