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 see why the next gen can't use the graphics set instead of the text set like the old gen, only the people who are playing acii will ever want to see the text on the map/ embark map.

In short, in nextgen there's a separate buffer for map tiles, so plugins that draw something over the map must draw into that buffer instead of the original DF buffer.

[notfood]

Couldn't the old buffer be overlayed on top of the new buffer?

[Roses]

Question: Is it possible to change overrides mid game?

[LeoCean]

Yeah they aren't taken from the save file, you can use different tilesets mid game too.

I wonder why bamboo requires varied grass, even if you get rid of the 3 other numbers it still won't show them if you don't have varied grass on, and varied grass takes tiles that are used in other things that make them less refined for the things that are plain grass. If we could override grass tiles that may make it look better.

[0x517A5D]

I know what happens.
Plugins that draw something in the map need to be updated to be compatible with twbt, that's easy to do for actual plugins but for Lua scripts... I need to think.

In short, in nextgen there's a separate buffer for map tiles, so plugins that draw something over the map must draw into that buffer instead of the original DF buffer.

I'm purely guessing here, but you might want to put intercept code into screen_paintTile() in dfhack/library/LuaApi.cpp, and a similar hook somewhere in Ruby.

Obviously this would mean folding some code into the main dfhack distro.

Or some hook code inside Screen::paintTile in dfhack/library/modules/Screen.cpp or inside Screen::doSetTile?

I've gotta say, I don't like the idea of you requiring custom-patched versions of other plugins.

[mifki]

I know what happens.
Plugins that draw something in the map need to be updated to be compatible with twbt, that's easy to do for actual plugins but for Lua scripts... I need to think.

In short, in nextgen there's a separate buffer for map tiles, so plugins that draw something over the map must draw into that buffer instead of the original DF buffer.

I'm purely guessing here, but you might want to put intercept code into screen_paintTile() in dfhack/library/LuaApi.cpp, and a similar hook somewhere in Ruby.

Obviously this would mean folding some code into the main dfhack distro.

Or some hook code inside Screen::paintTile in dfhack/library/modules/Screen.cpp or inside Screen::doSetTile?

I've gotta say, I don't like the idea of you requiring custom-patched versions of other plugins.

Me too. But I'm afraid twbt-nextgen is not popular enough for dfhack maintainers to welcome all the required changes to dfhack main code.

While not being the best solution, it's not a problem for me to provide modified versions of several plugins, and I didn't know that there are also scripts that draw on the map area.

[lethosor]

Is the source of these modified plugins available?

[mifki]

Is the source of these modified plugins available?

They're in the nextgen branch of twbt repo. But there's nothing interesting, just some hacks to make them compatible with twbt without modifying dfhack.

Spoiler (click to show/hide)

            renderer_cool *r = (renderer_cool*)enabler->renderer;
            if (r->is_twbt())
                r->output_char(color, x, y, 'X');
            else           
                OutputString(color, x, y, "X");

The proper way would be to add another parameter to functions that paint on screen and that return screen size - whether to use map buffer/size from twbt (if it's loaded) instead of the normal df buffer. Default that parameter to false (as most plugins draw text), and update plugins that draw on the map.

[LeoCean]

The overrides for tiles/items seem to work on the old gen 3.41 besides for the tree stuff. Mainly roots.

[Rose]

There's actually more scripts that write to the screen than plugins, as that's the preferred way of making a gui in dfhack.

[mifki]

There's actually more scripts that write to the screen than plugins, as that's the preferred way of making a gui in dfhack.

To screen doesn't necessarily mean on the map.

[LeoCean]

Can people change the version twbt loads from the source code? It may be helpful for those who build unofficial dfhack and want to play twbt before the official one is released, since so far no one else has figured out how to change what version twbt would load with.

Pretty sure it is done in twbt.cpp though there was nothing saying r1, so why didn't it work for them on r0...

[salithus]

Can people change the version twbt loads from the source code? It may be helpful for those who build unofficial dfhack and want to play twbt before the official one is released, since so far no one else has figured out how to change what version twbt would load with.

Pretty sure it is done in twbt.cpp though there was nothing saying r1, so why didn't it work for them on r0...

There was confusion when this all went down between me and what fricy was saying regarding source being available (I thought he was talking about TwbT not being available but he was referring to something else). As long as the TwbT source is out there (and it is per the OP - I didn't realize it at the time), we can build it and specify the DFHack build - that part is done in the CMakeList file.

[fricy]

Can people change the version twbt loads from the source code? It may be helpful for those who build unofficial dfhack and want to play twbt before the official one is released, since so far no one else has figured out how to change what version twbt would load with.

Pretty sure it is done in twbt.cpp though there was nothing saying r1, so why didn't it work for them on r0...

r0 is in the makefile. The problem with compiling it for newer versions is that the memory addresses it needs to work are not in symbols.xml used by dfhack, but hardcoded into the plugin itself. Those adresses change with every version, and mifki needs to reverse engineeer df to compile. When the adresses are updated compiling is trivial if you know how to.

@mifki: btw isn't it possible to add these to the df structure tools, so finding them could be automated? Not that I'd know how to do that.
@salitus: ninj'd: I was referring to mifki's updated dfhack plugins which I couldn't locate/compile at the time.

[salithus]

Can people change the version twbt loads from the source code? It may be helpful for those who build unofficial dfhack and want to play twbt before the official one is released, since so far no one else has figured out how to change what version twbt would load with.

Pretty sure it is done in twbt.cpp though there was nothing saying r1, so why didn't it work for them on r0...

r0 is in the makefile. The problem with compiling it for newer versions is that the memory addresses it needs to work are not in symbols.xml used by dfhack, but hardcoded into the plugin itself. Those adresses change with every version, and mifki needs to reverse engineeer df to compile. When the adresses are updated compiling is trivial if you know how to.

@mifki: btw isn't it possible to add these to the df structure tools, so finding them could be automated? Not that I'd know how to do that.
@salitus: ninj'd: I was referring to mifki's updated dfhack plugins which I couldn't locate/compile at the time.

ah.