Print

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

[PeridexisErrant]

"PyLNP.exe" and "Starter Pack Launcher.exe" try to connect to the internet when I execute them.  Can I ask why this is?

They both check this url to see if a newer version is available, nothing sinister.  The PyLNP is going to get an option to disable this soonish. 

I just realized that the download link to LNP is a bit slow, so I uploaded it to my server and offering it as a mirror link as a little thanks to you for doing all this. =)

LNP free mirror: http://bit.ly/1mcezz6

I have a script running on that server that checks for new versions on the official site every hour. If that's not ok, please tell me, otherwise the link above should have updated versions within an hour once they are uploaded as well.

Thanks!  To check the version, scrape this page - it's designed for it and doesn't inflate my view count.  In general re-hosting is welcome - my only ask is that source and version are clearly indicated, which you're already doing 

Something that I greatly appreciate when it's there and appear and disappear from one version to another:
Having ASCII Square in the list of graphic packs.

I hope I'm not alone to like ASCII Square
Can We haz Square Ascii back, please?

Sorry - but no.  Basically it adds 5MB to the size of the pack, and you can add it yourself by copy-pasting the ASCII pack and changing a single line!  ("[FONT:", the others are optional unless you use fullscreen or graphics).

Does PyLNP.exe have the optimizations and bugfixes that the LNP has? Such auto worn clothing dumping?

Yes, because these are done through DFHack, for which both launchers write a configuration file.  It's not a feature of the launcher, but it will still work with the PyLNP.

[salithus]

Something that I greatly appreciate when it's there and appear and disappear from one version to another:
Having ASCII Square in the list of graphic packs.

I hope I'm not alone to like ASCII Square
Can We haz Square Ascii back, please?

Sorry - but no.  Basically it adds 5MB to the size of the pack, and you can add it yourself by copy-pasting the ASCII pack and changing a single line!  ("[FONT:", the others are optional unless you use fullscreen or graphics).

Before I venture down the road - have you or the PyLNP or the modloader guys looked at doing a nexusmods approach? Basically thinking you include the list of "available" graphics packs vs "installed" ones, with functionality to download/unpack/install them.

[Art]

Yes, because these are done through DFHack, for which both launchers write a configuration file.  It's not a feature of the launcher, but it will still work with the PyLNP.

OK but how do you enable it with PyLNP? With the older LNP, there were some checkboxes.

[PeridexisErrant]

Something that I greatly appreciate when it's there and appear and disappear from one version to another:
Having ASCII Square in the list of graphic packs.

I hope I'm not alone to like ASCII Square
Can We haz Square Ascii back, please?

Sorry - but no.  Basically it adds 5MB to the size of the pack, and you can add it yourself by copy-pasting the ASCII pack and changing a single line!  ("[FONT:", the others are optional unless you use fullscreen or graphics).

Before I venture down the road - have you or the PyLNP or the modloader guys looked at doing a nexusmods approach? Basically thinking you include the list of "available" graphics packs vs "installed" ones, with functionality to download/unpack/install them.

We do keep looking at it - Fricy's maintaining a github collection of graphics packs - but consensus is basically that it's dependancy hell.  Different links, package types, incompatible versions, changes without notice... basically it'd become even more work because someone would have to construct and maintain the whole repo.  And then you either need a super-repo with everything, or to keep them all in sync...

Even then it could work - but it introduces too many single points of failure for me to be comfortable with.  Instead the approach is more to let users find the content, and try to structure, code, and document everything well enough that you can just drop it in.  You can see in my changelogs though how much is involved beyond this in preparing a coherent pack - you can easily add stuff, but compiling from scratch would be painful. 

I'm gently pushing an attempt to get some format standards in place - especially for mods, which are a complete mess such that I leave them out entirely - but it's a long-term effort.  Happy to continue the conversation, but that's where we're at right now.

Yes, because these are done through DFHack, for which both launchers write a configuration file.  It's not a feature of the launcher, but it will still work with the PyLNP.

OK but how do you enable it with PyLNP? With the older LNP, there were some checkboxes.

IIRC just right-click on the menu item and it should enable/disable it.

[salithus]

Something that I greatly appreciate when it's there and appear and disappear from one version to another:
Having ASCII Square in the list of graphic packs.

I hope I'm not alone to like ASCII Square
Can We haz Square Ascii back, please?

Sorry - but no.  Basically it adds 5MB to the size of the pack, and you can add it yourself by copy-pasting the ASCII pack and changing a single line!  ("[FONT:", the others are optional unless you use fullscreen or graphics).

Before I venture down the road - have you or the PyLNP or the modloader guys looked at doing a nexusmods approach? Basically thinking you include the list of "available" graphics packs vs "installed" ones, with functionality to download/unpack/install them.

We do keep looking at it - Fricy's maintaining a github collection of graphics packs - but consensus is basically that it's dependancy hell.  Different links, package types, incompatible versions, changes without notice... basically it'd become even more work because someone would have to construct and maintain the whole repo.  And then you either need a super-repo with everything, or to keep them all in sync...

Even then it could work - but it introduces too many single points of failure for me to be comfortable with.  Instead the approach is more to let users find the content, and try to structure, code, and document everything well enough that you can just drop it in.  You can see in my changelogs though how much is involved beyond this in preparing a coherent pack - you can easily add stuff, but compiling from scratch would be painful. 

I'm gently pushing an attempt to get some format standards in place - especially for mods, which are a complete mess such that I leave them out entirely - but it's a long-term effort.  Happy to continue the conversation, but that's where we're at right now.

Fair enough - for what it's worth I'd be willing to host a superrepo if we can figure out how to do it and the DFFD people can give me some stats on the kind of traffic they see so I can work out what kind of budget I'd need.

[PeridexisErrant]

The problem isn't hosting, it's maintenance and the complexity of code to manage all the dependencies - especially when they can change without notice, some users may not want to update, etc...  Basically I'm going to stick with what I know works until after I see a working prototype of an alternative system. 

[salithus]

The problem isn't hosting, it's maintenance and the complexity of code to manage all the dependencies - especially when they can change without notice, some users may not want to update, etc...  Basically I'm going to stick with what I know works until after I see a working prototype of an alternative system.

From an end-user experience, I like how NexusMods works - if you're not familiar it accomplishes three key things:

1) Searchable database of mods (in our cases, mods, DFHack plugins/scripts, and graphics packs)
2) Maintains list of known compatibility issues between mods and loose dependency-based sorting of mods for what order they should be installed/loaded.
3) Notifies users of updates to mods.

I spent some time trying to prototype this with just DwarfFortress, but I got sick + overtime at work and didn't make much progress with it. I stopped at a point where I'd have to decide between either scraping web pages to get updates on utilities or have "someones" be responsible for updating the central db.

I also don't fully comprehend the work you guys have done with mod loading.

[Kryxx]

Most of the applications that nexus mods use don't update a few times a month or more.

It's much easier to maintain and handle that when the games in questions are not technically in alpha/beta, with constant updates and changes.

It's a stable product/game with only a few changes per year for most of them.  So your not having constant changes to the various systems that need to be updated and redone.

There is not 'common' way to mod the game, there is no API per say.  Thus the issue.  Each mod can cause conflicts.

[salithus]

Most of the applications that nexus mods use don't update a few times a month or more.

It's much easier to maintain and handle that when the games in questions are not technically in alpha/beta, with constant updates and changes.

It's a stable product/game with only a few changes per year for most of them.  So your not having constant changes to the various systems that need to be updated and redone.

There is not 'common' way to mod the game, there is no API per say.  Thus the issue.  Each mod can cause conflicts.

Yeah I've got to wrap my head around how PE and company are handling mods, but for core things like DF, DFHack, plugins, and graphics packs, I think I can at least get a prototype working.

The difficult part re: stability is having a flexible system for marking dependencies. The idea I'm working on now has a list of "dependency" objects, and each dependency is a "component" with a min and max version. (note: I'm also heavily borrowing concepts from my experiences with the NuGet packaging system - they have a lot of the same issues we do)

[PeridexisErrant]

Mods!  The basic idea is to do three things:  transform mods into a common format, merge them* while providing the user with live compatibility feedback, and then install to DF folder.  The first bit is basically done; though we'll probably continue to add edge cases it handles so it 'just works' in as many cases as possible.  The merging is right now very primitive, but as long as whatever logic we use can do input and output in the same format that can be improved later.  Installing right now just means "drop into DF folder", which also needs to be smarter re: existing saves and also graphics.  Getting mods right now is an exercise in trawling forums and DFFD, and wishing people would use at least a similar format sometimes...

Further discussion should happen in that thread.

*repeated 3-way-merge by lines, no overlapping changes from common ancestor - yet

I spent some time trying to prototype this with just DwarfFortress, but I got sick + overtime at work and didn't make much progress with it. I stopped at a point where I'd have to decide between either scraping web pages to get updates on utilities or have "someones" be responsible for updating the central db.

I also don't fully comprehend the work you guys have done with mod loading.

The core problem with replicating the NexusMods approach in detail is that the DF community doesn't have a coherent structure to anything or good habits with format and documentation - no standards makes the whole thing way harder.  Kryxx also raises a good point about the stability and update rate of DF compared to other games - it would be a lot easier if updates were slower and we had the user base to justify a separate database for every version. 

I sincerely wish you good luck with your system - and I hope it's eventually possible to fold it into the PyLNP!

[salithus]

Mods!  The basic idea is to do three things:  transform mods into a common format, merge them* while providing the user with live compatibility feedback, and then install to DF folder.  The first bit is basically done; though we'll probably continue to add edge cases it handles so it 'just works' in as many cases as possible.  The merging is right now very primitive, but as long as whatever logic we use can do input and output in the same format that can be improved later.  Installing right now just means "drop into DF folder", which also needs to be smarter re: existing saves and also graphics.  Getting mods right now is an exercise in trawling forums and DFFD, and wishing people would use at least a similar format sometimes...

Further discussion should happen in that thread.

*repeated 3-way-merge by lines, no overlapping changes from common ancestor - yet

I spent some time trying to prototype this with just DwarfFortress, but I got sick + overtime at work and didn't make much progress with it. I stopped at a point where I'd have to decide between either scraping web pages to get updates on utilities or have "someones" be responsible for updating the central db.

I also don't fully comprehend the work you guys have done with mod loading.

The core problem with replicating the NexusMods approach in detail is that the DF community doesn't have a coherent structure to anything or good habits with format and documentation - no standards makes the whole thing way harder.  Kryxx also raises a good point about the stability and update rate of DF compared to other games - it would be a lot easier if updates were slower and we had the user base to justify a separate database for every version. 

I sincerely wish you good luck with your system - and I hope it's eventually possible to fold it into the PyLNP!

That's definitely the long term goal. I want a system that's geared towards the middle ground between "just found this game and using LNP" and "I just updated symbols.xml for you where da coders at?"

I'll quit derailing your thread, but for now think I'll focus my efforts on the graphics pack loading with this approach, although I'll have to lean heavily on your understanding of how to load/unload them properly. I definitely agree with the tenets for your mod approach (minimal effort required on the mod developer's side), but hope that by maybe creating some of this structure and letting them take advantage of it early on, we'll gain the adoption that Kryxx pointed out is missing.

[Raijen]

That does remind me that I should probably make a user option whether or not it should check for updates. I'll add that to my list of things to do.

As someone that plays DF from an offline laptop while on the train daily this would be quite nice -- If the device isn't connected it seems to hang for about a min or two and then throws an error when the connection timeouts -- you can ignore the error and the pack works properly but the delay gets a bit annoying after awhile.

[PeridexisErrant]

https://bitbucket.org/Pidgeot/python-lnp/issue/22/make-update-checking-optional

It's probably a good idea to *also* make the update check non-blocking, and just interrupt later if an update is found.

[ViRALiC]

You keep making all these updates to this pack, making it better all the time, and I really can't put into this text box how grateful I am.

If I win a million dollars in the lottery tomorrow, you're getting your share for making this pack, brother.

I deeply appreciate it.

[Dfuzzy]

I have an issue with the above ground level, whenever I try to lay down a zone (pen/pasture) I can't select pen or pasture the cursor dissapears and then I press ESC and after I press it the screen jump one level below ground making it impossible to do anything above ground.