Sabitsuki: While I won't discourage learning how to use the tools, the Workbench is for stuff that's aiming to be published. It seems you were posting WIPs, which those go in User Files and the respective game threads.
Please be aware that if you have too many rejected submissions in too short a time, your submission permissions can be restricted.
On that note, welcome to the forums!
I haven't played through PS but I have played through CoS; I know in CoS some of the stuff you can get you can't actually have until the second playthrough or later. Might be something similar at play here.
Does the game reward you with card combos for stopping Squirreldemort?
function generateCrit(luck, level, foelevel)
sum = mainmemory.read_u8(luck) + mainmemory.read_u8(level) - mainmemory.read_u8(foelevel)
div = math.floor(sum / 4)
return div
end
function generateRNG(addr1, addr2, addr3)
step1 = mainmemory.read_u8((addr2 + mainmemory.read_s32_le(addr3) + 1) % 8)
step2 = mainmemory.read_u8(addr1 + step1)
step3 = mainmemory.read_u8((addr2 + mainmemory.read_s32_le(addr3) + 2) % 8)
step4 = mainmemory.read_u8(addr1 + step3)
step5 = step4 * 256
step6 = step2 + step5
return math.floor((step6*99)/65535)+1
end
while true do
crit1 = generateCrit(0xf83f5, 0xf83e9, 0xf8589)
crit2 = generateCrit(0xf845d, 0xf8451, 0xf8589)
crit3 = generateCrit(0xf84c5, 0xf84b9, 0xf8589)
crit_rng = generateRNG(0x83084, 0x62e10, 0x62e18)
if crit1>=crit_rng then
gui.text(0,50,"Critical Hit from Character 1!")
else
gui.text(0,50,"")
end
if crit2>=crit_rng then
gui.text(0,60,"Critical Hit from Character 2!")
else
gui.text(0,60,"")
end
if crit3>=crit_rng then
gui.text(0,70,"Critical Hit from Character 3!")
else
gui.text(0,70,"")
end
gui.text(0,30,"Enemy 1 crit% = " .. crit1 .. " " .. crit2 .. " " ..crit3)
gui.text(0,40,"crit_rng = " .. crit_rng)
emu.frameadvance()
end
Addresses should mostly be right (they're known values for the most part) but the script as implemented here is probably very wrong, which a large part of that can be attributed to me not constantly checking against the asm as I converted the script. I need to better learn the underlying asm so that I can reimplement this accurately.
I'm stuck at Aria's starting zone, myself. I need to get back into practice.
Invariel: For me, I find All Zones Melody easier than just Z3 or Z4 by itself, even with the reduced starting health, because you're coming in with most-if-not-all of your run gear by that point. That and the whole "I'm in the mindset of pathing so that I'm not getting boxed in" thing.
Birdo runs on a timer rather than on an rng, so even if you save frames, when you need a Birdo egg you have to keep pace with the timer. In this case, no time would have been saved because of Birdo's eggs.
GB testing worked fine with Nail 'n Scale MD5:521D2AA473F4E740A6938861F70511CC
GBC testing worked fine with PPG: Bad Mojo Jojo MD5:258B7B8E4692D4204DF470487EF2FC3D
Might be a settings thing, what display method (Config > Display > Display Method) are you using?
I've had (my own) replays desync in the past, so I'm a little leery about using NecroDancer's replay format.
With that said, that Death Metal fight looked awesome, and it's a shame you the person making that couldn't tennis Deep Blues at the end there.
Best is supposed to compare against the best attempt on record - if attempt 1 had a score of 3-2, attempt 4 had a value of 5-0, and attempt 8 had a value of 10-1 it should first retain attempt 1, then discard 1 in favor of 4, then discard 4 in favor of 8.
For value, say that I had used 0x14 > 5 instead of 0x14 > best. In that case, any attempt in which player 1 scores more than 5 points would be retained (provided the tiebreak condition, in my example "Player 2's score is lower than the retained best attempt," is still met)
It's not even a true brute-force (which would systematically and exhaustively try everything), all it does is randomly-by-weight throw out inputs during the specified number of frames starting from the save state.
(Incidentally, using these settings for FlapPing under AtariHawk is amusing to watch)
The first thing you need to do is set a starting save-state in the game. Basic Bot defaults to State 0, but I prefer using State 1 simply because that's an easier hotkey for me to hit. At this time, it has to be a numbered state.
The second thing you need to do is set control weight. The higher the number, the more likely that any given frame will be sent that keypress.
(Unlike my PRNG lua script, the keypresses are not mutually exclusive under Basic Bot, so you can get stuff like EVERYTHING ALL AT ONCE. At the same time, there's always the chance that no input at all will be sent on a given frame)
The third thing you need is memory addresses to track. Basically, these serve as goals for Basic Bot to look at. These values determine which attempt is retained as "best".
The fourth and final thing you need is a duration. Basic Bot is capped at 999 frame segments... just long enough to almost play a complete game of FlapPing. Once the bot runs for this number of frames, it'll check the memory addresses. If the conditions are satisfied, that attempt will become "best" and be stored in the Best field. If it doesn't satisfy the conditions, the attempt is more-or-less discarded.
Replicated in BSNES Performance but not BSNES Compatibility.
Tested using Blackthorne MD5:EE33097D436B4901A71F7E4C9A5CB409
Address size setting doesn't seem to make a difference.
About optimization, would it be okay if I used an RTA route with "bad luck" removed and just had tas precision? Like first turns in every battle, random battles escaped immediately, avoiding world map encounters, getting hit on the first turn(to lower HP(for the powersoul)) or (get hit on the first turn(slots))? Or limit break before guard scorpion's tail. Things disregarded: critical hits, stealing, and item drops.
It's a starting point, but for a full-on submission you'll need to account for the RNG. With how thoroughly this game's been disassembled, there's very little excuse to not.
That was kinda garlands idea in the first place. Production will be a lot faster, as getting crits in this game is a pain. I just hate Bad RNG. Gecko sent me a lua script on getting criticals, I haven't used it though in this run. I may restart this run using it.
That's probably your best bet for making a solid starting point for a publishable TAS. Specifically for criticals, I found this thread over on qhimm. So far that's been my best lead on finding a disassembly of the rng that wasn't the lua script.
I'm looking at the lua functions, and there's gui.DrawNew(string name).
What sort of shenanigans can I do with this?
It calls "LockLuaSurface()", which is defined at "BizHawk.Client.EmuHawk\DisplayManager\DisplayManager.cs".
There are only two available surfaces: "emu" and "native".
I've toyed with it only once. Let me try to explain... Suppose you emulating a GameBoy game. Since the 160x144 is very small, you configure the emulator to 3x zoom.
Then, for all Lua gui functions, the coordinate system is the emulator one, which is just 160x144. However, if you call DrawNew("native"), all gui functions will now use the native coordinate system, which will be 480x432 (= 160x144 times 3).
As I said, I only tried it once, discovered what happened, and never tried again. I don't even know what side-effects it has. I guess one small "issue" to be aware is that the "emu" surface always gets cleared and redrawn on each frame (by the emulation itself), while the "native" surface doesn't. Which means if you draw something on it once, it will stay there until it is overwritten. Again, I'm not 100% sure about it. And I'm not sure how it interacts with other built-in features (such as messages at the bottom, on-screen input indicators and frame counters).
Here's an example
Language: lua
function position(demoValue1,textX,textY)
--gui.DrawNew("native")
levelNumber = mainmemory.read_u8(demoValue1) + 1
gui.drawText(textX, textY,"Stage " .. levelNumber)
end
while true do
position(0x0320,10,10)
emu.frameadvance()
end
With gui.DrawNew("native") commented out, we get this:
This draws to the Emu surface, and is the default behavior. The net effect is that this is really good for drawing substitute HUDs, but is not so good for easily presenting the depth of information necessary in a TAS.
For each frame that gui.DrawNew("native") is called, we would get the script drawn like this instead:
This method draws to the BizHawk surface itself instead of on top of what the core is drawing. The net effect is that you can draw in the padding if you need to and have it.
I haven't worked with the padding functions themselves as of yet.
local function position(XY,A,B,C,x,y)
--XY: X or Y? + Who?
--A: Sprite position
mainmemory.readbyte(A)
--B: Map position
mainmemory.readbyte(B)
--C:Map increments
mainmemory.readbyte(C)
--D:Final position
D = A+B+C
gui.drawText(x,y,"XY"D)
end
while true do
position(X:,0003,015A,01F2,50,50)
emu.frameadvance.()
end
Let's go through this one line at a time, maybe that'll help (since I don't know the context in which this is being used)
Language: lua
local function position(XY,A,B,C,x,y)
-- Defining the function to use variables XY, A, B, C, x, and y. No real issues here yet.
-- XY = X:, A = 3, B = 345, C = 498
--XY: X or Y? + Who?
--A: Sprite position
mainmemory.readbyte(A) -- You read from this address but don't do anything with it.
--B: Map position
mainmemory.readbyte(B) -- You read from this address but don't do anything with it.
--C:Map increments
mainmemory.readbyte(C) -- You read from this address but don't do anything with it.
--D:Final position
D = A+B+C -- This is adding the A, B, and C you passed originally as opposed to adding their ram values as you intended.
gui.drawText(x,y,"XY"D) -- Concatenation in lua uses the .. operator, so this should throw an error as written.
end
while true do
position(X:,0003,015A,01F2,50,50) -- Remember to declare hex values with the 0x prefix to prevent confusion
emu.frameadvance.() -- one too many dots.
end
I would also suggest renaming your variables to be more descriptive of what they hold.
subtitle 500 130 322 324 FFFFFFFF This is a tool-assisted run of Pokemon
subtitle 500 110 337 324 FFFFFFFF Blue (on the left) and Red (on the right).
I presume the first number is the frame the subtitle appears on, and the 4-byte value is the color information (probably ARGB since the first byte never changes). Are the 2nd and 3rd numbers positioning, and the 4th duration?
True, true. A slider would be neat for a viewer but that's clearly not possible with a youtube encode, and sliding back and forth in post-processing is probably more effort than possibly is necessary.
Really the only obstacle to such an alternate encode is the amount of raw time needed to script for it. If you can come up with some guidelines for when to fade between games (emphasize battles? avoid gambling noise? prefer new areas? stuff like that) I can get an avisynth script prepared.
Which core?
Regarding printing out the input table, since you're assigning inputs you'll want to manipulate your inputs table directly instead of comparing against input.get().
Language: lua
local inputs = input.get()
if (inputs ~= nil) then
console.log(inputs)
end
FFMpeg doesn't accept Lagarith as an encoding option (and I've decided I like using FFMpeg more than megui for my projects, despite it being more annoying to work with), youtube's going to re-encode it when I upload it anyway, and I use qp 0 for every stage except the upload encode (I use qp 16 for the final version).
I do need to take b-frames into account, though, and using a different container isn't much of an issue.
I thought I had transcoded that to RGB24 when I started working with it, but I guess I didn't actually do that until Cosmo2 (Aegisub Something I was using and I can't remember what doesn't play nice with ZMBV, ffmpeg doesn't like DirectShowSource(foo), and my laptop with megui was out of commission at the time). Still, at least I have a workaround in case this comes up again.
(Incidentally, using these settings for FlapPing under AtariHawk is amusing to watch)
The first thing you need to do is set a starting save-state in the game. Basic Bot defaults to State 0, but I prefer using State 1 simply because that's an easier hotkey for me to hit. At this time, it has to be a numbered state.
The second thing you need to do is set control weight. The higher the number, the more likely that any given frame will be sent that keypress.
(Unlike my PRNG lua script, the keypresses are not mutually exclusive under Basic Bot, so you can get stuff like EVERYTHING ALL AT ONCE. At the same time, there's always the chance that no input at all will be sent on a given frame)
The third thing you need is memory addresses to track. Basically, these serve as goals for Basic Bot to look at. These values determine which attempt is retained as "best".
The fourth and final thing you need is a duration. Basic Bot is capped at 999 frame segments... just long enough to almost play a complete game of FlapPing. Once the bot runs for this number of frames, it'll check the memory addresses. If the conditions are satisfied, that attempt will become "best" and be stored in the Best field. If it doesn't satisfy the conditions, the attempt is more-or-less discarded.
This draws to the Emu surface, and is the default behavior. The net effect is that this is really good for drawing substitute HUDs, but is not so good for easily presenting the depth of information necessary in a TAS.
For each frame that gui.DrawNew("native") is called, we would get the script drawn like this instead:
This method draws to the BizHawk surface itself instead of on top of what the core is drawing. The net effect is that you can draw in the padding if you need to and have it.
I haven't worked with the padding functions themselves as of yet.