Print

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

[lethosor]

Is stonesense maintained by anybody? There seems to be an issue where constructed walls & floors are using the sprite for smoothed stone walls & floors, rather than the sprite for constructed walls.

I always dread questions that start out like that, because the question usually contains "Stonesense is crashing" and the answer is usually "no". This is probably one of the most benign issues I've heard of with it. But unfortunately, we don't have anyone around who's familiar with Stonesense any more, and I don't really know how to fix that either. (Stonesense is pretty broken on macOS, and even more so on newer versions due to Stonesense's architectural choices, so I don't have a good way to develop it or test fixes.)

@bloop_bleep: Firstly, why do you perform all of these narrowing type conversions, rather than keep the original types?

Haha, believe me, I tried. It usually happens in the case where I’m dividing two values, and I can’t seem to be able to find the right combination of types such that the division is allowed and works as expected while also the end result matches the type desired by DF.

I mean, on principle, I don't want to tell you how to disable warnings, because you should fix the warnings instead. What types specifically are you trying to divide? What's the warning you're getting? Can you give an example (or all) of the code you're trying to compile?

As for explicit typecasting, I might do that, but honestly sometimes I just can’t be bothered. Besides, it produces the same effect, and probably hurts readability.

Yeah, I was about to suggest typecasting everything as an ugly solution.

If you know, is there any way to set compiler options globally (i.e. for the entire DFHack build)?

Absolutely, but it requires recompiling literally everything.

Additionally, could I have the username of the person who wrote steam-engine.cpp, so I could message them.

You can answer this with "git log" or on GitHub: go to https://github.com/DFHack/dfhack/blob/master/plugins/steam-engine.cpp, click "History", and go to the end. That takes me here. (Angavrilov = ag on the forums, although he hasn't been active in a long time.)
I can try to ask questions about steam-engine... are they about the code in general or specific features of the plugin?

Edit: if it's this:

I have two questions.

• df::item::addWear takes three arguments, an int16_t (which I assume is the amount of wear) and two other Booleans. What do these last two arguments mean? I ask because steam-engine.cpp seems to use both the (true, false) and (true, true) combinations, and neither of these seem to actually change the wear value when inspected with lua.

the answer is in df.items.xml in df-structures:

Code: [Select]

            <vmethod ret-type='bool' name='addWear'>
                <int32_t name='delta'/> <bool name='simple'/> <bool name='lose_masterwork'/>
            </vmethod>
Vmethod parameter names don't get transferred to the generated headers like field names do, unfortunately.

[bloop_bleep]

The code is at this git repository. (Erm... sorry about the inconsistent tabs/spaces. I haven't noticed that before, since kate displays them the same. I'll fix it next commit; in the meantime your text editor should be able to replace one with the other, or you could just look past it for now.) Looking at some of the warnings in the compilation log, I actually have no idea why some of them are there, given that none of the types involved are defined in my code...

For example, lines 259-263:

Code: [Select]

        return df::coord {
            pos.x - ref.x,
            pos.y - ref.y,
            pos.z - ref.z
        };

gcc warns on the middle three lines that

Code: [Select]

home/misha/df_linux/dfhack/plugins/moving-machines.cpp: In member function ‘df::coord MovingMachine::get_rel_pos(df::coord)’:
/home/misha/df_linux/dfhack/plugins/moving-machines.cpp:260:19: warning: narrowing conversion of ‘(((int)pos.df::coord::x) - ((int)((MovingMachine*)this)->MovingMachine::ref.df::coord::x))’ from ‘int’ to ‘uint16_t {aka short unsigned int}’ inside { } [-Wnarrowing]
             pos.x - ref.x,
             ~~~~~~^~~~~~~
/home/misha/df_linux/dfhack/plugins/moving-machines.cpp:261:19: warning: narrowing conversion of ‘(((int)pos.df::coord::y) - ((int)((MovingMachine*)this)->MovingMachine::ref.df::coord::y))’ from ‘int’ to ‘uint16_t {aka short unsigned int}’ inside { } [-Wnarrowing]
             pos.y - ref.y,
             ~~~~~~^~~~~~~
/home/misha/df_linux/dfhack/plugins/moving-machines.cpp:262:19: warning: narrowing conversion of ‘(((int)pos.df::coord::z) - ((int)((MovingMachine*)this)->MovingMachine::ref.df::coord::z))’ from ‘int’ to ‘uint16_t {aka short unsigned int}’ inside { } [-Wnarrowing]
             pos.z - ref.z
             ~~~~~~^~~~~~~

despite that pos and ref are both of type df::coord. Note that gcc says that the coordinate values are casted to type int, though they clearly aren't. This is truly baffling.

[FantasticDorf]

Is stonesense maintained by anybody? There seems to be an issue where constructed walls & floors are using the sprite for smoothed stone walls & floors, rather than the sprite for constructed walls.

Similarly it is lacking some artistic assets like stuff for pedistals/ + objects (plus probably instruments) which would be really neat introduced in the newer version since right now they are replaced by yellow empty boxes, i don't think @Dirst is still availbile but watching this space if any of us can pull together for a collaborative art project to maintain it i think would be useful.

A third party tool to draw/view file XML images might be useful in this regard, unless other such applications already exist.

[Clément]

...

I found some explanations here.

[bloop_bleep]

...

I found some explanations here.

Well that is truly strange. Subtract two int16_ts and get an int, which generates a warning when you try to stuff it into another int16_t. Using explicit typecasting would be very messy and confusing, as well as not at all necessary, so in this case I’d rather just disable these specific warnings. If anyone could inform me how to do that it would be greatly appreciated.

EDIT: Thank you, lethosor, for where to find parameter names. Guess the problem is not the Boolean arguments, then, even though I thought I made sure that df::item::addWear was being called with the correct wear delta... Does it not do what I think it does? That is, does it not change the wear member variable of the item?

[Silverwing235]

A third party tool to draw/view file XML images might be useful in this regard, unless other such applications already exist.

So, maybe something like this would be appropriate, unless I'm badly misreading the request here, let alone outright mistaken? 

[Clément]

Why are your warnings mentioning uint16_t, if int16_t are used in df::coord? The reason it is cast to int is the same: C/C++ doesn't do operation on types smaller than int. But there maybe something more.

-Wno-narrowing disables the warnings for gcc, but it may hide warnings in other places where it would be useful.

[bloop_bleep]

Why are your warnings mentioning uint16_t, if int16_t are used in df::coord? The reason it is cast to int is the same: C/C++ doesn't do operation on types smaller than int. But there maybe something more.

-Wno-narrowing disables the warnings for gcc, but it may hide warnings in other places where it would be useful.

Yes, but I would like to know how to set certain compiler flags for a specific plugin, or failing that, DFHack in entirety.

[Clément]

Try target_compile_options.

Nevermind, try DFHACK_PLUGIN(pluginname COMPILE_FLAGS_GCC options_here) instead.

[Rumrusher]

in should have tested this sooner news I found away to bypass blocks on entering the travel menu, uhh I realized I should have just deleted the message that pop up using  dfhack which boots you directly to freely move where ever. so folks in flight can just write a script that clears the "you can't fast travel if your in the air' message and be able to move around the map whereever and whenever.
sadly this doesn't say help when you can't move to activate the fast travel mode like say being surrounded by all sides but it's a start.

this also means one could write up a script to fast travel during the cackling.
Though it's possible to just clear the bogeyman timer in the UI_advmode section to do that.

or probably when one's bleeding to death.

[bloop_bleep]

More questions!

How does PersistentDataItem... um, work? That is, what functions am I supposed to call and when? I only have to retrieve data with a certain key when the world is loaded and save data when the world is unloaded. E.g., do I need to call anything special when I get an SC_MAP_UNLOADED event or do I just modify the value of the PersistentDataItem? And do I call GetPersistentData again in the store_data function or do I keep the PersistentDataItem that I obtained in the load_data function?

A simple code skeleton to demonstrate this would be greatly appreciated.

[lethosor]

What language?
For C++, autogems uses it in a fairly simple manner. autochop is a little more advanced.

[bloop_bleep]

C++, please.

As for autogems, I couldn’t glean much useful information from that because it didn’t use the string member of PersistentDataItem, just the integr values. I looked at workflow earlier, but there was so much surrounding code and not very many comments so I couldn’t parse that at all.

In my case, just to clarify, I’m trying to make it so that when the map is loaded, it attempts to read the a single persistent data item and unpack the binary data, but do nothing if it doesn’t exist. When the map is unloaded, it writes to the item with the same key, and does create it if it doesn’t exist.

EDIT: And the problem arises from the fact that whenever I boot up a save with plugin data saved, it says that the return value of GetPersistentData is valid, but the size of the binary data is inexplicably only 1 byte, which causes my unpacking function to crash. Which is why I was thinking I wasn’t saving the data properly.

[lethosor]

The string member is a string, which means that if you're storing arbitrary binary data in it, it will get truncated at the first null character.

If you can't represent your data as a <16KB ASCII string, you might want to use a different solution, like files. One feature of DF is that any .dat files in data/save/current will get copied into the region folder when the game is saved. You can copy them from the region folder when the game is loaded yourself, read/write to them there, and DF will take care of making sure they're only copied back when the game is saved. Of course, you'd want to avoid excessive reads/writes for performance reasons (one benefit of the PersistentData API is that everything is in memory).

[lethosor]

0.44.12-r2 is up (finally): https://github.com/DFHack/dfhack/releases/tag/0.44.12-r2

It contains fixes for several longstanding issues from r1, including issues with ui.main and ui.squads, which broke "tweak hotkey-clear" among other things. I'm sorry it's taken this long to get these fixes out, and merge some people's additions. Real life happened and this kept getting delayed.

I think we could use more active people on the "core" DFHack team (i.e. the GitHub org) - I'd much rather have other people reviewing pull requests than have me continue to be a bottleneck. If you're decently familiar with the DFHack codebase, or interested in DFHack development in general, feel free to shoot me a PM or reply here. There's not much onboarding to speak of, unfortunately; documenting our GitHub workflow has been on my list of things to do for a long time, and I will try again to get that done soon. Let me know if anything else would be useful for devs new to DFHack as well.

Anyway, many thanks to BenLubar for maintaining and fixing the build server earlier today. Also, thanks to those who contributed to this release in any way. I had to enforce a "feature freeze" of sorts, so I know some PRs didn't make it in, but I'll do my best to get r3 out quickly with those included.