Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Roses

Pages: [1] 2 3 ... 131
1
Utilities and 3rd Party Applications / Re: DFHack 50.11-r2
« on: November 01, 2023, 09:29:14 pm »
Extending the custom-raw-tokens functionality to support your use case is likely possible too. If you need it, others might as well.

Yeah, it's something I am looking into as well. Reading through the code I think it would be possible to extend it to encompass my use case, but I've gotta think more on what that would look like.

2
Utilities and 3rd Party Applications / Re: DFHack 50.11-r2
« on: October 31, 2023, 06:59:27 pm »
<sniped>

Thanks, that all sounds like it's fairly similar to the old system, just moved around a little. Should make my plans much easier.

Custom tokens - I see that custom tokens are now supported by DFHack, which is very nice. I had previously done this using curly brackets and parsing the raws when the game was started (see examples below). Looking through the custom-raw-tokens.lua code it seem that multi-line tokens aren't a thing though, is this correct? No problem if it is, I can just change my stuff to be a single line(s) as needed.

Hi, yea, custom-raw-tokens' dev (wolfboyft) here. I'm glad you like it! It's been a while since I made it, I don't really remember the reasonings behind everything, but yeah, it does indeed only support single line tokens, and only once in an instance of item subtype or whatever. It's just a search for the first instance of a token, returning the token's extra info. It's basically just for simple key:value(s) stuff, not working with/like the raw parsing state machine, like vanilla tokens often do. It's not super gorgeous in how it does it either, in that multiple instances of a tag don't raise errors (iirc), etc. Multi-line tokens would be pretty cool, though. I can't think off the top of my head how they would work, but I've forgotten a lot so...

Glad to see some interest! Good luck with your projects.

Hmm, only allowing a single use of a token per raw and it just being simple key:value means it probably won't work for my intentions. I'll have to see what I can do. I'd rather not go back to using the curly bracket method, but it might be the simplest method. I'll have to think about it some more.

3
Utilities and 3rd Party Applications / Re: DFHack 50.11-r2
« on: October 31, 2023, 01:00:24 pm »
I've got to say, I am very impressed with the amount of work that seems to have gone into the many many changes since I was last active. I have been spending a lot of time reading the documentation and looking through examples and it has been very exciting. I am sure I am going to have more and more questions as I read more, but the following are some of the first questions that have come to my mind.

List of Questions:
  • Custom tokens - I see that custom tokens are now supported by DFHack, which is very nice. I had previously done this using curly brackets and parsing the raws when the game was started (see examples below). Looking through the custom-raw-tokens.lua code it seem that multi-line tokens aren't a thing though, is this correct? No problem if it is, I can just change my stuff to be a single line(s) as needed.
Code: [Select]
[ITEM_SHIELD:ITEM_SHIELD_EXAMPLE]
[NAME:Example Shield]
{DESCRIPTION:Knocks enemy backwards half the time when you block}
... DF Item Stuff ...
{ON_BLOCK}
{SCRIPT:unit/propel -unit OPPONENT -source BLOCKER -velocity [ 50 50 0 ] -mode Relative:50}

[ITEM_WEAPON:RAPID_FIRE_CROSSBOW]
[NAME:Fast Shooting Crossbow]
{DESCRIPTION:Shoots bolts very fast}
... DF Item Stuff ...
{FIRE_RATE:10:2:1} -- Base fire rate is 10, increases by 2 for each skill level, max shot speed is 1

[ITEM_WEAPON:BLOOD_SWORD]
[NAME:Blood Sword]
{DESCRIPTION:Drains blood from opponent when wounded}
... DF Item Stuff ...
{ON_WOUND}
{SCRIPT:unit/change-body -unit OPPONENT -blood \-10:100}
{SCRIPT:unit/change-body -unit HOLDER -blood 10:100}
  • Mod paths and installation - This seems like its a fairly large change. We used to just drop stuff in the "raws" folder or put them in the hack/scripts folder, but now it seems there is an official way to handle mods (reading through the modding guide and the DFHack documentation). I noticed the mod makers development section in the DFHack guide which is very nice (and likely how I will use things most), and I also noticed that it is much easier to change vanilla raws without editing them directly (also very nice). My main question here is; are there any limitations in the new system that weren't in the previous? My previous work has dozens of lua scripts (some runnable, some just as functions for others) across many different folders. Are subfolders still allowed, or does everything have to be flat in scripts_modactive and scripts_modactive/internal?
  • Persistance - Previously, for large amounts of information, I just manually saved a lua table to a json file periodically (and on save) and then read it in on game start, and for small amounts of information (e.g. a script callback) I used the persist-table.lua functionality. Is this still the best way to handle persistant data storage and function callbacks, or is there a more "modern" way?
  • Syndromes - I used to have a working class system with spells and such. I did this using syndromes which were attached to custom inorganics that didn't have the tags to appear in the world. I am wondering if that is still the best way to handle this type of system, or if there would be a better way to handle unit based modifications (like changing displayed name and adding interactions)?
  • DF Structures - Similar to the above, my class system allowed for custom attributes (e.g. Perception). Because the DF structures were fixed, you couldn't just add another body or mental attribute to the list and have it work, so I had to write a wrapper function around the C++ function wrapper which returns the attribute values. I'm guessing the structures are still fixed (wouldn't make much programmatic sense for Toady to make them mutable), but I am wondering if there has been any work on the DFHack side of things to track things like custom DF structures.
  • Custom Files - Where should custom files that aren't techincally raw objects or scripts go? For instance, my old codes would read files like;
    Code: [Select]
    0,0,1,0,0
    0,0,1,0,0
    1,1,T,1,1
    0,0,1,0,0
    0,0,1,0,0
      and parse that to understand what tiles to target. Another example would be a mod specific configuration file that would be read once when a game is started?

I think that is good for now. I am sure that as I get deeper into getting my old codes running I will have more questions.

4
Sounds like a perfect place for me to start. Luckily I wrote a bunch of tests for my stuff before I stepped away so I should be able to help track down what is still working, and what needs updates.

5
Interesting. Do you know if the eventful plugins have been updated for v50?

6
So I'm finally thinking about getting back into DF and continuing the modding I was previously doing. I'm trying to catch up on all the changes (amazing work everyone!) But just wanted to check, is the LUA API reference stuff up to date? I use the function wrappers and plugins quite a lot and just wanted to make sure.

7
Wonderful work! Very excited to try all the new features

8
Utilities and 3rd Party Applications / Re: DFHack 0.47.05-r8
« on: December 31, 2022, 02:35:11 am »
On the DFHack side of things, has there been (or are there any plans to) changes to the persistent storage stuff? Previously I was using that heavily, but I moved to mixing it with writing/reading a basic JSON file when the game was saved/loaded. Wondering if I should keep doing that or if I should go back to using the persistent storage, or if I should use a completely different system?
We implemented a persistence API some time ago (in DFHack 0.44.12-r3), using JSON written to a cosave file in the game folder.

Awesome, sounds like it basically just does what I was doing already, so it's nice that there is an API for it now.

Yes, internally, DF works about the same (for the most part).

Regarding DFHack, persistent storage itself hasn't changed much, but the way plugins and scripts keep state has changed a bit. There is a much stronger push for tools to persist the state that players set while playing. The rallying cry is "initless", since the idea is to allow players to use DFHack tools effectively with zero init file editing (though init files still work if that's how the player wants to do things). As part of this effort, scripts have gained a way to automatically re-enable themselves according to their saved state. Before, a player would have to explicitly run a script (either manually or from an init file) before the script would have a chance to check any saved state. This prevented scripts from automatically reloading their state and continuing where they left off.

Now, scripts have a standard way to load state and set hooks at DF startup like plugins have always enjoyed: https://docs.dfhack.org/en/latest/docs/dev/Lua%20API.html#enabling-and-disabling-scripts

In UI news, the DFHack widget library is getting an overhaul. Two overhauls, actually. The current widget library is getting a lot more mouse support, like dragging, resizing, and being able to scroll the widget under the mouse cursor with the mouse wheel.

We're also working on an entirely new widget API that will allow much more "professional" UIs. This is still in the experimental phase, but it's coming along nicely.

Another big advancement is the DFHack overlay, which allows you to easily inject information and functionality into existing viewscreens. See https://docs.dfhack.org/en/latest/docs/dev/overlay-dev-guide.html

So, fun times ahead for modders : )

Interesting, so it sounds like I should do some real digging into the changes, from a cursory glance it seems a lot of the more esoteric things I was doing are now available through actual hooks and API interfaces. Should greatly simplify a lot of things, and hopefully make what I was doing more consistent.

The widget library overhaul also sounds very nice, so I am definitely just going to scrap all the stuff I was doing that was UI based, and come back to it once the changes move out of the experimental stage (or maybe I'll play with the experimental stage a bit).

Guess it's time to dust off the ol' lua scripting hat

9
Utilities and 3rd Party Applications / Re: DFHack 0.47.05-r8
« on: December 30, 2022, 06:15:21 pm »
Thanks, makes sense that any UI related information will be different, I think I will hold off on trying to do any of my previous UI work as I can foresee that changing a lot with the new graphics stuff. Where information is stored is too be expected I suppose as it usually changes somewhat every DF release. I guess I will have to just see what might have been impacted with what I use, but at least it seems like, beside the UI stuff, I can still work with what I was doing prior to my hiatus.

On the DFHack side of things, has there been (or are there any plans to) changes to the persistent storage stuff? Previously I was using that heavily, but I moved to mixing it with writing/reading a basic JSON file when the game was saved/loaded. Wondering if I should keep doing that or if I should go back to using the persistent storage, or if I should use a completely different system?

10
Utilities and 3rd Party Applications / Re: DFHack 0.47.05-r8
« on: December 30, 2022, 03:47:01 pm »
So I'm thinking about getting back into modding after years away, but I was recently reminded that the Steam version was released and have been reading through this thread to try to understand the impact of that release. Are there any immediate changes that I should be concerned about? I know I saw that ruby is planned to not be supported anymore, but I only wrote in lua anyway so that doesn't impact me. Nothing else jumped out at me, but I'm unsure if there was something I missed.

11
Utilities and 3rd Party Applications / Re: DFHack 0.47.05-r3
« on: December 09, 2021, 02:31:10 pm »
Very interesting. Thank you

12
Utilities and 3rd Party Applications / Re: DFHack 0.47.05-r3
« on: December 09, 2021, 11:09:10 am »
That might be the one thing you can't do with tiletypes - there's no MUDDY FLOOR shape, no MUDDY STONE material, no MUDDY special, and no Muddy option.
That's because there is no generic "MUDDY" flag (like there was back in 40d) - you have to create a "material_spatter" event with its material set to MUD:NONE (and state set to SOLID), add it to the map block in question, then set the "amount" for the appropriate tile within it.

Unfortunately, there don't appear to be any plugins or scripts which do this, but it shouldn't be too difficult to write a new one - it's mostly the same process as creating new mineral veins (which is supported within at least one plugin).

Out of curiosity, is it the spatter that facilitates farming, or does another flag get set when the spatter is detected?

13
DF Modding / Re: Sentient weaponry, Modding questions
« on: September 28, 2021, 03:43:13 pm »
Sharpness isn't a token you can assign to creatures. Also, there isn't the framework in the game to account for attacking with a creature, only items or your own body parts.

14
Small update, finally got around to pushing the changes to Enhanced Items so that only equipping an item as a piece of armor or using an item as a weapon will trigger the OnEquip and OnUnequip flags. Later I will put trigger flags for things like OnStuck, OnBandage, etc...

The Journal and Detailed Unit Viewer GUIs are also almost finished updating, all the new functions have been written and they have been moved into my new GUI system (which should make it a lot easier for me to write other GUIs going forward). The only thing left is to add all the functionality that the old GUIs had, and to make sure that they work on heavily modded games (and don't take forever to load)

15
Update to the Enhanced Item System. Previously the {ATTRIBUTE and {SKILL shortcuts were not working correctly. This fix makes sure that they are. Note that the changes when equipping/unequipping is currently happening when the item enters/exits the units inventory. Meaning a unit that picks up an item to haul it will experience the change. In the next update I will limit the equipping/unequipping changes to actually wearing/using the item, and I will add a OnPickup/OnDrop functionality for those that want something to happen on pickup/drop.

I'm going to step away from the Enhanced Systems for the next couple of updates (except for minor updates like the one above) as I get the journal and compendium back up to snuff.

Pages: [1] 2 3 ... 131