Print

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

I consider it an essential part of Dwaf Fortress, and can't play without it.

119 (18.4%)

I use it for pretty screenshots, but otherwise don't use it during play.

211 (32.7%)

I only try it occasionally.

174 (27%)

I have no idea why I'm even in this thread, I don't use it.

141 (21.9%)

Total Members Voted: 642

[KevinCathcart]

I've updated Stonesense's overlay mode to support running in OpenGL rendering modes. It is compatible with the multilevel version of the Text Will Be Text plugin, at least on Windows. (I'm not current set-up to test the changes on other OSes, but I'm not expecting any problems on them).

The changes have been submitted for incorporation into the official stonesene sources as  dfhack/stonesense#21.

[Rose]

You may want to hold off on that, as stonesense is being moved outside of DF, and an the way overlay mode works will have to change completely.
If you want to help with that, contact me directly.

[arclance]

You may want to hold off on that, as stonesense is being moved outside of DF.

Did you exhaust the 32bit memory space?
If you did I am not surprised at all.
I was worried that would be a problem when DFHack grafted itself on to the Dwarf Fortress process.

[Rose]

As a matter of fact, yes, the 32bit limit has become a problem with some people.

It is because of this that, as well as the backwards and forwards compatibility that I decided to work on separating things.

It's going to be a long and tough process, but at the end of it, things should go a lot smoother.

Example:

Then you have the terrain-value, this reffers to the terrain-id that DFhack retreives from DF, and is used to align the block with the correct terrain. You use the debug mode to find the correct numbers.

This shit right here is going down. The latest DF release completely changed all the terrain numbers, making everything in Stonesense show up wrong. So rather than change the numbers, I'm changing how they're assigned entirely, which will mean that the same stonesense version will be able to be used for more than one version of DF. Possibly even the 2d versions, if an appropriate server plugin can be made.

[arclance]

As a matter of fact, yes, the 32bit limit has become a problem with some people.

It is because of this that, as well as the backwards and forwards compatibility that I decided to work on separating things.

It's going to be a long and tough process, but at the end of it, things should go a lot smoother.

Is anything going to require stonesense to be compiled as a 32bit binary once you separate it?
I know if you build a 64bit Dwarf Therapist on Linux it works just fine with Dwarf Fortress.

Code: [Select]

file ./DwarfTherapist
./DwarfTherapist: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=ed9d3ef09fc835cff7dbc211f2acb95bede0cf71, not stripped


[Rose]

No, once it's separated, the only thing keeping it 32bit is convenience in compiling.

Since right now I'm still using the DFHack build system for convenience.

[KevinCathcart]

You may want to hold off on that, as stonesense is being moved outside of DF, and an the way overlay mode works will have to change completely.
If you want to help with that, contact me directly.

How are you planning on handling the overlay? If you still plan on having an in-process peice to handle that part with the rendered images being transferred via some form of IPC, then the code I've written could be adapted to handle that.

Most of the OpenGl support changes were concerned with taking a bitmap from some source, and drawing it on top of what DF core drew. I'm pretty sure that will still be needed in the new system, no?

[Rose]

There's two options for the overlay right now.

A: Send the DF screen to stonesense, and send key commands back.
B: Send the stonesense screen to DF, and overlay it there.

I'm leaning on A, but I haven't decided anything yet.

[therahedwig]

As a matter of fact, yes, the 32bit limit has become a problem with some people.

It is because of this that, as well as the backwards and forwards compatibility that I decided to work on separating things.

It's going to be a long and tough process, but at the end of it, things should go a lot smoother.

Example:

Then you have the terrain-value, this reffers to the terrain-id that DFhack retreives from DF, and is used to align the block with the correct terrain. You use the debug mode to find the correct numbers.

This shit right here is going down. The latest DF release completely changed all the terrain numbers, making everything in Stonesense show up wrong. So rather than change the numbers, I'm changing how they're assigned entirely, which will mean that the same stonesense version will be able to be used for more than one version of DF. Possibly even the 2d versions, if an appropriate server plugin can be made.

Oof, I can imagine you don't wanna click through all the files and fix em, no.
So stonesense is going to have many version specific 'configs' then?

I'm happy about the seperation either way. I do wush I was a better coder now though.

[Rose]

The idea is not to need version-specific configs. One config should work for all versions, the only thing that would change would be the DFHack server plugin.

Anyway, this is the tiletype list as of right now. The first column is the numbers we've been using till now. The new system will let you either specify an exact tile using the key (column 1) or by a fuzzy selection using the remaining columns.

[KevinCathcart]

There's two options for the overlay right now.

A: Send the DF screen to stonesense, and send key commands back.
B: Send the stonesense screen to DF, and overlay it there.

I'm leaning on A, but I haven't decided anything yet.

What I personally really want is to be able to play DF switching between TwbT graphics in 2d mode and a stonesense powered isometric view at will with a single keypress. Either approach could support that, since it would be easy to allow for displaying the non-overlayed screen in the second process's window.

I can definitely help if you decide to go with option B, although I also rather like the simplicity of option A.

In any case, this will likely take a while, and your first priority will surely be to get the non-overlay version working out of process, since that is sort of a prerequisite for getting the overlay part working.

[PeridexisErrant]

I favor A, on the basis that it looks like it would be relatively easy to keep extending it into a full front-end replacement and give DF a decent interface. Obviously far future, but it sounds elegant and flexible enough to justify the extra time now.

[Rose]

There's two options for the overlay right now.

A: Send the DF screen to stonesense, and send key commands back.
B: Send the stonesense screen to DF, and overlay it there.

I'm leaning on A, but I haven't decided anything yet.

What I personally really want is to be able to play DF switching between TwbT graphics in 2d mode and a stonesense powered isometric view at will with a single keypress. Either approach could support that, since it would be easy to allow for displaying the non-overlayed screen in the second process's window.

I can definitely help if you decide to go with option B, although I also rather like the simplicity of option A.

In any case, this will likely take a while, and your first priority will surely be to get the non-overlay version working out of process, since that is sort of a prerequisite for getting the overlay part working.

You can help with either option, actually, since I currently know nothing about reading from the DF screen or writing to it. It's mostly black magic to me.

[Rose]

So I realized that I was going about the conversion to an external app in entirely the wrong way, and the way I'll be doing it now means that it can still work in the meantime.

[Jiri Petru]

There already is a tool that can replace the game's UI for the most part and send keypresses back to the game - Mouse Fortress. It hasn't yet been developed into a proper overlay with menus and buttons etc., but that shouldn't be much of a problem should it? See my thoughts on the topic. I don't really understand how this ties back to Stonesense and the work you've guys done with your overlay, but it would be a shame if the same work were unnecessarily done twice by different people.