Any active modders?

[Night]

Looking to start collaborating more with the community, any active modders working on anything? I've been considering making some mod tools to make modding more user-friendly, but I'm not to familiar with the modding syntax myself, could be cool to see what I could come up with alongside someone who knows the modding syntax well.

I've also considered making a GFX manager to handle truetile and truegfx folders for custom sprites and gfx, but I haven't investigated too much, are people still doing GFX overhauls?

There are many other things that could theoretically be done with the current mod system + memory editing, but are more likely to be bug prone.

Anywho, if anyone wants to start something or just wants to talk about theory let me know, maybe we could get a group chat started somewhere.

edit: forgot to mention I also do pixel art, so if someone is looking for GFX for their mod, that is something I can also assist with, examples of my work:
https://www.deviantart.com/dr-night/art/Digital-PS-Icon-snapshot-2-763501321
https://www.deviantart.com/dr-night/art/Digital-PS-Map-1-763618568


edit: Contact info for mod makers looking to collaborate:

Steam: https://steamcommunity.com/id/Nightipoo/
Skype: xxvnightvxx (easiest place to reach me)
Discord: Night#9736

[Cromithian]

Firstly and foremost thanks to "Jack-jackspack, Brygun, JCM, Sufficency, Njerpez, and whomever else contributed to these mods. i am just edditing them so they all work in cohesion.

I'm not really a modder per say, but i have taken a few mods and put them together, they work, tho I do need more gfx/truetile for the items as using the same gfx/truetile (as in [it-punt) seems to make the punt disappear as soon as you use it.. it's there when you drop it but move even one space it turns invisible, its still there just can't see it. I'm still working on some kinks like the F1 encyclopedia,for descriptionsof "basicaly everything in the mod" also i think i should remove Iron, as copper/bronze were used first, I do know how to make any type of item for/in the game. If I knew how to make a "sub-menu's" "[sub-menu]" or a menu in a menu, Id be able to add anything, but some might say that would be too much, I would have a menu like; "metallurgy"-"[Copper]"-"[{Smithing}]"-"[{(Forging)}]"-"smelting".... "metallurgy" would be the main in the *make* menu with "[Copper]",
"[Bronze}", "[Tin]", and lastly "[Iron]" as its sub-menu's, with each having the "[{Smithing}]" menu and the "[Smithing]" menu's having "[{Forging}]" menu.. the
"[Smithing]" menu's would also have "Sharpen", "Polish", (and then finished  weapons/crafts/tools), while '[{forging}]" would have things like "smelting" and parts for (weapons/crafts/tools) well some parts such as a spear shaft would be in the Lumber/woodcraft/carpentry/bone-working sub-menu's while the "Spearhead" would be in the metal/stone sub-menu's, and the only thing i'd need to do to add it in game is look up each "Item's Process" like i just looked up Bronze, its 'copper' and lithos 'stone'. so basically smelt copper with a "rock" for bronze if you don't want to add another "rock" type into the game and not all the above is necessary. just an example. (will put into "fake" diy_Metallurgy as proper a example under the link)... I will also add my "so-far" full 3.52 redone with my Character if you want to check it out "still has some issues i'm learning to work out, but I think I Know why there is a disappearing act on the Transportation.. as I mentioned above..

An accident, probably frequent, reveals another of nature's useful secrets. A nugget of pure copper, or perhaps a finished copper tool, falls into the hot camp fire. The copper melts. When it cools, it is found to have solidified in a new shape.

(link to where i found this)
Read more: http://www.historyworld.net/wrldhis/plaintexthistories.asp?historyid=ab16#ixzz66r06TNg1

//first is the (menudef_Fake) that would be added

.Metallurgy. -1- *MAKE*
.Smelting. -1- *METALLURGY*MAKE*
.Copper. -2- *METALLURGY*MAKE*
.Smithing. -1- *COPPER*METALLURGY*MAKE*
.Bronze. -3- *METALLURGY*MAKE*
.Smithing. -1- *BRONZE*METALLURGY*MAKE*

(hmm I haven't tried this layout before. I have tried a couple others,with no luck. So I will have to see if this might just make a sub-sub-menu)... anyway now on tho the diy

(file name) diy_metallurgy<--(if done as it's own file)
(contents)                                          |
[SUBMENU_START:Metallurgy]<------ _  /
       OR         (the capital letter does matter after the SUBMENU_START:  )
[SUBMENU_START:metallurgy]<---(if done in the diy_glossary file)  (for this one I will act as if it is a separate file) I could describe each part of this procedure, but that would take more time then I have at the moment. If I could also figure how to add skills i'd add *METALLURGY* where *COMMON* is , I could also put *CARPENTRY* or *AGRICULTURE* instead. but.... and also please this is `fake' I don't know how to make SUB-SUB-menu's (YET)

[SUBMENU_START:Metallurgy:Smelting]

.Copper. -1- [Effort:1] [phys:hands] %-65%  *COMMON* /1h/ \45\ [Patch:10]
{charcoal} (20) [remove] [patchwise]
{forge}
{crucible}
{tongs}
{*hammer} <iron hammer> %=40%
{*anvil} <iron Anvil> %25%
[WEIGHT:1] [TILEGFX:cpr-ingot]

.Bronze.  -2- [effort:1] [phys:hands] %-65% *COMMON* /2/ \1\ [patch:10]
{charcoal} (30) [remove] [patchwise]
{rock} [Remove] [patchwise]
{forge}
{crucible}
{tongs}
{*hammer} <iron hammer> %+40%
{* anvil} <%25% [WEIGHT] [TILEGFX]:[br_ingot]

[Night]

Firstly and foremost thanks to "Jack-jackspack, Brygun, JCM, Sufficency, Njerpez, and whomever else contributed to these mods. i am just edditing them so they all work in cohesion.

I'm not really a modder per say, but i have taken a few mods and put them together, they work, tho I do need more gfx/truetile for the items as using the same gfx/truetile (as in [it-punt) seems to make the punt disappear as soon as you use it... -

I'd like to work directly with someone on playing with these sorts of things, moving beyond what the current modding capabilities offer, or streamlining the creation process by creating a tool to assist with mod making. I could probably remake the entire crafting system, but I lack control over turn processing, so albeit possible, it would lack the same feeling as the base game (craft item > time passes instantly > no gametick updating) but it would open up a vast array of item manipulation tools, which could be translated into usable features for example, you could track an items age that you have crafted and add decay to the item over time, or even "upgrade" an items quality. Many other things are possible. I have many ideas on my mind, NPC creation, localmap editing import/export, random events. Working along side someone familiar with the modding system would help me understand more about what type of implementations of this will feel and look good.

[Privateer]

 Just spit balling;

One of the 'issues' with mod 'creativity' is that it must all be defined in flat file prior to playing.
@Weathereye made a cool windows app? that allowed for more simple swapping in and out mods https://www.unrealworld.fi/forums/index.php?topic=67.0

Being able to ADD item(s) to craftable files based on some goal, ie: learning bone craft or metal working.
Would provide an environment where things like 'shaman mod' could exist.

[Night]

Just spit balling;

One of the 'issues' with mod 'creativity' is that it must all be defined in flat file prior to playing.
@Weathereye made a cool windows app? that allowed for more simple swapping in and out mods https://www.unrealworld.fi/forums/index.php?topic=67.0

Being able to ADD item(s) to craftable files based on some goal, ie: learning bone craft or metal working.
Would provide an environment where things like 'shaman mod' could exist.

I'll check that app out, as for your idea, I believe that's 100% possible, even with a simple hacky work-around, you could require an item that isn't craftable by the player and call it a "perk" for example, and when certain conditions are met you could implant this into the characters inventory, allowing them to then use the recipe, you could even control the quantity of the "perk" item to indicate the level of the perk. It would then be a matter of what condition would be required to be fulfilled  by the player in order to obtain the perk, and then detecting that in memory, which could be as simple or difficult depending on what kind of condition you'd like to achieve, for example reaching certain stats or acquiring items would be on the simple side where as things like tracking data over time would be slightly more difficult, and then even more difficult than that would be tracking steps overtime for a more quest-like feel, but this should all be within the realm of possibility.

That app might be of interest in the overall scope of organizing mods, I might pm @Weathereye and see what his thoughts on it are.

[aat]

I think that's great that you are delving into memory editing of URW.

We need to think what are the main limitations of the current system and what memory editing can do.

One current limitation is that not all object properties can be set in the txt files. I'm thinking of

• Accuracy
• Works as a ski stick
• Works as a beater

And many other hidden properties.

Ingredient matching is based on names or object property inheritance. If you inherit from "Club", your object will match the "Beater" ingredient; or if you inherit from "Northern spear" you will be able to use the object as a ski stick.

Would be nice to have direct control of these hidden properties, and even define new ones, so that we are not limited to name matching.

A concrete example would need having a [TAG:property1] syntax, to assign to a object, and then being able to require such type of ingredient with the {[TAG:property1]}. Much more diversified and streamlined recipes.
But I'm not sure if this would really be feasible only with memory editing

Some other limitations are intrinsic to the recipe system. For example, you can make only one type of object at a time (no multiple products from a single recipe).

Another limitation is that we can't add new buildings.

Finally, if memory editing really enables more modding possibilities, they would be limited only to the windows platform, right?

Anyway, I'm currently working on a mod, which is an evolution of caethan self sufficiency mod.
https://github.com/pietralbi/urw-extended-recipes

I'm not really a pixel artist, so I'm ignoring all the custom sprites for now and just focusing on the recipes themselves. I was planning at the end to slowly and painfully do the artwork with gimp, but if you can make the icons instead it would be great!!!

[Night]

I think that's great that you are delving into memory editing of URW.

We need to think what are the main limitations of the current system and what memory editing can do.

One current limitation is that not all object properties can be set in the txt files. I'm thinking of

• Accuracy
• Works as a ski stick
• Works as a beater

And many other hidden properties.

I can access a bunch of these, its just a matter of documenting them and then combining them properly w/ or w/o an official mod, possibly making some sort of interpreter to read the mod files for custom script to apply could be a project.

Ingredient matching is based on names or object property inheritance. If you inherit from "Club", your object will match the "Beater" ingredient; or if you inherit from "Northern spear" you will be able to use the object as a ski stick.

Would be nice to have direct control of these hidden properties, and even define new ones, so that we are not limited to name matching.

Some of these are directly tied to other areas of code/data within the game, in particular I noticed I wasn't able to find some herb effects while documenting herb addresses in the item struct, I noticed that they changed when i edited some of the strings to a different base herb, probably indicating the default values are hardcoded or stored elseware, currently I've just been looking at CharacterName.OBJ file which contains the data for objects the game has generated over play time, the default object list is CONSTANT.OBJ, which could contain the data, but I haven't gotten around to looking at this in more detail as I'm mostly still documenting other objects generated by the game, some of which aren't included in CONSTANT.OBJ such as corpse's and different states of hides/meat cuts from cooked to uncooked, soaked hides, tanning hides, etc. There are some flags for weapons, but I haven't identified them with certainty, my best guess is some sort of identifier as to weather the weapon damages hides or not when used, but I haven't verified this, only a conclusion based on a comparison of weapons which lacked the value seemed to be non-edge based weapons. I don't have a Northern spear in my characters data so I'm not able to compare that currently, but if anyone would like to donate game files for research purposes I could certainly use them, as I want to have multiple comparisons of data files for the best estimate as to what data is what, additionally many people have far more progress than me in the game and generally have more save data to work with. I can also provide modified versions of files for testing purposes if someone would like to help me in documenting the effects of the data changes. Lot's to talk about on the subject of data and files, would be better to talk about it over IM.

A concrete example would need having a [TAG:property1] syntax, to assign to a object, and then being able to require such type of ingredient with the {[TAG:property1]}. Much more diversified and streamlined recipes.
But I'm not sure if this would really be feasible only with memory editing

You'll have to explain what you mean here better, I'm not sure what kind of limitations I have when it comes to recipes yet, I could possibly learn more by tracking a mod's recipe data (if i can find it), but I'm not familiar with the actual official modding syntax yet so I'd be shooting in the dark for a little while (not even sure how to install an official mod yet aside from copying over the main files? lol).

Some other limitations are intrinsic to the recipe system. For example, you can make only one type of object at a time (no multiple products from a single recipe).

This is probably possible to do with relative ease.

Another limitation is that we can't add new buildings.

This along with NPCs, terrain, possibly some other types of data may be possible to manipulate (in theory, likely) its only a matter of documenting the data and the addresses in memory. What this means to me is,

A. I need to know what I'm looking for in terms of what numbers I'm trying to find (for example, an item on the ground has an X Y location in memory).

B. The data needs to be editable, and the edit needs to create the desired effect to be a feasible modification (I edit the X Y location of an item on the ground, it teleports to the edited location, I now have the power to use this as an "action" for a mod, or as a "condition", such as determining if a particular item is at a particular location to trigger some other "action")

Usually, when I'm looking for a particular piece of data, other data relating to the object is also close by in memory, so finding one thing can lead to indications of other things within the data (hence documenting the item struct)

This is the main limitation of what I can do, I am nowhere near close to the best memory-editor's out there, as there are many other people who can manipulate sections of assembly code to change the way the game functions entirely, most of what I do is reliant on changing data that the code interacts with to produce the desired effects. I can do other hacky workarounds with C# and manipulation of the data and using C# code to create some hacky effects, but this can be hard to get stable (for example, I have created a feature for my next update of URWCharacterMenu that allows you to click on a tile, and teleport to it. I was unable to add support for zoomed-out views however, though it is probably possible the math required to do it is beyond what I'm willing to figure out to fix a minor inconvenience).

Finally, if memory editing really enables more modding possibilities, they would be limited only to the windows platform, right?

My app in particular would be limited to windows yes. I'm not familiar enough with other operating systems to say yes or no on their limitations, I do know their op-codes tend to be different, so it would be a matter of weather they have memory editing support for their operating system + a matter of re-documenting the data for that particular operating system, I think anyways. The data itself should be similar, so the methods for finding and documenting the data should be similar, I think. If anyone using linux or ios (if that's even supported, gosh I'm so ignorant!) wants to experiment on their side with this, I would be happy to provide the methods in which I have found my addresses, but they would be starting nearly from the ground up as far as creating an app that can read/write to memory, and the actual design of the app (be it a standalone mod or something that can interpret custom mod files to enable a richer scripting environment for that particular OS) Just my thoughts, I could be completely wrong.

Anyway, I'm currently working on a mod, which is an evolution of caethan self sufficiency mod.
https://github.com/pietralbi/urw-extended-recipes

I'm not really a pixel artist, so I'm ignoring all the custom sprites for now and just focusing on the recipes themselves. I was planning at the end to slowly and painfully do the artwork with gimp, but if you can make the icons instead it would be great!!!

Funny I was just looking at caethan's mod files the other day, admiring his work and efforts. I would defiantly be up for this, if you wanna chat more about it we can hookup on IM and get a workflow going on my side.

I'll be updating the main thread with some contact info, and I'm considering opening up a group chat on discord or somewhere else to get at least some connections/conversations started, forums are great for long, clear, thoughtful thinking but this is closer to sending a letter than having a conversation where our ideas can evolve at a more rapid pace.

edit:
Also just wanted to throw it out there, the more things we can get documented in memory, the higher the chances are someone (maybe myself, maybe someone else) can make things like map editors and tools not currently available, however the line is drawn where-ever the Enormous elk team decides to draw it, making mods to enhance the game is one thing but we need to respect the creators wishes as to what they want made publicly available, being that the game isn't inherently pay to play (protection wise, I believe), I don't want to be the guy creating tools that will create a run away effect where the game is effectively used as an engine, rather than enjoying and expanding its original content. It would be a dishonor to this games development history and DECADES of continuous passion from the developers, and for most of you this probably doesn't seem like it's a big deal, but I've developed and been apart of communities of developers and modders for several different games over many years, and I can tell you from experience, modifying memory can be fun, creative, innovative, and an overall enjoyable experience for everyone, but it can also ultimately, destroy an app from its core, for its developers and users. Most people are familiar with this experience in the form of multiplayer game cheats, such as aimbot and ESP in the case of FPS games, but there are many dangerous ideas that can be executed using reverse engineering processes which can have a longer lasting negative impact, It's only a matter of imagination and code. Just my two cents on it.

edit2: Spent a good amount of hours starting a guide on using cheat engine, should give anyone who wants a swing at it a good chance to succeed. I'll be posting it when I have completed it.

[aat]

Some of these are directly tied to other areas of code/data within the game, in particular I noticed I wasn't able to find some herb effects while documenting herb addresses in the item struct, I noticed that they changed when i edited some of the strings to a different base herb, probably indicating the default values are hardcoded or stored elseware, currently I've just been looking at CharacterName.OBJ file which contains the data for objects the game has generated over play time, the default object list is CONSTANT.OBJ, which could contain the data, but I haven't gotten around to looking at this in more detail as I'm mostly still documenting other objects generated by the game, some of which aren't included in CONSTANT.OBJ such as corpse's and different states of hides/meat cuts from cooked to uncooked, soaked hides, tanning hides, etc. There are some flags for weapons, but I haven't identified them with certainty, my best guess is some sort of identifier as to weather the weapon damages hides or not when used, but I haven't verified this, only a conclusion based on a comparison of weapons which lacked the value seemed to be non-edge based weapons. I don't have a Northern spear in my characters data so I'm not able to compare that currently, but if anyone would like to donate game files for research purposes I could certainly use them, as I want to have multiple comparisons of data files for the best estimate as to what data is what, additionally many people have far more progress than me in the game and generally have more save data to work with. I can also provide modified versions of files for testing purposes if someone would like to help me in documenting the effects of the data changes. Lot's to talk about on the subject of data and files, would be better to talk about it over IM.

You'll have to explain what you mean here better, I'm not sure what kind of limitations I have when it comes to recipes yet, I could possibly learn more by tracking a mod's recipe data (if i can find it), but I'm not familiar with the actual official modding syntax yet so I'd be shooting in the dark for a little while (not even sure how to install an official mod yet aside from copying over the main files? lol).

Ahh I see you are not familiar with the modding system. It's actually very simple, much simpler than memory editing. I try to get you started here, because it can be extremely useful for the memory documenting process. You don't need to wait to find a Northen spear in-game, you can just make it!

This page on the wiki tells most of the things, I've been trying to update it with the things I've discovered via sperimentation:
www.unrealworld.fi/wiki/index.php?title=Modding#Item_Property_Parameters

In the main folder of UnReal World, open the diy_glossary.txt file. You can see this recipe for the shortbow, that you find in-game in the weapon's menu:

Code: [Select]

.Shortbow. [effort:2] [phys:stance,arms] *CARPENTRY* /320/ |2|
{Board} [remove]
{Axe} <Carving axe>
{Knife}
{Cord} =5= [remove]

This defines entirely the recipe for the object "Shortbow".

• [effort:] is how much fatiguing it is, from 0 to 5
• [phys:] is which physical condition you need to have (standing, no debilitating arm injuries)
• *CARPENTRY* means it uses the carpentry skill to determine the quality of the object (and maybe also modifies the duration of the craft)
• /320/ is the base duration of the craft in minutes
• |2| is a skill gain modifier for the CARPENTRY skill

Then there are the required ingredients listed below:

• {Board}: a board. that will be consumed in the process (removed from the inventory)
• {Axe} <Carving axe>:  an axe, preferably a carving axe
• {Knife}: A knife
• {Cord} =5= [remove]: A cord of 5ft  that will be consumed.

We can add any recipe for any object in-game in this way. For example, if you want to make 5 Northern spears, just write:

Code: [Select]

.Northern spear.    (5) *COMMON*    /0/   [effort:0]


Be sure to leave a blank line after. You don't need to close URW or reload a save: the recipe will be read on the fly while running.
You can see there are no ingredients specified here. This is basically a cheat recipe: you are creating 5 Northen spears, from nothing. instantaneously and with zero fatigue!

The above works for objects that have no recipe yet. Say that you want to test an object that has already a recipe, like the Shortbow, but you don't wont to modify the original. What I do is the following:

Code: [Select]

.Shortbow test. "Shortbow"   [effort:0]    *COMMON*   /0/
[NAME:Shortbow]


In the first line, the game will create a recipe for an object named "Shortbow test", which inherits all the properties (graphics, weight, uses and all hidden properties) of the Shortbow. If we leave like this, you would see in your inventory an object named "Shortbow test", but we don't want that.
That's why we override the object's name with the [NAME:Shortbow] syntax. In this way, the object created will have properties AND name of the Shortbow, and will "stack" with other Shortbows made with the original recipe.

Now, under the hood I don't know if the game is actually creating a NEW object which is game-wise indistinguishable from the original one, or if effectively it is still the original object.

I hope it was not too confusing.
Anyway, this is the way I am testing the mod as I'm developing it. I actually have a file in the game folder, named "menudef_testing.txt", with the following line:

Code: [Select]

.Testing. -Q- *MAKE*
This creates a "Testing" sub-menu in the crafting menu
Then I have a "diy_testing.txt" in which I write the recipes I use for testing:

Code: [Select]

[SUBMENU_START:Testing]

.Rye bread. (10)   *AGRICULTURE* /1/ |-2| [noquality] [effort:0] [phys:arms,stance,one-armed]
{[NEARBY_TILE:Hole in the Ground]} 'Dig a hole in'
{[TERRAIN:open_mire]} 'next to a open mire'

.Northern spear.    (5) *COMMON*    /0/   [effort:0]

.Paddle 2. "Paddle" *COMMON* /1/
{[TILE:water]} 'Be in the waters'
{[TERRAIN:lake]} 'in a lake' 
{Sesta} '+to probe the bottom'
{Net}     '+to scoop'

[SUBMENU_END:Testing]

-end
Using this syntax, you can quickly add any item to your inventory and check the memory address for a faster documenting process.

 By the way, I'm really waiting for you to release a Cheat engine that can fast forward/rewind time. This would be incredibly helpful in testing modded plants and agriculture, since waiting months in-game is prohibitively time consuming for testing purposes.
 

Funny I was just looking at caethan's mod files the other day, admiring his work and efforts. I would defiantly be up for this, if you wanna chat more about it we can hookup on IM and get a workflow going on my side.

I'll be updating the main thread with some contact info, and I'm considering opening up a group chat on discord or somewhere else to get at least some connections/conversations started, forums are great for long, clear, thoughtful thinking but this is closer to sending a letter than having a conversation where our ideas can evolve at a more rapid pace.

Cool! That's great! I'm still working on the ironworking part, and then I need to test it for balance, but the weaving part is pretty much done, and I've already listed the many sprites I need for that part (in the code, I've commented with //Todo graphics). My time-zone is not really forgiving for IM, but I was also thinking about a discord group. Would be great to set up discord group for URW! To discuss about the game in general and even modding ideas.
-- Wait I've seen that you posted your contact. I will contact you soon-ish.

Also just wanted to throw it out there, the more things we can get documented in memory, the higher the chances are someone (maybe myself, maybe someone else) can make things like map editors and tools not currently available, however the line is drawn where-ever the Enormous elk team decides to draw it, making mods to enhance the game is one thing but we need to respect the creators wishes as to what they want made publicly available, being that the game isn't inherently pay to play (protection wise, I believe), I don't want to be the guy creating tools that will create a run away effect where the game is effectively used as an engine, rather than enjoying and expanding its original content. It would be a dishonor to this games development history and DECADES of continuous passion from the developers, and for most of you this probably doesn't seem like it's a big deal, but I've developed and been apart of communities of developers and modders for several different games over many years, and I can tell you from experience, modifying memory can be fun, creative, innovative, and an overall enjoyable experience for everyone, but it can also ultimately, destroy an app from its core, for its developers and users. Most people are familiar with this experience in the form of multiplayer game cheats, such as aimbot and ESP in the case of FPS games, but there are many dangerous ideas that can be executed using reverse engineering processes which can have a longer lasting negative impact, It's only a matter of imagination and code. Just my two cents on it.

I totally agree here.
On my side, I just wish more game mechanics were exposed to modding without having to resort to any hacks. I hope Sami can extend the modding functionalities after he finishes fleshing out the 3.60 updated.
I think mod help keeping games and communities alive. But of course, any exploitation you describe would be very dishonorable, given the passion and dedication this game has received and keeps receiving.
Would be nice to know the option of Sami here.
Maybe in the future the freeware version could become just a demo, since the donation-based has become dry? I think that many people even just download it to try the game after having seen it on Steam.

[Night]

- stuff i read

I'm mentally tired right now, been on a coffee binge for like three days and that cheat engine tutorial took longer than I thought it would to describe in detail (lol) so I'll probably make my reply short for now, maybe come back and add to it later if i get a second wind after some game time... -

I read what you wrote on the modding, described very well, and quite exciting for me - as I can potentially find recipe data in memory now, which would be a game changer for mod potential :O. Also kind of funny that you mentioned the time control thing as that's the address I describe the search process for in my guide, almost as if fate has it in sight... I'm thinking about releasing some standalone stuff, but mostly just ideas in my head at the moment, as most of the coding work I've been doing has been in relation to item struct, I've even decided to cut the release to just armor and weapons for the item editor for now, otherwise people are going to be waiting a long time for some pretty nice stuff in my opinion, and ya, waiting for perfect item manipulation can come after I release some cool stuff . Some standalone ideas I had:

• Console (included in my next release of URWCharacterMenu) - Would essentially allow for text based input to be processed and used for mods. In my mod this currently comes in the form of setting teleportation waypoints and using them, some other stuff too. Could probably be applied to the current modding system in some way.
• StuckFix - Would use XY location addresses to essentially fix your characters position in the unfortunate event they're stuck in some unintended way, for example spawning on an 1 tile island, or being blocked inside of a house.
• ScriptInterpretor - Would read recipe files and make memory modifications as needed upon reading custom script, high amount of documentation and stability testing would be required to make this mod seamless with URW, and would require the interpretor to be running alongside the game, with possible looped threads to update values. Would also need to be maintained and updated every time the game is updated to ensure accurate data read/write.

I've already listed the many sprites I need for that part (in the code, I've commented with //Todo graphics)

I'll check this out soon.

edit: also I'll work on the discord thing, and I wouldn't worry about your timezone too much, I've touched all hours of the day awake and asleep, pretty sure my circadian rhythm is permanently damaged. lol.