Print

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

[variablenonsense]

It actually did this on the previous version but I forgot to mention it, so it isn't just restarting - I shut down my comp nightly, so ...

Resizing doesn't help either, tried that.

http://i.imgur.com/jzSRZqA.png

Screenshotting only catches one frame of it; it happens too fast, but in that GRAPHICS_FONT will jump up to the top of the window then back down to that position really quickly.

Maybe it has something to do with using a custom windows theme? ... I forget when I noticed it, so I don't remember which revision -didn't- do it.

[Pidgeot]

Maybe it has something to do with using a custom windows theme? ... I forget when I noticed it, so I don't remember which revision -didn't- do it.

That sounds plausible. Judging by the image, it *might* be related to scrollbars? As of PyLNP 0.10, scrollbars are supposed to hide themselves whenever they aren't actually needed, I think maybe that's what ends up confusing it.

You could try making a bunch of extra keybinding files so it ends up needing a scrollbar for that; if that also freaks out, then that's probably it. (You can delete them again from the LNP\Keybinds folder.)

It'd also be helpful to know what theme that is; maybe I can work around it somehow (no guarantees, though).

Until the problem is resolved, you can try going back to PyLNP 0.9.6, which doesn't contain the automatic scrollbars. You can just drop the old exceutable right next to the current one; I'd keep PyLNP.json from the pack (note that update checking might fail, since that system was also changed somewhat for 0.10).

[variablenonsense]

http://yorgash.deviantart.com/art/Steam-VS-for-Windows-7-449032822

I believe this is it, though I don't have the icons. Not fond of them. (It's been several months since I installed it and I looked at quite a few, but I'm pretty sure that's it.)

Going back to that previous version fixes the issue, so I'm going to guess that's the problem, if that's what's changed. Actually, let me see...

Yep. Adding a bunch of duplicate keybinds causes that tab to do the same thing. I know I've had compatibility problems with at least one other program from the custom theme, that's what made me think about it.   

[Pidgeot]

Yeah, I don't really think I can actually *fix* this, since it appears to be a problem with the modified system files used by the theme.

What I *could* do is add a user setting for the next version that forces the scrollbars to always be visible. That should avoid the problem, assuming they're working at all in 0.9.6.

Alternatively, you could wait for the new UI that's under development. It uses a completely different UI library, so there's a chance it won't be affected by this - but I don't know when it'll be ready, as there's still some work to do.

[Pidgeot]

@variablenonsense: One of the other developers (the guy who added the auto-hiding scrollbar, actually) suggested another approach, which I'd like to know if works.

Can I get you to go to https://bitbucket.org/Pidgeot/python-lnp/issue/89/auto-hiding-scrollbar-may-cause-breakage, download the build attached there (PyLNP_scrollbar_test.zip), and try running it? If it works, we'll put that in the next build instead of a hidden option.

[variablenonsense]

Tried it out, same effect.

Whatever works for you guys; I just report the oddities when I see them. I don't go to that tab often (after playing around I have it how I like it, and I can swap basic tilesets with no issues, it's just the customize screen) ... and I can use the 0.9.6 version for that if I -need- that screen. I don't know how many other people have custom themes or have this issue and just haven't mentioned it, so, like I said, your call.

[Ravendarksky]

I have a request/suggestion for future LNP. Can the Copy data from an older Starter Pack.bat file be modified to also copy the actual LNP settings?

[lethosor]

Which LNP settings? If you mean the game configuration (init.txt, d_init.txt, keybindings, etc.), those can't always be copied over safely if options are added or changed by Toady, although it should be safe to copy the files over if the DF version doesn't change (they're located in <DF folder>/data/init).

[easykiln]

I know it is minor but it annoys me that Dwarf Therapist throws a warning every time if you set it to run with dwarf fortress, but that is the easiest way. The only way I can think of to properly fix that is to change Dwarf Therapist to automatically just listen for some sort of signal from dfhack before autoconnecting, but I am a noob and it is a problem that only matters with this pack so I was hoping you might have an easier way to address it.

[Pidgeot]

Tried it out, same effect.

Whatever works for you guys; I just report the oddities when I see them. I don't go to that tab often (after playing around I have it how I like it, and I can swap basic tilesets with no issues, it's just the customize screen) ... and I can use the 0.9.6 version for that if I -need- that screen. I don't know how many other people have custom themes or have this issue and just haven't mentioned it, so, like I said, your call.

PyLNP 0.10b, which is being uploaded to Bitbucket at this very moment, adds the option I was talking about earlier (Options > Always show scrollbars). Hopefully it'll allow you to use the newest version properly.

[Linkxsc]

question, is there anyone else having issue with this version of LNP where dwarves will have issues assigning and unassigning hauling labors? Might be a therapist bug actually, but started noticing on my fort. Only 6 of the 10 soldiers (off duty) and wood crafters (also not doing too much because its a small desert embark without much wood) didn't have hauling set, even though they should have it. Meanwhile my brewer, grower, and metalsmith who should have no hauling labors, have all of them set.
Upon trying to give the ones that should have hauling... it'll set, and I hit send to game, and then when it refreshes, they still won't have those labors.

What gives?

[fricy]

question, is there anyone else having issue with this version of LNP where dwarves will have issues assigning and unassigning hauling labors?

It sounds like the autolabor plugin is messing with you. Check the dfhack tab in the launcher if you have autolabor enabled. You can switch it off in the dfhack console with disable autolabor

[toasteur]

I know it is minor but it annoys me that Dwarf Therapist throws a warning every time if you set it to run with dwarf fortress, but that is the easiest way. The only way I can think of to properly fix that is to change Dwarf Therapist to automatically just listen for some sort of signal from dfhack before autoconnecting, but I am a noob and it is a problem that only matters with this pack so I was hoping you might have an easier way to address it.

you can simply uncheck the option to connect and load dwarves on startup in DT.

[easykiln]

I must have missed said option ,thank you.

[Linkxsc]

question, is there anyone else having issue with this version of LNP where dwarves will have issues assigning and unassigning hauling labors?

It sounds like the autolabor plugin is messing with you. Check the dfhack tab in the launcher if you have autolabor enabled. You can switch it off in the dfhack console with disable autolabor

Its off and was never turned on. And still is happening.

Literally it will be like this. 2 of my 4 woodworkers will have all far right labors applied, I hit to apply hauling labors to all of them. hit send, and it just keeps telling me that the 2 of them don't have those labors applied.