My hacky solution to the overcomplicated, impossible-to-follow timeline problem.

[flarn2006]

If you're like me, your UTA interface looks something like this:

And if you're like me, you would also not like this, and the knowledge that this is an inevitability and that it will only get worse is stopping you from experimenting nearly as much as you want. (It's especially bad when you're browsing the library.) Well I figured out a solution: a Lua script hack that makes it so once ENABLE_DEBUG_BUTTONS is turned on, it will stop saving checkpoints, and then you can set queenSpriteGaveHearts to True before changing areas when you want to save one. Before saving the checkpoint, it will automatically set it back to False.

Here's the guide I posted on Steam that tells you how to do this.

What do you think?

[KestrelPi]

If you're like me, your UTA interface looks something like this:

And if you're like me, you would also not like this, and the knowledge that this is an inevitability and that it will only get worse is stopping you from experimenting nearly as much as you want. (It's especially bad when you're browsing the library.) Well I figured out a solution: a Lua script hack that makes it so once ENABLE_DEBUG_BUTTONS is turned on, it will stop saving checkpoints, and then you can set queenSpriteGaveHearts to True before changing areas when you want to save one. Before saving the checkpoint, it will automatically set it back to False.

Here's the guide I posted on Steam that tells you how to do this.

What do you think?

Wow, I never got it looking anything like this. I can't imagine what I'd do to get it that way! But still, is there some way you can release this hack as a Steam Workshop patch?

[flarn2006]

I would but Steam Workshop just doesn't give the same flexibility from my understanding. Like you can't just paste the modified function right into the patch file. I tried cloning that Halcyon mod where it displays the old value, and from looking at the code it looks like a lot of complicated searching and patching was necessary for it to work. If there was an easier way I'd imagine that mod's developer would have done it that way.

I know the mods work the way they do (as in, with such limited access) to prevent them from containing malware, but I think it would be much better if it wasn't like that. Yeah, then there's the possibility of malware, but that possibility is there whenever you download any program from the Internet, and even mods for many games, like Minecraft for instance. Besides, I'd be surprised if knowingly uploading malicious mods wasn't against the Steam ToS. If someone uploaded malware, someone would report it, and Steam would (hopefully) remove it. Then ideally whoever uploaded it would be banned from SW.

[SmashManiac]

The Halcyon mod is a pretty bad mod example actually. Even the author admits about over-complicating everything.

From my understanding, making a mod out of this should be relatively easy, since you're only adding a few lines of code. You don't even need to convert it to assembly manually - just load your code as a function in a sandbox mod and dump the results with my Disassembly Dumping mod. The only patching you would need to perform is on your own code to make sure that the instructions point to the correct constants, but that's it. Let me know if you need help with this.

Thanks for crediting me in your guide by the way.

[flarn2006]

The Halcyon mod is a pretty bad mod example actually. Even the author admits about over-complicating everything.

From my understanding, making a mod out of this should be relatively easy, since you're only adding a few lines of code. You don't even need to convert it to assembly manually - just load your code as a function in a sandbox mod and dump the results with my Disassembly Dumping mod. The only patching you would need to perform is on your own code to make sure that the instructions point to the correct constants, but that's it. Let me know if you need help with this.

Thanks for crediting me in your guide by the way.

You're welcome! I know it's not something you came up with yourself, but you presented it in a convenient way, so I figured I'd thank you for saving me the trouble!

I looked at the source for your Disassembly Dumping mod, but all that seems to do is execute some code when the new save is created. How do I get it to actually add code to the beginning (or end) of a function in the game?

[SmashManiac]

Disassembly Dumping just saves the return value of scripts.disassemble(scripts.load(...)) in text files to allow easy inspection of the structure and data of the returned table. You can pass in it your own non-compiled code to retrieve the assembly as well. Using this knowledge, you should be able to find a way to merge the two tables together to your advantage.

If you're lazy and don't want to deal with Lua opcodes, you could just recompile the entire function (since we have the source code) and overwrite the whole thing altogether. The clean solution however, in order to avoid conflicting with other mods or future patches, would be to compile just your added code and inject it in the existing code, although this solution requires offsetting the parameters of the instructions you're adding to make sure they point to the correct constants.

I don't know how familiar you are with Lua programming or Lua opcodes, so my explanation may be a bit obscure. If you need help with the latter, here's the official definition:

http://www.lua.org/source/5.1/lopcodes.h.html

[flarn2006]

Disassembly Dumping just saves the return value of scripts.disassemble(scripts.load(...)) in text files to allow easy inspection of the structure and data of the returned table. You can pass in it your own non-compiled code to retrieve the assembly as well. Using this knowledge, you should be able to find a way to merge the two tables together to your advantage.

If you're lazy and don't want to deal with Lua opcodes, you could just recompile the entire function (since we have the source code) and overwrite the whole thing altogether. The clean solution however, in order to avoid conflicting with other mods or future patches, would be to compile just your added code and inject it in the existing code, although this solution requires offsetting the parameters of the instructions you're adding to make sure they point to the correct constants.

I don't know how familiar you are with Lua programming or Lua opcodes, so my explanation may be a bit obscure. If you need help with the latter, here's the official definition:

http://www.lua.org/source/5.1/lopcodes.h.html

I've done a lot of Lua programming before (mainly for Cheat Engine scripting, and appropriately enough the project I linked does involve patching and injecting assembly code) but my only experience with the actual opcodes is through playing HnS. Thanks though; I'll take a look at it.

Would adding a new artifact to control checkpoint saving, and putting it in a chest early in the game require the same types of methods? Or is there an easier interface programmed in for that purpose?

EDIT: I'm starting to see how this works. Silly test mod that works:

local disasm = scripts.disassemble(scripts.load("Data/Content/Game/DorkForest/Rooms/BobTrap.lua"))

disasm.proto.protos[4].constants[98] = loading.prompt("Yeah! We're going to be...")

assets.overwrite("Data/Content/Game/DorkForest/Rooms/BobTrap.lua", scripts.reassemble(disasm))

[SmashManiac]

I never tried spawning objects in the game (yet), but I believe it's just a matter of adding code to the init function of the desired room. As for chests, I believe you need to insert a new function that will be called by the opening chest as well.