Print

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

[igglez]

I deleted this line from these 2 files to fix with notepad (actually had duplicates of the file for some reason when I searched for the file so deleted from everyone)

[ fix/stuckdoors ] -name stuckdoors; autoresetgrid enable

files were -

PyLNP_dfhack_onLoad.init
LNP/PyLNP.json

EDIT - I fixed the flickering with this

[lethosor]

Again, that is not a PyLNP issue. There are instructions for disabling that script in the thread for PE's pack.

[Dirst]

Again, that is not a PyLNP issue.

Recently my shirts have been coming out of the laundry with wrinkles even though I followed the instructions on the little labels.  This started happening the day after I downloaded PE's latest pack, so I'm sure that PyLNP must be causing it!

In all seriousness in a world where most folks don't know where Windows ends and Office begins, reporting a bug in the wrong thread is an understandable mistake.  That said, anyone using third-party plugins to third-party extensions of alpha-stage software could benefit from taking an interest in what all of those different components bring to the party.  These launchers and utilities are seriously impressive work.

[Pidgeot]

Note to pack authors: The update checking will be changed in the next release.

For the most part, everything should work as before, but you should add a field "updateMethod" to the "updates" object and set it to either "dffd" or "regex" (depending on what you are currently using). If you are currently using regexes and "directURL", you may need to set "directFilename" as well.

There will, at least temporarily, be an auto-detection routine which tries to guess the correct updateMethod based on the current settings, but after a handful of versions, I expect to remove it. When auto-detection kicks in, a warning will be printed to the error log as a reminder.

Please refer to the associated issue and the updated README for further details, and feel free to ask if there's anything you are unsure of.

[igglez]

Again, that is not a PyLNP issue. There are instructions for disabling that script in the thread for PE's pack.

While I appreciate it was off topic - when I searched for the issue it brought me here first.

It took me much, much more time to actually find & implement the fix, trawling through various other posts and my PC folder for .init  files and such.

If someone else goes down the same path as me to find the fix for the flickering issue, and come to that post in this thread, they will easily find the steps because of those 3 off topic posts. While I appreciate the need for structure, structure is only in place for efficiency, to which it was more efficient to post the steps of the fix than it is to send people off to look elsewhere.

[Dricus]

Heyo, I've uploaded a third alpha version of my Qt GUI for PyLNP. Feedback is greatly appreciated.

Changelog

• Added a widget for installing mods to the settings window.
• Implemented the Defaults button.
• Implemented the Update dialog.

Download

Windows executable: https://bitbucket.org/Dricus/python-lnp/downloads/PyLNP-qt_gui-alpha3-win.zip
Linux executable: https://bitbucket.org/Dricus/python-lnp/downloads/PyLNP-qt_gui-alpha3-linux.tar.gz
Mac executable: https://bitbucket.org/Dricus/python-lnp/downloads/PyLNP-qt_gui-alpha3-mac.zip

Source code: https://bitbucket.org/Dricus/python-lnp

[Uzu Bash]

Why is World Viewer packaged with this? You may support it, but it's really not ready for distribution to anyone but beta test volunteers. To push it in the state it's in now is just going to leave a negative impression of it. I've never been able to use it without a crash. I can't even get a feel for the interface without it crapping itself.

[fricy]

Why is World Viewer packaged with this? You may support it, but it's really not ready for distribution to anyone but beta test volunteers. To push it in the state it's in now is just going to leave a negative impression of it. I've never been able to use it without a crash. I can't even get a feel for the interface without it crapping itself.

This is the launcher's support forum. Your comment is more useful elsewhere - namely your platform's Starter Pack thread. Or even better - in the World Viewer's development forum.

[kahrkunne]

Hey!
You might remember me as that guy who kept bothering you about xdg-terminal.
I'm back. I switched from i3 to bspwm and I discovered a bug in xdg-terminal.
Basically, on my system I have $TERM set to "rxvt-unicode-256color" (because if you set it as "urxvt", some programs don't recognize it or don't support 256 colors).
But xdg-terminal tried to do "which $TERM" and execute that in the terminal_generic() function, which clearly doesn't work.
So I fixed it, here's the new and improved version: http://sprunge.us/BBAD

It should only do something if somebody has $TERM set to "rxvt-unicode-256color" and "which rxvt-unicode-256color" spits out an error, so it shouldn't break compatibility for anyone or anything or any situation. So if you'd just merge that with your code (I'd submit a pull request but I have never used either bitbucket or mecurial) and add it to the binaries (by the way, I compiled and tested it and it works just fine) for your next release that'd be very nice.

EDIT: My earlier code had a bug that has now been fixed. Also, I added an improvement: now, if $TERM is not empty, but "which $TERM" throws an error, and $TERM is not "rxvt-unicode-256color", it will fall back to xterm.

The final added piece of code now looks as such:

Code: [Select]

    # If `which $TERM` throws an error, fall back to xterm
    { ERROR=$(which "$TERM" 2>&1 1>&$out); } {out}>&1 # $ERROR is set to whatever "which $TERM" outputs to stderr
    if [ -n "$ERROR" ]; then
        if [ "$TERM" == "rxvt-unicode-256color" ]; then
            TERM="urxvt" # fix for if $TERM is set to "rxvt-unicode-256color" but the terminal binary is named "urxvt"
        else
        TERM="xterm"
        fi
    fi

EDIT2: Modified the code one last time, this time to update the comments. Also it's funny because the link now spells "BAD" (it's not bad though it's good don't worry)

[Pidgeot]

I'm not sure that's sh syntax (I think $() is from bash), but anyway, wouldn't this be better?

Code: [Select]

    if [ "$TERM" == "rxvt-unicode-256color" ]; then
        which $TERM >/dev/null 2>&1
        if [ $? -ne 0 ]; then
            TERM="urxvt"
        fi
    fi

This way, no extra commands are executed unless the detected terminal is exactly that string.

[kahrkunne]

$() is valid in any shell. Backticks are deprecated and have been for quite a long time I believe. They were replaced with $() because you can't nest backticks, but you can nest $(). Also it's clearer. Backticks are only still supported for compatability's sake and you should refrain from putting them in any new code. Also $() is POSIX-defined.

Code: [Select]

    { ERROR=$(which "$TERM" 2>&1 1>&$out); } {out}>&1 # $ERROR is set to whatever "which $TERM" outputs to stderr is not valid in a different shell (I just tested in dash), I'll find a fix for that tomorrow (there's a different way to do it)
Also, the code I posted also accounts for the other possible values of $TERM. True, what you posted would work if someone had TERM="rxvt-unicode-256color", but my code will not only account for that, but also for any other possible values of $TERM (for example, if $TERM turns out to be rxvt-88color, z29a-nkc-uc, Eterm-256color, xterm-xf86-v44, xnuppc-200x75-m, ansi80x25-mono or any other of the 2661 possible valid values listed in /usr/share/terminfo (yes there's 2661 different terminals out there can you believe that?)) by defaulting to xterm.
What my code does is as follows:
* First, it checks if $(which "$TERM") gives an error. xdg-terminal tries to execute that later on, and if it's an error it'll crash the whole thing horribly
* If it is, it checks if $TERM just so happens to be rxvt-unicode-256color, and if it is it sets TERM to be "urxvt", because I happen to know that's what is meant by rxvt-unicode-256color.
* If it's not rxvt-unicode-256color, it just ignores the previous value of TERM altogether.
Your code skips the first and last steps and only fixes the crashing for a TERM value of rxvt-unicode-256color. It'll work on my machine, but it won't work for someone who has some other exotic terminal. My code will work for anyone that has xterm installed.

EDIT: Also, I think I've mentioned this before but why are you so hellbent on not having bash as a dependency? I challenge you to find even 1 example of a GNU/Linux user who doesn't have bash installed. If you just make xdg-terminal bash-dependent then I'm 100% sure you'll not break compatibility for anyone, not now nor in the future, and you'll get access to all these shiny bash features.
Anyways, I have a non-bash-reliant solution to the problem here (tested using the dash shell)
Just replace the line I posted earlier in this post with the following:

Code: [Select]

ERROR="$(which $TERM 2>&1 > /dev/null)"With this, the entire thing should work without using bash, and it looks better too.

[Pidgeot]

Thanks for the change. I'll get it committed in time for the next release.

EDIT: Also, I think I've mentioned this before but why are you so hellbent on not having bash as a dependency?

The original xdg-terminal script uses sh, and I have to assume there's a reason for that. There's no point in changing it for the sake of changing it.

Also, I don't *need* those features. If I want fancy script features, it'd make more sense to rewrite it in Python; that way I wouldn't need an external file in the first place.

[kahrkunne]

Thanks for the change. I'll get it committed in time for the next release.

EDIT: Also, I think I've mentioned this before but why are you so hellbent on not having bash as a dependency?

The original xdg-terminal script uses sh, and I have to assume there's a reason for that. There's no point in changing it for the sake of changing it.

Also, I don't *need* those features. If I want fancy script features, it'd make more sense to rewrite it in Python; that way I wouldn't need an external file in the first place.

I doubt there's a reason for it to use /bin/sh instead of bash, really. Also, now that you've mentioned it, I might actually rewrite the whole thing in python sometime. It doesn't seem like it'd be too much work, and it'd be a nice way to practice my python a little bit.

[Pidgeot]

PyLNP 0.10 is now out, with the most significant changes being the addition of resolution options and a significant overhaul of many UI elements.

For pack maintainers, this release also adds support for custom titles and tooltips for graphics and mods, and enhances the update system to be more generic. Please check your configurations to make sure the new "updateMethod" field is set appropriately.

[PeridexisErrant]

For modders, makers of graphics packs, or maintainers:  content manifests.

As well as a title and tooltip, these allow you to specify incompatible versions of DF, which are then hidden so users don't try to install game-breaking old raws.  All you need to do is stick a file like the following at the top level of the mod directory or graphics pack.

Code: (LNP/Mods/foo_mod/manifest.json) [Select]

{
    "author": "Urist McFoo_Modder and friends",
    "content_version": "1.2a",
    "df_min_version": "0.40.03",
    "df_max_version": "",
    "title": "Foo Mod!",
    "tooltip": "The mod all about foo-ing.\nA second line."
}