I need a script that reads lines in text file A.txt, and checks if they are present in text file B.txt. If not, the lines are deleted from A.txt.
I figured someone good can come up with a solution in 1 min so I don't have to spend 30 mins working on it. :P
Also, please be aware of this issue regarding file reading.Language: lualocal file_name_A = "C:\\path\\to\\A.txt" local file_name_B = "C:\\path\\to\\B.txt" local file_A, file_B, line_A, line_B local matched_lines = {} file_A = io.open(file_name_A, "r") file_B = io.open(file_name_B, "r") if (file_A ~= nil) and (file_B ~= nil) then file_A:close() file_B:close() for line_A in io.lines(file_name_A) do for line_B in io.lines(file_name_B) do if line_A == line_B then table.insert(matched_lines, line_A) end end end file_A = io.open(file_name_A, "w") for i = 1, #matched_lines do file_A:write(matched_lines[i]) file_A:write("\n") end file_A:close() end
Thank you again!Language: Luafor line_A in io.lines(file_name_A) do for line_B in io.lines(file_name_B) do lengthA = string.len(line_A) if line_A ~= string.sub(line_B,1,lengthA) then table.insert(matched_lines, line_A) break end end end
As said, I'm checking if lines of A exist anywhere in file B. I tried with string.find(s, pattern) but pattern misbehaves if I want to search for characters like - * % $ [ ] etc.
Now let's say that "blablabla" reaches the far right of the screen. Is there a way for the rest of the text to go automatically underneath blablabla
Language: luagui.drawText(0,0,"blablabla\nrandom text")
Is there a way for the rest of the text to go automatically underneath blablabla
There's probably other [better] ways to do that, this is the one that first came to mindLanguage: lua-- Font settings local BIZHAWK_FONT_WIDTH = 10 local BIZHAWK_FONT_HEIGHT = 14 -- Text wrap function local function draw_text_wrap(x, y, text) local text_table = {} for word in string.gmatch(text, "%a+") do table.insert(text_table, word) end local x_pos, y_pos = x, y local limit = client.screenwidth() -- Fit 1st word if x_pos + string.len(text_table[1])*BIZHAWK_FONT_WIDTH > limit then x_pos = limit - string.len(text_table[1])*BIZHAWK_FONT_WIDTH ; y_pos = y_pos + BIZHAWK_FONT_HEIGHT end gui.text(x_pos, y_pos, text_table[1]) x_pos = x_pos + (string.len(text_table[1]) + 1)*BIZHAWK_FONT_WIDTH -- Fit the other words for i = 2, #text_table do if x_pos + string.len(text_table[i])*BIZHAWK_FONT_WIDTH > limit then x_pos = x y_pos = y_pos + BIZHAWK_FONT_HEIGHT if x_pos + string.len(text_table[i])*BIZHAWK_FONT_WIDTH > limit then x_pos = limit - string.len(text_table[i])*BIZHAWK_FONT_WIDTH end end gui.text(x_pos, y_pos, text_table[i]) x_pos = x_pos + (string.len(text_table[i]) + 1)*BIZHAWK_FONT_WIDTH end end
You can see the result of this example in this image. Now I realised it doesn't consider any symbol (like commas), but the fix should be easy.Language: lualocal test_text = "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam rhoncus, mauris quis dapibus maximus, felis mi dapibus mauris, quis pulvinar lectus risus sed metus. Suspendisse id libero sed metus scelerisque maximus id sed est. Mauris iaculis justo vel neque euismod, a semper sapien consectetur. Nam vitae consequat tortor, nec efficitur purus. Proin porttitor libero tellus, sed mattis diam rutrum et. Curabitur ut dui ex. Sed nec nulla nec sapien tempus viverra. Ut ut sollicitudin nisi. Sed in sem ut erat ullamcorper interdum id et diam. Nulla eu tempus nisl. Phasellus eu nisi eget neque placerat viverra eu quis leo. Morbi vehicula est massa, sit amet sodales ligula blandit ut. Phasellus egestas ipsum eu vulputate tincidunt. Mauris gravida risus in malesuada malesuada." while true do draw_text_wrap(128, 0, test_text) emu.frameadvance() end
I need a script that reads lines in text file A.txt, and checks if they are present in text file B.txt. If not, the lines are deleted from A.txt. I figured someone good can come up with a solution in 1 min so I don't have to spend 30 mins working on it. :P Thanks in advance.
Language: lualocal function do_shit_with_file(name, shit) local handle, err = io.open(name) if (handle) then local foo = shit(handle) handle:close() return foo else error(err) end end local function get_lines(handle) local ram = {} for line in handle:lines() do ram[line] = true end return ram end local function erase_if_not_in(other_file) return function(handle) local buffer = {} for line in handle:lines() do if (other_file[line]) then table.insert(buffer, line) end end return buffer end end local function overwrite_file(name, content) local handle = assert(io.open(name, 'w+')) handle:write(content) handle:close() end local B = do_shit_with_file('B.txt', get_lines) local A = do_shit_with_file('A.txt', erase_if_not_in(B)) overwrite_file('A.txt', table.concat(A, '\n'))
MUL (Multiply) multiplies two signed or unsigned 32-bit values. The least significant 32 bits of the result are written to the destination register.
Since the bitwise library in Lua for BizHawk is 32 bit, I cannot use bit.band(result,0xFFFFFFFF00000000). Is this the best way to extract the lower 32 bits from the result of a multiply without using bit library, or can it be done better?Language: luafunction MUL(A,B) local result = A * B local temp = result local result = 0 for i = 0,31 do result = (temp%2 == 1) and result+2^i or result temp = math.floor(temp/2) --can't use bit shift due to being 64 bit end return result end
(The final recombining step adds a 32 bit and a 48 bit number, so technically requires 49 bits. But we have 53 bits so we're good.)Language: luafunction MUL(A,B) local reslow = A * (B%0x10000) -- A multiplied with lower 16 bits of B local reshigh = A * (math.floor(B/0x10000)%0x10000) -- A multiplied with higher 16 bits of B (shifted down) reshigh = reshigh%0x10000 -- only 16 bits can matter here if result is 32 bits return (reshigh*0x10000 + reslow)%0x100000000 -- recombine and cut off to 32 bits end
Is this correct on bits 16 to 31 and bits 32 to 47 comment?Language: lua--[[ 0000 0000 0000 0000 0000 0000 0000 0000 1111 1111 1111 1111 1111 1111 1111 1111 A 4,294,967,295 x 0000 0000 0000 0000 0000 0000 0000 0000 1111 1111 1111 1111 0101 1010 1010 1010 B 4,294,924,970 1111 1111 1111 1111 0101 1010 1010 1001 0000 0000 0000 0000 1010 0101 0101 0110 Res -181,793,080,695,466 RdHi should be 0000 0000 0000 0000 0000 0000 0000 0000 1111 1111 1111 1111 0101 1010 1010 1001 Lower 32 bits, and thus Answer and RdLo should be 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1010 0101 0101 0110 Answer 42,326 --------------------------------------------------------------------------------- Break B to 2 parts 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1111 1111 1111 1111 B1 Upper 16 65,535 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0101 1010 1010 1010 B2 Lower 16 23,210 A x B1 0000 0000 0000 0000 0000 0000 0000 0000 1111 1111 1111 1111 1111 1111 1111 1111 A 4,294,967,295 x 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1111 1111 1111 1111 B1 65,535 0000 0000 0000 0000 1111 1111 1111 1110 1111 1111 1111 1111 0000 0000 0000 0001 C1 281,470,681,677,825 Do bits 16 to 31 in C1 corresponds to bits 48 to 63 in "Answer"? That is: RdHi_1 = C1 Mod 4,294,967,296 shift right 16 0000 0000 0000 0000 1111 1111 1111 1110 1111 1111 1111 1111 0000 0000 0000 0001 C1 281,470,681,677,825 Mod 4,294,967,296 0000 0000 0000 0000 0000 0000 0000 0000 1111 1111 1111 1111 0000 0000 0000 0001 4,294,901,761 Shift 16 right 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1111 1111 1111 1111 RdHi_1 Mod 4,294,967,296 0000 0000 0000 0000 0000 0000 0000 0000 1111 1111 1111 1111 0000 0000 0000 0001 4,294,901,761 Shift left 16 times 0000 0000 0000 0000 1111 1111 1111 1111 0000 0000 0000 0001 0000 0000 0000 0000 Mod 4,294,967,296 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 C1 65,536 A x B2 0000 0000 0000 0000 0000 0000 0000 0000 1111 1111 1111 1111 1111 1111 1111 1111 A 4,294,967,295 x 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0101 1010 1010 1010 B2 23,210 0000 0000 0000 0000 0101 1010 1010 1001 1111 1111 1111 1111 1010 0101 0101 0110 C2 99,686,190,916,950 Do bits 32 to 47 in C2 corresponds to bits 32 to 47 in "Answer"? That is: RdHi_2 = C2 shift right 32 0000 0000 0000 0000 0101 1010 1010 1001 1111 1111 1111 1111 1010 0101 0101 0110 C2 99,686,190,916,950 Shift right 32 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0101 1010 1010 1001 RdHi_2 23,209 Combining C1 + C2 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 C1 281,470,681,808,896 + 0000 0000 0000 0000 0101 1010 1010 1001 1111 1111 1111 1111 1010 0101 0101 0110 C2 99,686,190,916,950 0000 0000 0000 0000 0101 1010 1010 1010 0000 0000 0000 0000 1010 0101 0101 0110 D 381,156,872,725,846 D Mod 4,294,967,296 gives RdLo (lower 32 bits) RdHi_1 x 65,536 + RdHi_2 gives RdHi (upper 32 bits) ]]-- function MUL(A,B) --The lower 32 bits of the 64 bit result are written to RdLo, the upper 32 bits of the result are written to RdHi. local reslow = A * (B%0x10000) -- A multiplied with lower 16 bits of B local reshigh = A * (math.floor(B/0x10000)%0x10000) -- A multiplied with higher 16 bits of B (shifted down) local RdHi = math.floor(reshigh)/0x10000 --Shift right RdHi = RdHi * 0x10000 --Shift left RdHi = RdHi + math.floor(reslow/0x10000) reshigh = reshigh%0x10000 -- only 16 bits can matter here if result is 32 bits local RdLo = (reshigh*0x10000 + reslow)%0x100000000 -- recombine and cut off to 32 bits return RdHi, RdLo end
Language: luafunction MUL64(A,B) local reslow = A * (B%0x10000) -- 0x0000LLLLLLLLLLLL local reshigh = A * math.floor(B/0x10000) -- 0xHHHHHHHHHHHH0000 local reslow_lo = reslow%0x100000000 -- 0x00000000LLLLLLLL local reslow_hi = math.floor(reslow/0x100000000) -- 0x0000LLLL00000000 local reshigh_lo = reshigh%0x10000 -- 0x00000000HHHH0000 local reshigh_hi = math.floor(reshigh/0x10000) -- 0xHHHHHHHH00000000 local low32 = reshigh_lo*0x10000 + reslow_lo local high32 = reshigh_hi + reslow_hi high32 = high32 + math.floor(low32/0x100000000) -- add what carries over low32 = low32%0x100000000 -- 32 bit high32 = high32%0x100000000 -- 32 bit return low32,high32 end
set_flags(CPSR, flag0, flag1, flag2, ..., flag31)
if flag0 > 0 then
if flag0 > 0 then CPSR = bit.set(CPSR, 0) else CPSR = bit.clear(CPSR,31) end
if flag1 > 0 then CPSR = bit.set(CPSR, 1) else CPSR = bit.clear(CPSR,31) end
...
if flag31 > 0 then CPSR = bit.set(CPSR, 31) else CPSR = bit.clear(CPSR,31) end
endset_flags(CPSR, new_CPSR)
CPSR = new_CPSR
return CPSR
endset_flags(CPSR, table_CPSR)
for i = 0, 31 do
if table_CPSR[i] = 1 then CPSR = bit.set(CPSR, i) else CPSR = bit.clear(CPSR, i) end
end
endThis would output "4". Ignoring the bit hacking fuckery, the main gist here is that you set up a table with the names of your registers and their associated position in your integer. Then when you want to set or clear specific bits, you pass in a table with keys that are the register names and either a 0 or a 1 depending on what you're doing. This way you only pass in pairs of registers and values that you want to modify. I literally only tested this to see that it compiles and the sample output is correct, so make sure to test yourself. EDIT: Code inside the for loop that is actually human-readable would look like:Language: luaregisters = {C=2, V=3}; function set_flags(CSPR, flagPairs) for k, v in pairs(flagPairs) do local mask = bit.lshift(1,registers[k]); CSPR = bit.bor(bit.band(CSPR, bit.bnot(mask)), bit.band(bit.lshift(v, registers[k]), mask)); end return CSPR; end while true do local CSPR = 8; t = {C=1,V=0}; print(set_flags(CSPR, t)); emu.frameadvance(); end
and you would pass in bools instead of integer 1s and 0s.Language: luaif v then CSPR = bit.set(CSPR, registers[k]); else CSPR = bit.clear(CSPR, registers[k]); end
"0": "WRAM"
"1": "ROM"
"2": "VRAM"
"3": "CartRAM"
"4": "OAM"
"5": "HRAM"
"6": "System Bus"
"0": "WRAM"
"1": "ROM"
"2": "VRAM"
"3": "CartRAM"
"4": "OAM"
"5": "HRAM"
"6": "IO"
"7": "BOOTROM"
"8": "BGP"
"9": "OBP"This is very good news because I'm just starting work on a bot for a Goldeneye 00 agent full run, and I've found the guards' hitboxes in memory but they are only available briefly before they are overwritten. Sometimes the game syncs up well with the 1/60th frame advances and you just can't read them.
Can you share a general overview of your strategy for finding the hitbox data? I don't mean like a detailed breakdown or anything (unless you really want to). I had the idea of writing a wallhack in Lua to make TASing easier, and the part of the process that I figure would just be horrendously tedious and difficult would be figuring out where hitbox data is stored (and what format it might even be in), so that a bounding box could be drawn around the enemy.
Great minds eh :)
For sure I can share. I'm a big fan of making paper notes which I number before they leave my desk so it's kinda documented. My method was pretty haphazard tbh because it's the first major bit of reversing I've done on a game, but I've definitely come out of the other side with something more definitive. Also bear in mind that I got pretty lucky.
Starting out I had some knowledge of the standard bits of memory courtesy of Wyster which I've extended slightly in my travels, and I'd done some reversing for a mod that I made recently. Crucially I had already made & improved & debugged & remembered-that-lua-is-one-based-for a lua HUD. My plan was to find some kind of boxes and throw it in this to make sense of it.
Getting started
Unfortunately my 'in' isn't so documented because it was doing reversing in ghidra, so we have to do a little speculation. In the-elite (Goldeneye speedrunning) people call me a TASer but it's not so much actual TASes that I make (until now) but just exploring strategy ideas using emulator. At the end of last year I was fleshing out an old strategy idea which I won't excite you with (TAS here, heartbreaker here). It relies on random shot spread to actually hit the hostage, so I looked into that.
I had a neat (though no doubt unoriginal) idea for this. I dumped the rom in virtual memory from Project64, and found all calls to the RNG (I already knew the address from Wyster, so Project64's debugger found the update function). Then I wrote some assembly code to look the RNG's return address up in a table of values at a specific address. If it found a match then it returned the non-random value from the table, else it returned the generated random value. Coupled with a lua script, this lets you take something observable and random (gun spread) and binary search for where it calls the RNG. I quickly found that it made 2 pairs of calls for x and y spread. This debunked my hope that playing in wide/cinema would widen your gun spread.
Back on topic though, this gave me a starting point - I had found the code which generated a random shot, so the code for testing collisions shouldn't have been too far away. Bear in mind that I'm by no means an expert at reversing, and I've pretty much only used Ghidra against Goldeneye, so I won't lecture you. The decompiler is very impressive imo, and with 0 effort the output can still be really good. One thing I always bear in mind is not to have too much confidence on the signatures that it gives functions, unless you've gone and looked at it. I just focused on the control flow, and at 7f03b15c there's a function which calls the 'makeRandomShot' function at +0x48, and has 2 main loops near the bottom. Highly suspicious :)
In summary: Hook RNG -> Find shot code
Project64 scripts
From here I started 'hitbox_chasing.js', a Project64 script to hook some of these calls and just shout to say that they'd run. I found a function that ran once for each guard that the shot passed near to.. lower .. a function with a jump table .. lower .. and bingo a function which was clearly doing vectory shit and returning a boolean. The main thing which I'd been following was the shot direction vector. The script was really useful for verifying my reversing, and I found it a really good companion because you might have been looking at various values to do with the leg, but then in 5 seconds you can get those same values printed out for the head instead. Or a different guard. I could shoot a guard in the left forearm and it would say I've hit hitbox #10, and describe a box which is long and thin.
This function took 4 things:
- some origin offset, always (0,0,0) [Perhaps guards also use this to shoot :) ]
- shot direction vector
- hit box data
- hit box matrix
So looking at this function, I could parse the hitbox data. It is just Body part #, X min, X max, Y min, Y max, Z min, Z max. But I still needed to be able to find the matrix.
I went back and I tried to piece together what was going on. The Project64 scripting was useful again, but really I was going in the wrong direction.
Basically these hitboxes are linked from '0xA-type' 'skeleton objects'. The skeleton objects live in a binary tree structure with backlinks. I realised that they had up to 3 pointers but I was thrown off because the backpointers usually go back many steps, rather than just to the parent. If I had just looked at a sibling of the vectory function, I'd have seen code walking up the skeleton looking for a matrix (on a 0x2-type skeleton object normally). My thinking was that at some point I'd have to look back up the call stack and trace my parameters, but the much clearer code was down low. I gave up and went to sleep :)
Sunday
The next day I was feeling kinda low because we're in corona lockdown and my corona project seemed a bit stuck. I think I must have put a breakpoint on reading these 3 pointers and I was blessed by finding an amazing function at 7f06f0d0. It literally walks the skeleton, following the pointer at 0x14 until it sees a nullptr, then stepping back on 0x8 and looking for 0xC. I did some skeleton-walking myself, and found that type 0xA signified hitboxes. So I just had to see how it got hold of the skeleton root.
Then I noticed it came from a familiar value (the 'model data pointer') that I'd seen in the long stack of calls earlier. I suddenly realised that this is actually kinda familiar, and I knew how to find it from Wyster's "GuardData". The sibling function that I mentioned explained how to find the matrix within a list linked off of this model data pointer.
Finishing up
So profit. I had the hitboxes, but with 2 issues:
(a) The memory that the matrices are written to is reused even before the next frame is drawn
(b) The matrices were for the view projection, whereas I also wanted their global coordinates
(a) has been 'solved' using lua to hook the end of some matrix multiplication code, looking for writes to guards' matrix lists. Currently I'm getting a crash but the code does work for a little while before it runs out of memory.
(b) To get them locally I could use the matrix that my HUD uses, but I've always known that to be a bit of a hack - my HUD lags if you spin fast, and sometimes hops about a bit. My bot is going to use this for godlike aiming so it needs to be good. Instead I noticed that the 15 hitboxes didn't use consecutive indices in the matrix list. I just tried multiplying by the inverse of the unused matrices at [16], [13], [9] and [4], and really liked the look of [4]. It's effect was to fix the centre of the gut hitbox, and the direction that the guard was facing (though his animation might still spin or whatever). I was very fortunate that I could correct both of these. The guard's point position is readable from the GuardData and coincides with the center of the 'gut hitbox', and I just happened to have found guards' facing angles in memory a while back.
The result shows guard's hitboxes 2 in-game frames ahead of where the guards are visually, which is pretty neat. As a bonus it reveals the view matrix, which I can use on the shot direction if I like.. or track down more reliably in memory.
To come back to lua my worst error was hooking the matrix multiply function, because a 1 was written by the delay slot in the bottom right of this 16 cell square matrix. Not to worry, I'll just do this myself in lua:
Ms[offset][3][3] = 1.0
I don't mean like a detailed breakdown or anything (unless you really want to).