#Lovely - A runtime lua injector for LOVE2D
1 messages · Page 2 of 1
I might be stupid
apparently . is treated litterally in []
oh that was quick
ERROR - lovely-injector has crashed:
panicked at C:\Users\Ethan.cargo\registry\src\index.crates.io-6f17d22bba15001f\ropey-1.6.1\src\rope.rs:546:37:
called Result::unwrap() on an Err value: Char range out of bounds: char range 0..225455, Rope/RopeSlice char length 224835
patch ```toml
[manifest]
version = "1.0.0"
dump_lua = true
priority = 0
[[patches]]
[patches.pattern]
target = "game.lua"
pattern = "(?:.|\n)*"
position = "at"
payload = ''
match_indent = true
overwrite = true
complex = true
ah yes
this is happening because I'm mutating the backing rope in terms of byte indicies when I should instead be using char indicies
there's a chance that this is causing this problem as well
yup, that was the problem
(pushed the fix)
try this one
I'll do this for the next release
yeah now the game crashes instead of lovely 👍
also this is super suprising. I did basically 0 validation work to assert that the wildcard pattern patch worked 1:1
perfect
it's pretty funny looking at the dumped game.lua lmao
wait did we have wildcards in patches before?
yep, but very simple
oh I didn't use them
you either had * or ?
no char combinators or anything
yeah they weren't very useful
surprisingly the game doesn't crash ifyou delete game.lua
main.lua
sorry
I mixed up my core game file names
sorry ill butt out then
hold on I think I got you
its uhh running
you left a debug print in
wait by all text do you mean all strings or litterally all text?
ok I chose a smaller file
was tired of waiting
thats a little harder
tbh you should let us run arbitry lua code during the patching to do patching
what is your regex engine
inb4 "whats a regex engine"
The meta implementation from the regex-automata crate. https://docs.rs/regex-automata/latest/regex_automata/index.html#available-regex-engines
It basically automatically scales between minimal + fast and complex + slow engines based on the query's requirements.
A Rust regular expression editor & tester.
oh turns out I can't spell my paths
wait I have a silly idea
oh wait its not even that silly
hmmm
for some reason I can't seem to hook the localization file
your'e that silly tho
[manifest]
version = "1.0.0"
dump_lua = true
priority = 0
[[patches]]
[patches.pattern]
target = "localization/en-us.lua"
pattern = '".+"'
position = "at"
payload = '"BUTT"'
match_indent = true
overwrite = true
complex = true
``` this should work, right @solar pebble?
this somewhat works ```toml
[manifest]
version = "1.0.0"
dump_lua = true
priority = 0
[[patches]]
[patches.pattern]
target = "functions/misc_functions.lua"
pattern = '''if args and not (type(args) == 'table') then'''
position = "after"
payload = '''return "BUTT" end
if false then'''
match_indent = true
overwrite = true
complex = false
[[patches]]
[patches.pattern]
target = "functions/misc_functions.lua"
pattern = '''final_line = final_line..assembled_string'''
position = "at"
payload = '''final_line = "BUTT"'''
match_indent = true
overwrite = true
complex = false```
dont' feel like fixing it
yeah, it's not loaded in the same way as everything else
I'll have to investigate later
oh man I'll test this out later
I'm not very happy with the regex patch at the moment. Let me know what you think about the workflow.
I think not having lookaround support is a massive problem
yeah if we can only replace it is kinda bad
oh also we can't specify flags, which isn' that big, but it would be nice to disable global so we only patch one instance of smth
ugh yeah this is cursed
oh also I didn't test, but I assume regex patches work with varibles, right?
the build I sent you has it disabled, updating it as we speak
actually for mod stuff, maybe thats where we can use the lovely module. Give it some methods for things like varible reading, getting its directory (oh wait you do export the general mod directory, don't you) etc.
maybe patch the module to have a local varbile of some id to get info
like you do the integrity
that might be handy.
- Lovely patches module to add some kind of varible, (lets say
LOVELY_MOD_ID) - Mod can import lovely
- Mod calls lovely.getModInfo(LOVELY_MOD_ID) (or whatever)
- This provides all the varibles of a mod/patch (this will be especially useful with getting metadata from other sources), mod's directory, and other info that might be useful (can't think of anythign else rn)
and then since the module has all that info for the mods, then it can also export it so my crash handler can display it
hmm, I like that idea
complex patching is high priority for me atm, so I'll look into this after that
yeah fair enough
I really like the idea of syntax tree parsing but my assfeeling is that the pattern grammar will be super gross
also bold of you to assume i want to patch an entire chunk of syntax and not just some arbitry block of code
^^ exactly
me when I patch G.something to G.somBUTThing
maybe I should get a rust compiler setup and mess around with lovely
after my exam though
do it 👀
alright, I'm going to split the regex stuff into its own patch. I'll add some configuration which lets you select a capture group to replace with some value. that way we can avoid needing to interpolate $0 back into the payload.
pattern = "osdkD)0ko2opldakodm(sd)" # Arbitrary regex
position = "after | before | at" # Before and after inserts the payload before or after $0, at replaces the group in `replace`.
replace = "$1" # Defaults to $0 if not set. Optional
payload = "some_interpolated_thing" # Replaces the match / capture group targeted in `replace`. Capture interp is allowed here.
[[patches]]
[patches.regex]
target = "functions/UI_definitions.lua"
position = "at"
pattern = '''text = (?<thing>localize\(["'].+["']\))'''
root_capture = "thing"
payload = "BUTT"
give this one a shot
the position field doesn't do anything yet, will get to that later.
if I even keep it
ah and it doesn't work with non-named capture groups
fixing that in a few
(gotta run off and do things)
position could be nice, cause then I could add stuff below or after without having to worry about also doing $0
I could probably make a regex that automatically prints a functions name and the name + values of it's args with this
and apply it to all functions
ok I built lovely but its crashing and all the crash output is going to the terminal it has which instantly dissapears
ok attatched a debugger
idk what't swrong
it looks like it's exporting the wrong ordinals / the proxy is generally invalid
try pointing the path in build.rs to the version.dll I sent earlier.
gnu toolchain?
I belive I'm using the GNU toolchain
gotcha. that might be the cause, but try my recommendation first.
I believe that I can avoid needing to do that by manually specifying the exports
... maybe
maybe. try the msvc toolchain instead. you'll need to use cargo-xwin
shits erroring
did you install the llvm prereq? rustup component add llvm-tools-preview
I have no idea why this is happening honestly
oh I need to install llvm in cargo?
no same error
idk
it shouldn't be this hard to compile smth
I use this tool to build much more technical and complex projects, so I'm not sure what's going on. I'll tweak the proxy build tooling in a little bit, hopefully it's just that.
@gleaming locust @glad hare @final void Heads up that you all will need to update your packages on TS to refer to the latest lovely release (0.4.0).
Otherwise r2mm will break
No rush, take care of it when it's convenient
(this shouldn't generally be required, it's only necessary because of the dwmapi -> version name change)
New update download is stuck at 100%, guess I'll try installing manually
Even that is failing
yeah, I had to change how r2mm installed lovely so the build that you have wont work anymore
The issue is installing 3.1.48 doesn’t include Balatro, so I think I’ll need a new build
Ah gotcha. Give me 10 and I'll build you the updated version.
tysm
In the meantime I’ll add one thing to my mod so releasing v1.0.2 makes sense lol
here you go
ty
I was able to build it on my Fedora install.
Did you run rustup target add x86_64-pc-windows-msvc?
And make sure that your build command was cargo xwin build --package lovely-win --target x86_64-pc-windows-msvc.
Just trying to figure out what's causing the build the fail
err
testing
this shouldn't be caused by the release, nothing notable changed between 0.3.1 and 0.4.0
(also, while you're here, it would be great if you could make the dumps auto-remove after each time lovely runs; it'll help with one of my security checks)
it worked fine 0.3.1, must be an issue with [patches.copy]
will track this issue there
ideally it would remove the old dumps and leave the new ones, so I can check if someone adds code to other files besides main and game.lua
the files would be overwritten, but excess ones are never removed on game restarts
I'm not able to repro on my quick testbench
Let me do a better job of this
Since I was just testing against steamodded
I can send you my mods folder
sure
My plan is to clean the dump directory first, then write new dumps to it
perfect
Hmm
Wait I might know the issue
It might be overloading dwmapi and version DLLs
Deleting dwmapi.dll fixed it
But that should be something that r2mm does automatically
https://github.com/ethangreen-dev/lovely-injector/issues/9 tracking that issue here
I'm thinking I'll likely just remove dwmapi.dll if it's present and invoke a panic
Or just ask the user to delete it 🤷
Is it possible to inject into the middle of a base game function using lovely 🤔
More specifically, I want to inject into Card:generate_UIBox_ability_table(), which defines loc_vars as nil at the start of the function and then passes it to generate_card_ui(), and I want to modify loc_vars before it gets passed on.
not reliably without regex support (which is being worked on) since you might not be able to match a single line uniquely
I want to have steamodded relying on this as well down the line once regex support is released and stable
Okay, I'll hold off on my idea for now then, thank you!
yeah I'm building on fedora, I run the rustup command, and I was building with cargo xwin build --target x86_64-pc-windows-msvc -p lovely-win but your command also erorrs the same
If you create a new project with cargo new build-test --bin can you build it with cargo xwin build --target x86_64-pc-windows-msvc?
Yeah compiles and runs
ok, now try to build this
[[patches]]
[patches.regex]
target = "conf.lua"
pattern = "(?m)t.(?<thing>.*) = (?<val>.*)\n"
root_capture = "val"
position = "at"
payload = "\"$thing\""
regex patching is looking pretty solid rn
ah, my bet is that the libc dependency is breaking your build
if I'm not mentally dead tomorrow I'll make a lovely pre-release on the repo.
Wilson, at this point you should try the xwin docker image.
Okay, I'll see if I have time and willpower tommorow
@devout cargo I was looking at your romanian i8n mod and was trying to come up with a good solution to make it work with either lovely or steamodded. What edits did you make to game.lua?
Nevermind, did a textdiff
Although I am curious about this change:
I'm guessing that it's that hard to get i8n injection working. Your first step would likely be to extend these two tables with the new language and its font, if required.
You could then load the new assets via steamodded
The only hard part is loading the i8n lua file itself. It's being loaded into the game here:
and loadstring eventually should call lual_loadbuffer
but my hook isn't being called with that name
in theory you could replace this function entirely (or the self.localization setter) with something that either (a) loads from some steamodded / alternative file location OR calls the original code.
in other news I've added the ability to prepend payload lines with a string or regex capture: ```toml
[[patches]]
[patches.regex]
target = "game.lua"
pattern = "(?<indent>[ \t])if love.filesystem.getInfo\(v.file\) then \n.\n.*\n"
position = "after"
line_prepend = "$indent"
payload = "print('hello world!')\n"
this is basically a more complex version of the pattern patch's match_indent field
ok for some reason my lovely has stopped working
even the stable release which is known working
oh nvm linux is being a silly goof
I had a broken symlink for the version.dll so it wasn't being overwritten
docker image
@final void heads up that dump files wont have the @ prefix for this next release
Hello everyone, it's time for a (pre)release. Version 0.5.0-beta1, including Regex patching and the long-awaited CARGO VERSION NUMBER. Enjoy: https://github.com/ethangreen-dev/lovely-injector/releases/tag/v0.5.0-beta1
What's Changed
- Implement shared "Lovely runtime" to reduce code duplication across win and mac targets by @ethangreen-dev in https://github.com/ethangreen-dev/lovely-injector/pull/6
This is a backend change which reduces the complexity required to support windows and mac targets. - Complex Regex patching and patch optimization via ropey by @ethangreen-dev in https://github.com/ethangreen-dev/lovely-injector/pull/7
_This makes it possible to write patches with Regex, enabling MUCH MORE complex patch behavior than before. _ - Cleanup previously dumped buffers at startup, remove @ prefix from file names by @ethangreen-dev in https://github.com/ethangreen-dev/lovely-injector/pull/11
This will remove the dump directory (Balatro/Mods/lovely/dump) directory at startup to ensure old buffers aren't kept around. This also ensures that buffers dumped to this directory do not have the@prefix. - Add check and panic message when old
dwmapi.dllbinary is found within the game directory by @ethangreen-dev in https://github.com/ethangreen-dev/lovely-injector/pull/12
This change adds a panic whendwmapi.dllis found within the game directory, with instructions on how to fix it. - Add
--disable-consoleargument by @ethangreen-dev in https://github.com/ethangreen-dev/lovely-injector/pull/13
For people who find the console annoying. Add this to the Steam launch args:--disable-console.
Regex Patches
This beta release is primarily meant to test long-awaited support for the Regex patch - a new format which enables infinitely more complex (and expressive) patch behavior. Be careful with this tool, though, as it's easy to seriously damage runtime patching performance, cause infinite loops, or even trigger memory overflows.
Full documentation is pending, so here's a quick and dirty example:
[[patches]]
[patches.regex]
target = "game.lua"
pattern = "(?<indent>[ \t]*)if love.filesystem.getInfo\\(v.file\\) then \n.*\n.*\n"
position = "after"
line_prepend = "$indent"
payload = "print('hello world!')\n"
A note about the position and root_capture: The former specifies where relative to the root capture (Regex capture group) the payload will be inserted. I accept before, after, and at. The latter is the only value that will directly replace the capture with the payload. Capture groups can be interpolated into the payload as well, so it's quite simple to parse values out of the codebase and interpolate them into your payload.
line_prepend will prepend each value containing (non newline or empty) line of the payload with the containing value. Capture groups are interpolated into this value, as show in the previous example.
Refer to the regex patch struct definition for more information: https://github.com/ethangreen-dev/lovely-injector/blob/a1ac407f3a5c80c9dee98a694afed872be812f4f/crates/lovely-core/src/patch/regex.rs#L11
(I will write documentation sometime)
Full Changelog: https://github.com/ethangreen-dev/lovely-injector/compare/v0.4.0...v0.5.0-beta1
@vital coyote lets chat about it here
👍
so for most of the balamod modules we made it so you gotta require(module_name) it
so that means most of the files have a return at the end
since lovely copies contents of the files, it has code that wants to run after a return is called on the whole file
there is a module patch but it's currently a bit half-baked
my next project is getting really solid module patching implemented, but I've been a bit distracted
but yeah, that seems like a pretty solid blocker
hmm
i think i theoretically could just change all the files to just use global scope but thats what we were mostly trying to avoid with the overhaul
definitely dont do that
yea xdd
it sorta goes against my ethos to require changes like that lol
alright 🫡 lmk when you get modules
you can technically try to see if the current module patch works for your use-case ```toml
Inject a new module into the game before a target file it loaded.
USEFUL: For when you want to silo your code into a separate require-able module OR inject a "global" dependency before game / mod code begins execution.
[[patches]]
[patches.module]
source = "nativefs.lua"
before = "main.lua"
name = "nativefs"
i was experimenting with newer versions of balamod in lovely a bit ago and has some luck with setting _G.package.path instead of using lovely's inbuilt module patches. the modules have lots of cross dependencies so mudule patches didn't work very well.
yep, module patch works if you want to inject something totally standalone
which is like... almost never
this is likely the way that I'll do it, it's been working well in my test environment
it's not so "clean" but who tf cares at the end of the day
it works
the main issue I ran into was the mod folder name not being able to be renamed without breaking it, since lovely currently has no way of getting that in the patch code.
it might be easier to add some sorta flag like extend_import_paths = true or something which wires it up automatically
that way the patch doesn't need to care about the actual directory (but that would be nice to have as a lovely var const)
what version of love is balatro using?
tried messing with love's setRequirePath but that didnt work unfortunately
technically it works if we just dump all of balamod's lua files into steamapps/common/Balatro/lua but that's kinda hack-y
i think
yea i got it running with lovely if i do that, also no errors are immediately jumping out
yeah, it's funky. I need to dig into the source and see how it actually behaves
glad you got a POC implemented. it's obviously not production ready, but it's good evidence that balamod works with lovely in the first place
nice work
I'll keep you posted on my module injection overhaul
🫡
@strong hawk you can disable the console now lol
I remembered your request legit last second
just add --disable-console in the steam launch args
Thanks
Is updating as simple as replacing the version.dll file with the newest one?
yep!
Is there a way to check if a patch has been applied succesfully? I am trying to patch into the generate_card_ui function but this doesn't seem to work.
[manifest]
version = "1.0.0"
dump_lua = true
priority = 0
# Add card mult localization
[[patches]]
[patches.pattern]
target = "functions/common_events.lua"
pattern = ''' elseif _c.set == 'Enhanced' then'''
position = "before"
payload = '''
if specific_vars and specific_vars.bonus_mult then
localize { type = 'other', key = 'card_extra_mult', nodes = desc_nodes, vars = { specific_vars.bonus_mult } }
end
'''
match_indent = true
overwrite = false
not in a super clean way, but your patch isn't working because the pattern is applied to each line without any leading whitespace
you can fix it by removing the four spaces before your pattern :-)
and if you have match_indent set each line of your payload is prepended with the same indentation as the matched line, so you should only need one set of spaces in your payload, not two
That fixed it, thank you!
no problem!
Do I need to do anything to specify that my mod uses lovely inside of my mod.lua file, or is simply adding the lovely.toml file enough?
you only need the toml :-)
beautiful
also Wilson you'd be proud - I actually set the version const for the release
Wait it was 0.1.0 the whole time before? lol
what if I did?
perchance?
Also no way it was actually done
I have numerous abilities, many of which terrify me
I'm scared of incrementing version numbers
Are there any changes to pattern patch in 0.5.0 beta?
[[patches]]
[patches.pattern]
target = "game.lua"
pattern = '''init_localization()'''
position = "before"
payload = '''
apply_properkorean()'''
match_indent = true
overwrite = false
This works fine in 0.4.0 but with 0.5.0 it applies to weird position https://www.diffchecker.com/03z7GZpO/
yep, I refactored the patch backend. looking into this, thanks for the report
that is definitely a weird spot lmao
what other mods do you have installed with lovely patches?
There are a few more but the same thing happens if I leave only that one
awesome, thanks
looking into it after I eat
in the meantime this regex patch should work ```toml
[[patches]]
[patches.regex]
target = "game.lua"
pattern = "(?<indent>[ \t]*)init_localization()\n"
position = "before"
line_prepend = "$indent"
payload = "apply_properkorean()\n"
although I haven't tested it
fixed, was using a byte range when I should have instead been using a char range
ez fix, will push and publish a beta2 release later today
give this one a shot, should be working
That works, thanks 👍
Released version v0.5.0-beta2: https://github.com/ethangreen-dev/lovely-injector/releases/tag/v0.5.0-beta2
This notably contains a fix to the weird pattern patch offset bug that DVRP reported.
I'm likely going to replace the module system with _G.package.path, I think it's the most simple way to go forward.
I would love to hack together a system that does it entirely in-process but dependency resolution is meh
I suppose I could also implement a loader hook
Lovely

I am trying to patch into the following function
elseif _c.set == 'Enhanced' then
if specific_vars and _c.name ~= 'Stone Card' and specific_vars.nominal_chips then
localize{type = 'other', key = 'card_chips', nodes = desc_nodes, vars = {specific_vars.nominal_chips}}
end
if _c.effect == 'Mult Card' then loc_vars = {_c.config.mult}
elseif _c.effect == 'Wild Card' then
...
With this patch
# Add card mult localization to mult cards specifically
[[patches]]
[patches.pattern]
target = "functions/common_events.lua"
pattern = '''elseif _c.effect == 'Wild Card' then'''
position = "before"
payload = '''
if _c.effect == 'Mult Card' then loc_vars = {((specific_vars and specific_vars.bonus_mult) or _c.config.mult)}
'''
match_indent = true
overwrite = true
And I'm getting this error
Syntax error: functions/common_events.lua:2723: 'end' expected (to close 'function' at line 2370) near '<eof>'
I'm on the first beta version of 0.5.0, but I assume I'm doing something wrong with the overwrite part, although I'm not sure what. Any help?
0.5.0-beta2 should address this-?
if not, try checking the dump to see if your patch makes sense syntactically
Still crashing on latest version
How do I do that exactly 🤔
Shouldn't you use an elseif in your code?
I want to overwrite the if _c.effect == 'Mult Card' then loc_vars = {_c.config.mult} line
there should be some sort of lovely/dump folder in your mods dir
Then you should probably set that as your pattern and set position to at
That fixed it, thank you!
I tried the cargo zigbuild and it still doesn;t work
wait let me get the latest lovely, just in case
ok yeah same error
what dist are you on again?
don't answer that
try sudo dnf install @development-tools
something about your c header install is ducky
yeah, give it a go. I'm otherwise sorta out of ideas. all of these build failures are stemming from the libudis86-sys crate, which is shitting the bed for some reason.
the docker image is dead but I googled and saw that and it found 2 different files
dnf provides "*string.h"
see if that returns anything
in theory you should have a clang install with that header
well let me install cargo-zigbuild first
and by that I mean let me update rust first so I can install that
after this?
either way this build failure stems from the retour crate
wait what fedora version are you on?
here we go: https://github.com/Hpmason/retour-rs/issues/36
no clue :-)
hang on, let me bump the retour version
cat /etc/fedora-release
reinstalling development tools didn't fix it
pull the udis-build-fix branch and build it
it compiled
ok great so now we're back at the first issue
wait
actually I think I reverted the change I made for it to look for the version.dll
nope still crashing
how does the path even work on a linux system?
I tried forward_dll::forward_dll("\\home\\shorty\\projects\\external\\lovely-injector\\version.dll").unwrap(); and forward_dll::forward_dll("/home/shorty/projects/external/lovely-injector/version.dll").unwrap();
pull the linux-forward-dll-fix branch and build it
in theory it would link to the version.dll found within the active wine prefix
but that gets a bit abstracted when using build tools like xwin
this branch should technically fix it since it replaces the static forwarder with a dynamic one
which should behave better when running under wine
basically means that you dont need to have the version.dll file present when compiling it, only at runtime
which works since you're guaranteed to be running it under a wine prefix
Compiling lovely-win v0.1.0 (/home/shorty/projects/external/lovely-injector/crates/lovely-win)
error: proc-macro derive panicked
--> crates/lovely-win/src/lib.rs:20:10
|
20 | #[derive(ForwardModule)]
| ^^^^^^^^^^^^^
|
= help: message: 指定的 DLL 可能是一个无效的 PE 文件: "Failed to read file: No such file or directory (os error 2)"
error[E0599]: no method named `init` found for struct `VersionModule` in the current scope
--> crates/lovely-win/src/lib.rs:44:17
|
22 | pub struct VersionModule;
| ------------------------ method `init` not found for this struct
...
44 | VERSION_LIB.init().unwrap();
| ^^^^ method not found in `VersionModule`
|
= help: items from traits can only be used if the trait is implemented and in scope
= note: the following trait defines an item `init`, perhaps you need to implement it:
candidate #1: `ForwardModule`
For more information about this error, try `rustc --explain E0599`.
error: could not compile `lovely-win` (lib) due to 2 previous errors
nevermind, I assumed incorrectly. can't blame me, the name isn't super clear lol
alright let me think about it
i think i goofed up something when trying to add the mod loader cause my game won't open
make sure steam is open
and delete the balatro executable and validate game files
saving this for later https://learn.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-def-files?view=msvc-170&viewFallbackFrom=vs-2019
going to implement true dynamic forwarding later
shouldn't be too hard?
tried it and it still isn't opening
match_indent seems to be adding indents to one more line than it should (the last line is not supposed to be patched)
that is unless I don't end the multiline string on a separate line
it turns out normal when done this way
noted, will fix this in beta3
thank for report
tysm, doing great work as always
likewise :-)

also leaving a note here to add this to the readme#1211272354676613221 message
#⚙・modding-general message
Feature request; detect if the DLL is injected into a non-LOVE executable and don’t do anything
got another one, this appends the first line of the payload onto the line before the pattern instead of inserting a new one - behaves as normal if a newline is prepended to the payload
I don't understand how this works.
Probably not gonna work anyways, most likely will need to append generate_card_UI for badges
But I do want to at least test if it's not necessary
A card.lua dump is created so I'm under the impression something else is wrong
iirc if it creates the dump but doesnt applying the patch then no valid match was found in the source file
have you tested your regex against what you're trying to match? if not then definitely do it on a site like https://regexr.com
Used a different regex (because apparently it was just bad? idk it just seemed to never work on the site nor here) but getting this now
you need to escape the curly braces with backslashes
well, I think
It works now, nice
Can a pattern be several lines, or only one?
The location I need to patch something in is in the middle of this mess that I can't directly match
regex one's can be
the other one's couldn't, but not sure if that changed when regex patching was added
I'm not at my PC, can you see if this behavior persists if you add the newline char to the end of the regex pat?
if not then I'll test it out tomorrow after work
oh I had a question
yes sir
What is the version in the menifest of?
so you know how Santa is 100% real until your parents tell you otherwise, and then you're like "wow ok that was pretty obvious"
perhaps
let's just say that the version is Santa
ok so what is the version supposed to be for?
(it's not currently validated but it's supposed to be used to validate the current patch spec version)
ok
so its patch file version
and you made a major patch file change
and didn't bump the version
smh my head
I didn't make a breaking change to the existing patches
i do the same thing with balamod api xdd
nah it's not semver
tbh files that are easily adapted, like JSON and TOMl and YAML and whatever really don't need versions
well, not "true" semver
imagine if I could compile lovely rn
yeah, the solution requires some additional work and I haven't had time to do it
I'm basically going to need to manually implement dynamic exports
ok wait you mentioned that it's using wine to compile it?
yeah, but it's not able to find the patch of the system version dll, which implies that the wine environment is ducky (or not wine at all)
so I'm not sure anymore
ok let me test smth
ok it didn
't work
hold on I might be onto somthing
so remeber that one branch you made for me
I changed the one line to #[forward(target = "/home/shorty/projects/external/lovely-injector/version.dll")]
and it fixed one of the errors
warning: unused import: `libc::FILE`
--> crates/lovely-core/src/sys.rs:3:5
|
3 | use libc::FILE;
| ^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
warning: field `args` is never read
--> crates/lovely-core/src/lib.rs:176:5
|
170 | pub struct PatchTable {
| ---------- field in this struct
...
176 | args: HashMap<String, String>,
| ^^^^
|
= note: `#[warn(dead_code)]` on by default
warning: `lovely-core` (lib) generated 2 warnings (run `cargo fix --lib -p lovely-core` to apply 1 suggestion)
Compiling lovely-win v0.1.0 (/home/shorty/projects/external/lovely-injector/crates/lovely-win)
error: symbol `DllMain` is already defined
--> crates/lovely-win/src/lib.rs:20:10
|
20 | #[derive(ForwardModule)]
| ^^^^^^^^^^^^^
|
= note: this error originates in the macro `$crate::define_function` which comes from the expansion of the derive macro `ForwardModule` (in Nightly builds, run with -Z macro-backtrace for more info)
error: could not compile `lovely-win` (lib) due to 1 previous error```
idk how to fix that further though
did it doesn't find the symbols or whatever
tried that and that but with backslashes and that but also with a Z: in front
wine: Call from 00006FFFFFC5E7B8 to unimplemented function version.dll.GetFileVersionInfoSizeW, aborting
lame. I'll fuck around and get a reproducible example working on my end tomorrow.
that's the only real way I'll be able to figure this out
It's unfortunate cause I want to do a little lovely programming
@solar pebble I figured it out
you're never going to belive this
removing the #[cfg(target_os = "windows")] works
well my love is crashing but I bet its a faulty mod
I'm like pretty sure this is code for it built it
also huh????
there is none
also there might've been a regression
for some reason this code is cut short
haven't touched this file for al ong time
lovely.toml ```toml
[manifest]
version = "1.0.0"
dump_lua = true
priority = 0
[[patches]]
[patches.pattern]
target = "main.lua"
pattern = "function love.load() "
position = "at"
payload = 'function love.load(arg) '
match_indent = true
overwrite = false
[[patches]]
[patches.pattern]
target = "main.lua"
pattern = "G.STEAM = st"
position = "after"
payload = 'initSteamTest(arg)'
match_indent = true
overwrite = false
[[patches]]
[patches.copy]
target = "main.lua"
position = "append"
sources = [
"core.lua",
]
it also seems to have screwed up another file
controller.lua is cut off at the end (non-lovely injected code)
only mod that injects into that is DebugPlus
Does this answer this question?
lmao
dang, nice
alright
not sure about these bugs, will investigate tomorrow. make sure that your environment is clean and stuff
but yay! super weird that caused the problem
could be caused by target_os vs target_family, not totally sure
error still happens when rebuilt
which commit is the latest releasse built on?
ah its 0f97d12a7042d1571bf4169f8b9986a9481bae2c
oh that commit erros with that werid error from earlier
when you got it working did you still have the modified path?
yeah I modifed the path
this is my current build.rs ```rs
fn main() {
forward_dll::forward_dll("/home/shorty/projects/external/lovely-injector/version.dll").unwrap();
}
why would it be cutting off my mod files?
works fine on the latest release
but I can't compile that commit
also all you changed was the version of one dep
so that seems odd
oh intresting
it seems to create both the @file and file in the dump folder
that might be where the second integrity is from
you have two copies of lovely being run somehow
wait
well maybe
I might know whats happening
I'm braindead atm
ok so uhh I think the version.dll I'm using to patch is a lovely dll
yeah okay I think that was it
ah yeah
reset the path and build it again with xwin
see if that picks up the wine system version dll
path not patch
error: failed to run custom build command for `lovely-win v0.1.0 (/home/shorty/projects/external/lovely-injector/crates/lovely-win)`
Caused by:
process didn't exit successfully: `/home/shorty/projects/external/lovely-injector/target/debug/build/lovely-win-774db1e7ad08685d/build-script-build` (exit status: 101)
--- stderr
thread 'main' panicked at crates/lovely-win/build.rs:2:68:
called `Result::unwrap()` on an `Err` value: "Failed to read file: No such file or directory (os error 2)"
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace```
yeah
maybe let me set an env var for the version path
default to the windows one
I broke it
I am not even sure where this file is from
give me the input patches so I can repro, that's a hell of a bug
I'm heading off to bed for now though, will review your findings / problems tomorrow. thanks :-)
it also requires a modifed lovely
so I'm not even sure what's wrong
... huh
I think it might be caused by printing a super massive message
send me the patches and a git diff
oh no I formatted the code and now there are like a million differences
ok so I modifed inject_metadata to ```rs
pub unsafe fn inject_metadata(&self, state: *mut LuaState) {
let table = vec![
("mod_dir", self.mod_dir.to_str().unwrap().replace('\', "/")),
("version", env!("CARGO_PKG_VERSION").to_string()),
("patches", format!("{:?}", self.patches)),
];
let mut code = include_str!("../lovely.lua").to_string();
for (field, value) in table {
let field = format!("lovely_template:{field}");
code = code.replace(&field, &value);
}
sys::load_module(state, "lovely", &code, self.loadbuffer.as_ref().unwrap())
}
lovely.lua tolua
-- This file contains template values filled during JIT. You can access these values
-- within your code with local lovely = require("lovely").
return {
repo = "https://github.com/ethangreen-dev/lovely-injector",
version = "lovely_template:version",
mod_dir = "lovely_template:mod_dir",
patches = "lovely_template:patches",
}
and my patch istoml
[manifest]
version = "1.0.0"
dump_lua = true
priority = 0
[[patches]]
[patches.pattern]
target = "game.lua"
pattern = "self.SPEEDFACTOR = 1"
position = "after"
payload = '''
lovely = require("lovely")
print(lovely.patches)
'''
match_indent = true
overwrite = false
wait I somehow messed up and this might be easier to replicate
huh
ok its some kind of issue on my end
I realized what I was calling was null
and so putting print(nil) as the payload crashes
but this doesn't happen on the latest release??
what did I even change to cause this??
reverted my changes and this still crahses on my build
¯_(ツ)_/¯
just a thought, might be intresting to pass lovely panics to the games crash handler
although I guess most of them would happen before the game is even started
looks like what I want to do is not possible without modifing the loader to store more info
I don't want to get that involved yet
What is this?
wait are args shared across patch files??
oh I might've found an oopsie
I found 2 oopsies
in the README you say vars are called like ${{lovely:var_name}} when it's actually {{lovely:var_name}} (and also theres one spot in the readme where you says it's ${lovely:var_name}
they are
ok I'm going to sleep
gn
for some reason under EXTREAMLY specific circumstances that i dont really understand, the override_print() function will crash at runtime unsafe precondition(s) violated: slice::from_raw_parts requires the pointer to be aligned and non-null, and the total size of the slice not to exceed `isize::MAX
I'm so cloooooose
I was getting it when printing nil but only when I built lovely myself
Are you on the latest commit?
yep
Maybe it's some kind of regression then
its when you attempt to print null
i removed a leftover accidentally null print and it fixed itself
nil, whatever
game keeps crashing at launch with just lovely + steamodded installed
any way i can get a log?
this only just started happening today
should be an easy enough fix
that's like var interpolation but through the command line, not yet implemented. I've got a somewhat funky version of it locally but it's not ready to be pushed.
the help field would basically allow the mod author to provide detailed information about what the command line flag does, accepted values, etc.
gotcha, will update this
Is this a hint that I should be using GitHub issues?
cant get lovely to inject on linux, ive:
put version.dll in ~/.local/share/Steam/steamapps/common/Balatro/
added the executable bit using chmod +x version.dll
added an selinux policy to allow for the game to write executable memory using ausearch -c 'wine-preloader' --raw | audit2allow -M my-winepreloader && semodule -X 300 -i my-winepreloader.pp
got my mod directory like this https://the.yog.zone/ALKCm77.png
what am i doing wrong?
you need to add WINEDLLOVERRIDES="version=n,b" %command% to the game's steam launch options
Mr. Meth I was thinking, how hard would it be to have it where lua code can call native lovely code?
Like a native module but auto injected
ez pz, just requires some annoying boilerplate
it would basically require what I'm already doing with the native print override
that's basically my plan with the loaded_mods function, whenever I implement it
oh neat
I was thinking msth
oh yeah
allowing dynamically defining imports
or requires
or whatever lua calls them
it might also be neat if you could let the code do more
but pretty much everything else would require you to load the mod before the game does
ok so I got some weird silly behaviour
I was messing around with exploiting the fact that saves/settings are evaled
I added a print stament to it
when lovely is loaded, it crashes
INFO - [GAME] Error unpacking string: [string "print('A')..."]:1: attempt to call global 'print' (a nil value)
when lovely isn't, it works perfectly fine (well I don't have any kind of console output for some reason)
any of yall know why the game aint launching? this is what i get
One of your lovely mods has an error
Looks like debugplus
But it should be fine
Unless it was modified?
i dont think so
Which version of lovely do you have?
removed it and got a different error
Syntax error: game.lua:3607: '=' expected near '<eof>'
Traceback
[love "callbacks.lua"]:228: in function 'handler'
[C]: at 0x7ffdecb02fa0
[C]: in function 'require'
main.lua:16: in main chunk
[C]: in function 'require'
[C]: in function 'xpcall'
[C]: in function 'xpcall'```
but the game loaded
you don't happen to have an old dwmapi.dll lovely loaded as well?
i dont know but ill update whenever i get back home, i have to leave for now
are you running an older version?
screenshots for refrence
downloaded it off github today so no
That should work
i followed the exact install instructions
and it doesnt work
so idk what to do
the console window isn't showing up at all?
yeah nothing at all
do I need a startup paramater or something?
Mr. Meth will a regex match the same string multiple times if it appears multiple times?
Or a simple patch?
actually i can just patch in a different spot
not mr. drugs here, but I happen to have gotten an extra trigger of a patch for a line that wasn't unique
so yes
yea i accidentally set a pattern to literally everything thinking it would go to the first match, but it instead, replaced every single character
i once used a greedy match pattern that should have been lazy and ended up eating the entire rest of the file lmao
wso true
i was trying to match the entire get_straight function so I did something like [\s\S]*end
yeah need a question mark
which just greedily ate up everything until the last unindented end in the file
that sure was fun
i feel like this is gonna be fun 💀
hell yeah
yes to both, but that'll change sometime soon
For some reason my regex patch is inserting after the first match, and before the second?
and also incorrectly interpolates some groups?
is there a way to get the directory of my mod? trying to do things with the files in there and don't want to hardcode the directory name
(without Steamodded btw)
love.filesystem has a bunch of different directories it keeps track of
wait this is lovely chat oops
I've been using lovely.mod_dir.."/hardcoded-path/"
you probably meant lovely specifically
table.sort(self.cards, function (a, b) return a.T.x + a.T.w/2 - 100*(a.pinned and a.sort_id or 0)
< b.T.x + b.T.w/2 - 100*(b.pinned and b.sort_id or 0) end)``` becomes ```lua
table.sort(self.cards, function (a, b) return a.T.x + a.T.w/2 - 100*(a.pinned and a.sort_id or 0)+ 100*(a.pinned_right and a.sort_id or 0)
< b.T.x + b.T.w/2 + 100*(_.pinned_right and ..sort_id or 0)- 100*(b.pinned and b.sort_id or 0) end)``` with```toml
pattern = '''- 100\*\((\w+)\.pinned and (\w+)\.sort_id or 0\)'''
position = "after"
payload = '''
+ 100*($1.pinned_right and $2.sort_id or 0)
'''```
but if someone renames hardcoded-path the program can't load 
I mean you could set a var for the hardcoded path and tell them to modify the lovbely file
but thats not a very nice way to do so
maybe we should have some built in way of doing this
liek built in varible
I might be able to do that
but let me finish what I'm working on
yup, it'll be a patch option
@solar pebble hows this for a feature?```toml
[manifest]
version = "1.0.0"
dump_lua = true
priority = 0
[[patches]]
[patches.pattern]
target = "main.lua"
pattern = "function love.resize(w, h)"
position = "before"
payload = '''
print("{{lovely:lovely_mod_dir}}")
'''
match_indent = true
overwrite = false
very nice uwu, lovely:mod_dir
okY

although it doesn't quite seem to work yety
@solar pebble is it intended for patches in different dir's to share varibles?
it's both intentional and not intentional
so it's an unexpected feature?
this is proving to be a ltitle more difficult that I wanted because of how the lovely behaves
ah, I understand what you're trying to do now
yeah that's a little bit tricky. if you give me a day I can whip something up that'll do it
cause it seems you collect all the vars then process all them, so I lose info about where a patch is from
If I can just add a property to the patch class, it shouldn't be too bad
is there a better way to do this?
the easiest way would likely have each patch hold a reference to some mod metadata
yeah I figured
An Arc<Mod> would probably be the easiest way to do it
bold of you to assume I know what an Arc or Mod is
Mod is the theoretical struct that would contain the mod metadata
Arc would be the smart pointer which lets you have multiple patches refer to the same Mod instance
okay
I'll implement this for the next beta release if you'd like
yeah maybe do that
I'll probably just produce shit code you'd have to fix anyways
so, if we storee all the mods, then it would be eaiser to export mod info to lua
yeah but I basically have to learn rust to do so
you're literally the best
but yeah this feature would be perfect for what I'm doing
Look what I did
lovely
Tbh a few different values can probably be optional, like most people don't touch match indent, priority, or dump_lua, and just giving them sane defaults would be good
@twin bluff merged your PR last night
Yeah I saw, thanks
also have the patch application issues you found earlier been consistent?
eg. are they still happening?
Wait like this? #1214591552903716954 message
I don't have access to that link
That's for me to look into, thanks Harb. I'll check it out later today.
my game is taking like 30 seconds to load with all the patches in steamodded now....
is there any optimization to be had, or is it just gonna be that way?
30 seconds to patch?
it depends on the amount of regex patches you're running. The normal pattern patch should be very efficient.
either way share your mods directory with me so I can repro and work on optimizing things.
patching itself is probably closer to like 20 seconds
I'm pretty much just running on https://github.com/Steamopollys/Steamodded/tree/main
ah it absolutely should not be taking that much time
I have 67 regex patches and 35 pattern patches
i guess i could try to cut down on that, but it still seems a bit excessive
my dude lmao
that's a 1400 line patch file
you're cracked
looking into it :-)
also you should definitely split these up into separate files
I unfortunately can't reproduce, patching is pretty quick on my machine
maybe 5 seconds?
well same for me now, I swear it just took longer >_<
i was gonna say it might be a case of "I shouldn't be running 2 concurrent instances of vscode on this machine", but that isn't really making a difference
phew, glad we figured that out
I will keep optimizations in mind though moving forward
I think it would be nice to have some sorta patch cache
yeah, that seems nice
I'll keep an eye on my load times and see if anything comes up again (or ig I'll download more RAM xD)
I did some looking to see how love2D handles the save directory, so lovely doesn't have to harcode the Balatro directory
looks like its a bit messy
it uses an identity to configure it
the game can change it a runtime
so chances are, you can't handle every mod's directory
I think the default identity is just the exe/love file name
can't find in the code where it's handled
but anyways, theres a handy chart
if fused on windows, then it drops the LOVE directory
so I guess you could default to just getting the basename of the exe
maybe make a config file you can drop in beside the dll to overwrite that, if a game needs it
I have actually used a regex patch for something useful now
niiiice, thanks! yeah, it would probably be ideal to have some sort of game-specific config file that we can dump next to the executable
Yeah. Ideally, the config shouldn't be nessicary, but it should be helpful when you can't do everything yourself
oh yeah, it's practically instantaneous on the release build
so we should be good for now
Yeah I noticed my thing was kinda slow, but I was on a debug build so I figured I should test on a release build before mentioning
how do i download lovely?
i followed a guide on youtube but it didnt work
i want to download to play the reverie mod
i also used to steammodded ps injector if that makes a differece
On the release page, there is a file called version.dll. Download that and stick it in the same folder as your balatro exe (you can get this in steam by going to properties > local files > browser local files or smth like that). Then when launching balatro, it should open a console windows as well. Also you should probably move to installing steam modded with lovely, as it is a lot better in a bunch of ways. Also see https://discord.com/channels/1116389027176787968/1217867725532041369
steamodded not steam modded, the creators name is steamo so that's why it's named that way
oh ok ty
It got autocorrected
xd
Lovely
Lövely?
LÖVEly
keeping it then
Looks lovely
Although it and game being different widths might be annoying
But also you don't usually mix the two
or [♥♥♥♥]
hm right
XD
Tbh G is good
🇬
But also there's like 50 characters of steamodded stuff after that usually, so I don't think it's a big deal
50 characters? don't you mean 500 lines?
I meant just the boilerplate for a message
(me when I forget the fact that I logged all mod info including the file contents for whatever reason)
Ok wait question if you're a DLL/shared library, can you read the argv?
yus
Is it a pain to do?
nah, it's accessible natively within rust env::args
Nice
When I have time and after I do the crash log thing, I'll see about unhardcoding the mod path
Oh yeah I guess you read command flags, so the argv must be readable
you can get the mod dir at runtime with require("lovely").mod_dir iirc
could we get the lovely link pinned pls? <3
Ok so I was working on unhardcoding the path, and it "works", but .'s in the name get turned to _ in love2D. I can fix this case, but worried that there might be more I'm not aware of. Would you happen to know how this is determined or just who cares, ship it?
But yeah it's working
oh just realized my source is out of date
ok @solar pebble ready for some super shitty code to review?
uhhh
why didnt you use env::current_exe()?
let game_name = env::current_exe()
.as_ref()
.map(Path::new)
.and_then(Path::file_name)
.and_then(OsStr::to_str)
.map(String::from)
Didn't know it existed
Also this should be file_stem not file_name
I think
yup, should be file_stem
Oh also you didn't replace the . With _
I would argue that this isn't something we should worry about perfecting atm
This solution is hard because it's not a "real" solution :-/
I mean it should work for like 90% of cases
bing bam bop
figured out an okish solution that doesn't rely on the executable name
we can basically just call PHYSF_getWriteDir at runtime
well no we cant
well we technically can
if we hook PHYSFS_setWriteDir when lovely has been newly installed into a game we can grab the path, then kill the game process, then we can restart it
bleh
ignore everything I've said
let game_name = env::current_exe()
.as_ref()
.map(Path::new)
.and_then(Path::file_name)
.and_then(OsStr::to_str)
.map(String::from)
.replace('.', '_');
that should work
The thing is love2D litteraly relies on the executable name
By default
Like rename the balatro exe and then run it and it uses a new directory
Unless it sets a config option in lua
In which case, it's game dependant
this is the scenario that I'm worried about, but we can add a cli arg for cases like this
Yeah I think a config file would be good
So then if a mod scene uses lovely, they deploy it with a premade config
this does not work
my head hasn't wraqpped around options and resut quite yet
yeah I can't figure this out
Path::file_stem is an option not a result
working on improving the install guide
Remember to add the execution instruction for Linux :p
I would appreciate another set of eyes on this PR if possible, I'm pretty bad at github action stuff: https://github.com/ethangreen-dev/lovely-injector/pull/31
this is what a release would look like (if anyone is interested): https://github.com/ethangreen-dev/toolchain-test/releases/tag/v1.0.30
I got Lovely working
I mean it uploading zip files is kinda inconvient
well I guess it's nice that you can have both macos versions
also you should write install instructions for mac
but other than that looks fine
if its runs it runs
it's all automatic thankfully
if you're talking about me needing to upload them being inconvenient
No I mean downloading them
yeah but it's the only real way to make Mac distribution work
it's a necessary annoyance unfortunately
@twin bluff left a review on your PR btw, sorry I forgot about it
afternoon everyone, v0.5.0-beta3 is released. https://github.com/ethangreen-dev/lovely-injector/releases/tag/v0.5.0-beta3
I'm pretty sure clicking the windows install gives you the apple install instead
Ok yeah I'm definitely sure it's not directing to the correct download
Also, are the only direct changes to how patches work are the removal of overwrite?
dumb moment, fixed
that should be the only thing, but overwrite funnily enough never did anything sooo
Awesome to have a log
Lemme see if this lets me know why the game doesn't like calling copy_table on an object.
Damn, oh well. Guess I'll never know.
Also through the quick text, the log does work, just maybe not with the game closing crashes?
that depends on the debug mod I think
on the bug: assuming copy_table is just a shallow copy, it may be because objects have metatables
oh, it's a function in Balatro already, nvm
welp. maybe yell at localthunk
I'm amazed at how many people are playing Balatro on Mac
It's basically a 1:1 split between Mac and Windows
very impressive
Oh yeah I fixed my pr
@solar pebble hi, can I request support for a .lovelyignore sort of file or some other way to disable lovely patch files?
should be easy. I'll add a check for a .lovelyignore file in a mod dir. If it exists then the entire directory is skipped.
yeah that's perfect
merged
ez to implement
I've also removed that regex debug statement and clarified the readme for Steam Deck / Proton / whatever
Can you make the overwrite deprication not spam the console?
Cause we only really need it once (or maybe once per patch file) and also we can't remove it if we want to keep compat with older lovely versions
i'm amazed macs are even used
you can remove the field without breaking support
but yeah, fair, it is too aggressive
iirc it used to complain if it was missing
but it's only 0.4+ that's actually still usable anyway
I'm pretty sure old versions error without it
Isn't that the example i used for the pr where I made better error messages?
hmm yeah, you're right
that's what I get for responding 30 seconds after I wake up
looking into this. I'm honestly considering tying it into some sort of logic instead of removing it
but making it an optional field obviously
how does .lovelyignore work
whole directory is ignored if it exists
I mean, do I make it as a dummy file
its contents don't matter
I see
i requested this for integration with steamodded
hey, I was the one who contributed the code that apparently spammed everyone with deprecation messages... I can change that to once per file
though it looks like we're just going to let people not care
which is totally fine too
nah it's not your fault, I should've caught it in the review :-)
I mean it's an option that never really did anything so if we just make it not do anything, but optional, then it's basically like nothing changed
hm, having trouble on mac. lovely indicates that the mod directory is 'love', not 'Balatro' now
the reason seems to be simply that the mac version of Balatro ends up running an executable called 'love'. it's right in the folder
so current_exe is working, and it correctly returns 'love'...
(in case it wasn't clear, the app structure on Mac ends up running a file called 'love'.)
it doesn't really behave wrong per se
hmm that's mildly frustrating
made a quick pr to paper over this problem
so that's the reason patch files are not running at all
ok, the patch file from my mod isn't running still, plus beta5 completely breaks Custom Font
h
can you please patch it a little bit so i can use it on my old windows 7?
man, this is exhausting
I should probably wait for a fully-functioning Language API from Steamodded
it should be functional in 1.0
but there's no instructions
this is my first time ever joining the modding community of some game
that's on me, I need to get docs out there
if you're on Mac then yes, that would likely be the reason.
depends on what sort of error message you're getting. a good thing to try is ensuring that your vc redistributable is updated.
Rust 1.75 dropped windows 7 support in February, I recommend updating if you want to use lovely
in theory there's a way that I could compile it for win7, but it's a tier 3 target and largely untested.
eg. it's not something that I feel comfortable with releasing for use
that being said windows 7 is becoming a security problem, you should seriously consider win10 or Linux
in beta5 pattern patch works I believe, but not copy patch, at least for me
I still cannot append/prepend stuff
I'll be gone till Friday 
I assume patches are usually meant for other stuff
localization files are probably loaded before their supposed patch happens
feature idea:
Add a console warning if a patch finds 0 matches
Good for if you make a typo or if you’re trying to find what broke with a game update
I play on mac so I can play a bit of Balatro at work
Hi! Is there a configuration somewhere to set Lovely in silent mode?
To avoid having a Window Console running in the background every time Balatro is launched (especially in windowed mode)
yes, add --disable-console to your steam launch args
Thanks!
np
Idea export argv in the lovely module
could run_lovely.sh for Mac forward command flags to the game? since it's not run through steam, launch args from it aren't used as I understand it
eh, iunno nothing about macs, I was just helping someone earlier with setting up steamodded with restricted access
I thought setting a different mod dir would work, but it ended up blocking the dylib anyway - I just thought it could be useful to add an easier way to specify launch args
Oh you could probably add your launch args to the script itself.
just adding them after this line should work https://github.com/ethangreen-dev/lovely-injector/blob/master/crates/lovely-mac/run_lovely.sh#L8
that's what I ended up telling that person to do, perhaps it's good enough
i guess it's more of a permanent config that way
gimme a minute
oh yeah I was right
does this work properly with multiple args?
that pr
it should
just tested
@thick steppe checking in on Lovely + Hades II - have you tried it out?
If the lua is not compiled bytecode then there's a chance it'll just work.
but it depends on how the Hades 2 engine loads lua, where it's loaded from, etc. etc. If it uses lual_loadbuffer then it'll work, otherwise I'll need to implement additional function hooks.
https://github.com/SGG-Modding/Hell2Modding
this is our loader
the game's scripts are transparent text files
and we load before they are read
my intention is the plugins just register patches by calling functions, then those get ran once those files are imported by the game
in the step between the game reading the file data and loading it as lua
(I don't like having a data format for patches, I just want them to be elected as callbacks that have arguments)
I was hoping there was some bytecode shenanigans going on too so that the patches could be done lazily such as on hot reload
so the overall desire is to use lovely (or similar) to provide JIT code transformation in addition to the current modding API that H2M exposes?
and the want is to have patches be defined at runtime within the mod without the patch file
(I'm still waking up, just wanted to be sure that I'm on the right track)
that sounds about right
we can read toml as lua tables and vice versa, so if for the sake of easy implementation we still use the patch structure from lovely, that can be done in the interim
as h2m ships with rom.toml namespace (the toml library on luarocks)
we can't dynamically load lua libs because the lua is statically linked
so any custom clib must be bundled into h2m
e.g. socket is bundled too
anyway, you may want to continue this discussion in-depth in the Hades Modding server
same discord listed on the hades II community page?
ye
could I use this to replace/patch the current game.lua file found in Balatro.exe with my own?
so yeah, in theory you could. create a regex patch which matches EVERYTHING in game.lua, replace with an empty string. then create an append patch which appends your game.lua onto the now empty game.lua
hey, thanks for the reply! but I already managed to brute force the changed game.lua into the games source code files, so we good.
do you know when/if an update that tracks which mods are loaded will be released? It'll help greatly with tracking what mods are loaded in runs played with Ankh
my antivirus detects(Win64/HackTool.RustRegion.A) file as a threat
when trying to download the beta 0.5 of lovely for the version.dll file
any1 know how to fix this and if there might be a way to mod baltro without it
the steamodded injector would not cause you any less trouble - lovely generally gets flagged less by antivirus
it does however happen sometimes
the easiest way to get around it is to disable your antivirus software for the time of installation
alright thanks
Likely by the end of the month, have had my hands full with other projects so lovely feature dev has been deprioritized.
how granular?
do you want each loaded patch or just a high-level list of directory names
Loaded patches with mod names would be the best
hey, can someone tell me what these directories in the run_lovely.sh script are meant to contain? i'm trying to find the equivalents with my setup so i can edit the command
gamename="Balatro"
defaultpath="/Users/$USER/Library/Application Support/Steam/steamapps/common/$gamename"
export DYLD_INSERT_LIBRARIES=liblovely.dylib
cd "$defaultpath"
./$gamename.app/Contents/MacOS/love "$@"```
what are you trying to do tho
if you find running the script in terminal too time-consuming, consider writing an Apple Script file to automate that
i currently run balatro directly through the love2d game engine and was trying to make lovely work with that

code moment