Print

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

[mifki]

I don't think there's a newer version of TWBT than 5.45?  I looked on mifki's Github and the latest release is 5.45, and there had only been 5 commits since that release.   I guess mifki is running from the latest compiled source but hasn't released a new general version yet?

Latest binaries are always at http://build.mifki.com

Should I be distributing a newer version in the Starter Pack?  My understanding was that the releases were stable, and the builds might not be.

I thought most people were using builds from the build server (and you as well). I usually wait for positive feedback for new builds and then forget to make a Github release.

[scamtank]

Anytime a build.mifki.com^® product comes out broken, this thread gets plenty busy.

[lethosor]

In my opinion, you ought to include some kind of additional version information if you're encouraging people to use non-release builds to make bug reporting/troubleshooting easier (DFHack obtains some git information when using CMake, although that might be harder to integrate into your build system).

[TheBloke]

I am using version 5.45, bundled with PyLNP.  I just looked at mifki's Github and I see there have been 5 new commits since 5.45.  One of them looked particularly interesting to me:

Fixed zooming to unit/building

I have noticed that zooming is usually broken.  If I zoom to a unit/building, it will end up looking at another tile on the Z level of the target building/unit. 


OK, so now my question:  is any of this related to the fixes mifki has made regarding "Fixed zooming to unit/building"?  I thought the problem was only with mousequery, but maybe it is actually a problem in TWBT and it's possible to fix it in TWBT itself?

Short answer:  Yes, this is exactly what this fix is for, and now that I have applied 5.47 zooming works properly with mousequery.  Awesome, thanks mifki.  I am very happy not to have to use hotkeys to disable/re-enable mousequery for every zoom I do!

Long answer:  My original question was based on my failing to understand that mousequery is also written by mifki   I thought it was part of DFHack, and that mouse-menu was the non-DFHack mouse plugin.  Of course, both are.

So yes it was mousequery that was breaking zooming and the fix to it was for mousequery itself, which I had not noticed was actually part of/included with TWBT.

Got it now   Thanks for the fix, mifki.

PeridexisErrant:  In my opinion the fix to unit/building zooming makes it extremely worthwhile to include 5.47 in your pack.  The broken zooming has bugged me since I started playing, to the point where I assigned shortcut keys to disable and re-enable part of mousequery which I ran before and after every zoom.  Because I wanted to give up neither mousequery nor zooming, and thought that was the only way to fix it.

[lethosor]

Mousequery is not written by mifki - he just distributes a modified version that works better with TwbT.

[TheBloke]

Ahh I see. Thanks. 

[mifki]

In my opinion, you ought to include some kind of additional version information if you're encouraging people to use non-release builds to make bug reporting/troubleshooting easier (DFHack obtains some git information when using CMake, although that might be harder to integrate into your build system).

Don't undestand about additional version information.
Well, not that I'm encouraging people - in the time of active development I've configured the build server to help myself making binaries for three platforms, and people who followed the development knew where to get the latest version, this never was a problem. Honestly, I thought pack authors were taking latest builds too.

[lethosor]

My point is that if two builds are identified as, say, 5.47, it's difficult to tell them apart (although it's not an issue if you change the version number for every build; I'm not exactly sure what you do).

[mifki]

My point is that if two builds are identified as, say, 5.47, it's difficult to tell them apart (although it's not an issue if you change the version number for every build; I'm not exactly sure what you do).

No, it increments version each build and github releases are published from the build server as well, so all version numbers should be unique.

[PeridexisErrant]

Should I be distributing a newer version in the Starter Pack?  My understanding was that the releases were stable, and the builds might not be.

I thought most people were using builds from the build server (and you as well). I usually wait for positive feedback for new builds and then forget to make a Github release.

I'd be a lot happier redistributing from Github, FWIW.  Downloading an unsigned binary from a website with certificate errors is one thing for personal use, and quite another to hand out to tens of thousands of people.

[mifki]

Should I be distributing a newer version in the Starter Pack?  My understanding was that the releases were stable, and the builds might not be.

I thought most people were using builds from the build server (and you as well). I usually wait for positive feedback for new builds and then forget to make a Github release.

I'd be a lot happier redistributing from Github, FWIW.  Downloading an unsigned binary from a website with certificate errors is one thing for personal use, and quite another to hand out to tens of thousands of people.

Ok, I've published a release.

[Meph]

Should I be distributing a newer version in the Starter Pack?  My understanding was that the releases were stable, and the builds might not be.

I thought most people were using builds from the build server (and you as well). I usually wait for positive feedback for new builds and then forget to make a Github release.

I'd be a lot happier redistributing from Github, FWIW.  Downloading an unsigned binary from a website with certificate errors is one thing for personal use, and quite another to hand out to tens of thousands of people.

Ok, I've published a release.

So it's this from now on?

Spoiler (click to show/hide)

Mifki, any update on caste-specific creature graphics? ^^

[PeridexisErrant]

Just passing on a bug report - some overrides lead to images persisting even when the map is moved.

I seem to have found a bug and narrowed it down to TwbT and the Phoebus texture pack in the R17 starter pack.
Normal:
https://drive.google.com/open?id=0B3Vnl7plZSmeZHFaZDFFR3JBU1E
Then when you move the screen around this happens:
https://drive.google.com/open?id=0B3Vnl7plZSmeZUI2YkV2dklaS2c
https://drive.google.com/open?id=0B3Vnl7plZSmeZDFqSzdiR1N3NUU
I have no idea on how to fix this. Also I did not have this problem with the R16 starter pack.

That's TwbT 5.47 with Doren's Phoebus overrides, FYI.  r16 was 5.45 and minimal overrides.

[mifki]

Just passing on a bug report - some overrides lead to images persisting even when the map is moved.

I seem to have found a bug and narrowed it down to TwbT and the Phoebus texture pack in the R17 starter pack.
Normal:
https://drive.google.com/open?id=0B3Vnl7plZSmeZHFaZDFFR3JBU1E
Then when you move the screen around this happens:
https://drive.google.com/open?id=0B3Vnl7plZSmeZUI2YkV2dklaS2c
https://drive.google.com/open?id=0B3Vnl7plZSmeZDFqSzdiR1N3NUU
I have no idea on how to fix this. Also I did not have this problem with the R16 starter pack.

That's TwbT 5.47 with Doren's Phoebus overrides, FYI.  r16 was 5.45 and minimal overrides.

There's a recent discussion of this somewhere - it's because overrides specify different images for several tile types that the game normally displays with the same ASCII character. Therefore when moving, character doesn't change and I (and the original graphics code) don't update such tiles. It wasn't a problem before but probably now I'll add an option to always update all tiles that you can activate for affected tilesets (but we'll need to see how this affects gFPS).

[PeridexisErrant]

There's a recent discussion of this somewhere - it's because overrides specify different images for several tile types that the game normally displays with the same ASCII character. Therefore when moving, character doesn't change and I (and the original graphics code) don't update such tiles. It wasn't a problem before but probably now I'll add an option to always update all tiles that you can activate for affected tilesets (but we'll need to see how this affects gFPS).

Makes sense.  FWIW, I'll always leave that option on, because correct behaviour is much more important than the performance issue.

DFHack r4 has been tagged and the binaries should be uploaded soon, so maybe a build for that?