Posts for Omnigamer


1 2 3 4 5
11 12
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Glad some folks are interested in this game again! It's due for a revamp. I don't think I have any lua scripts built for it, but I know the full RNG process/addresses if you want to manipulate drops. A few things were discovered after the previous TAS was published for use in RTA runs. This list isn't exhaustive, but includes the most significant things off the top of my head: -Shura-Oh quick kill. Should be pretty straightforward, just get the luck right. -Cutscene skips in 3-1 and 3-2. By buffering tumble attacks and getting some good positioning, you can start the screen transition earlier. -Faster kills on a few minibosses. I don't remember exactly which, but be sure to watch Ohon's run for hints. -Generally better movement in several rooms, such as 2-3 and 5-4. May not be as applicable to a TAS since you have walljumps and zips to work with, but worth checking out nonetheless. Good luck on the TAS! I'm also available to help out if you get caught up on any mechanics or otherwise.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I am neither an expert in the game nor have I fully watched this run yet, but I'm somewhat cautious with the time and optimization. The SDA sumbission from many years ago seems to only be 18 seconds slower with equal timing (8 of which comes prior to gameplay). I don't know what, if anything, is different between the language versions of the game, but considering the SDA run is 8 years old I think there's probably some better optimization you can eke out here.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
So I've been thinking for a bit on potentially making a Suikoden II TAS before getting back into full runs again because I'm an idiot. Just due to the ability to have absolute control over luck manipulation, I think there could be some pretty interesting routing choices to work through. To help reduce the tedium though, I'm looking at building up a few lua scripts to ease the endeavor as I go. I'm listing them here in case anybody else has additional input, but I'll go about actually building them up sometime in the future. Some are definitely possible, others would be nice but might not have an easy solution. -Dialog input ready indicator. If there's some flag that gets set as dialog inputs become responsive to progression, it would save a LOT of time to have that available. Otherwise I can probably work off of visual cues, but automating the several hundred dialog boxes away would make it a lot more reasonable. -Encounter indicator. I can easily set up something to determine the remaining grace period, but determining how many RNG calls before an encounter is a much trickier problem. I might be able to come up with something, but I might not. -Upcoming encounter group indicator. Somewhat related to the previous bullet, but I still don't know the exact mechanic behind group selection. This would help in making sure that the few times I need a specific group, I can automate for it. -Delay & test script. For battles, a lot of times I'll need to rely on abusing multiple critical hits or otherwise. This would be tedious to test extensively by waiting for following RNG updates, so I can instead pre-calculate the next 1000 or so RNG values and find the first one that meets my condition (KO of boss). -Stat growth predictor. Similar to the above, if I can pre-process the RNG calls well enough, I can predict how many "good" level ups I can get for one or all stats, and find an optimal RNG value to use. -War battle sequencer. War battles are tricky to manipulate because there's relatively few ways to affect RNG outside of performing attacks. Ideally, I'd limit attacks to just those necessary to advance, but exhaustively testing different options would be maddening. Having a script to go through and move units procedurally would help this, but may end up being more work than it's worth. -Loading Zone indicator. I have my doubts that this is possible due to how the game is structured, but being able to see the exact regions that the game uses to initiate events would go a long way in potentially finding other skips. ======================== Unrelated to this post, the details of my prior post from 2014 have been figured out in greater detail. The technical stuff is all available in this thread: http://suikosource.com/phpBB3/viewtopic.php?f=9&t=14301&p=156717 We still have no idea how to reproduce, but we at least understand the mechanism. It is likely related to a corrupted save file, but if a specific story flag is set related to the end of the game, it will go into the credits sequence. The exact memory location is 0x8006AEFE.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
The biggest issue for me is that this doesn't give the impression of being a TAS at all. I could very well believe that all of the events were instead performed by a human in real time. I get that this is a playaround, but I don't see much value in it other than showing off the game content. Some funny bugs, if they exist, would be helpful to its entertainment. I might also like to see how the "advantaged" characters play through each of their respective events, achieving the theoretical max for the game rather than the max for the neutral character. No vote for me. It just needs to be sillier or more polished to make sense as a submission.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
For anybody that wants to work on this game, I made a helper lua script some time ago. I have not made any attempts to update it for recent BizHawk changes, but it's simple enough that it should still be compatible. It was originally intended to show hitboxes, but the hitboxes are determined by unique subroutines per enemy, thus being a pain in the ass. It still displays HP and damage values of attacks, which should be pretty helpful. It also does some strange calculations against a semicircle around your character, which I can only imagine is your shield.
--Alcahest Helper Script
--Author: Omnigamer

function draw_cross(x_pos,y_pos, color)
	gui.drawLine(x_pos-3,y_pos,x_pos+3,y_pos, color)
	gui.drawLine(x_pos,y_pos-3,x_pos,y_pos+3, color)
end

while true do
	
	camx = mainmemory.read_u16_le(0x00173C)
	camy = mainmemory.read_u16_le(0x001744)
	
	textX=20
	textY=30
	
	hp = mainmemory.read_u8(0x001858)
	gui.drawText(textX,textY,string.format("HP:  %d",hp))

	
	memory.usememorydomain("CARTROM")
	
	x_coord = mainmemory.read_u16_le(0x000CF6)
	y_coord = mainmemory.read_u16_le(0x000D2E)
	
	--2 = player
	--4 = partner
	--6 = guardian
	--A = partner projectile
	--16 = aura blade projectile
	--24-34 = enemies and items
	
	next_ID = 0x02;
	
	while next_ID ~= 0xFF do
		
		x_coord = mainmemory.read_u16_le(0x000CF4+next_ID)
		y_coord = mainmemory.read_u16_le(0x000d2c+next_ID)
		
		status = bit.band(mainmemory.read_u16_le(0x00118c+next_ID),0x0005);
		
		if(next_ID == 0x02) then
			gui.drawRectangle(x_coord-camx-0x08,y_coord-camy-0x08,0x10,0x10,"blue");

			
		end
		
		if(status~=0) then
		
			enemy_HP = mainmemory.read_u8(0x00103c+next_ID)
			
			if next_ID ~= 2 then
				gui.drawText(x_coord-camx,y_coord-camy,string.format("%d", enemy_HP));
			end
			
			draw_cross(x_coord - camx,y_coord-camy, "red");
		end
		
		next_ID = mainmemory.read_u8(0x000C4c+next_ID)
	end
	
	emu.frameadvance()
end
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Just judging from your addresses, it's somewhat unusual for a large-value variable like position to be starting on an odd address. You will likely find your supixel values at 8262830 and 8262902, respectively. I'm not familiar with the coordinate system in this game, but it's possible it may even be a 4-byte value starting from those locations.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Right, the title is a bit misleading. The effects and garbage showing up though may have some alternative uses though, which is the main thing I was pointing to.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Just thought I'd leave this here in case it might be useful: Link to video
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Specifically, scenes at 11:09, 11:36, and 12:18.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Green has a lot of the best offensive power in the game, but is by far the slowest. The ground teleportation (which isn't actually teleportation; the hitbox is similar to a roll) is only slightly faster than walking the same distance. If you take Green to Stage 4, it is even difficult to keep pace with the collapsing bridge. There are a few aspects of Blue that might not be apparent from watching alone. The first is that the dive attack ties your vertical speed to your horizontal speed. This means that starting the dive a little sooner or later in your natural descent can have a pretty drastic impact on your overall movement speed. The second is that every dive attack is invulnerable to certain types of hitboxes. For other characters this doesn't come into play as much because of limited horizontal movement, but this really makes a difference in setting up positioning and paths for Blue. Just a comment on the Zenki comparison, I agree that I would have liked more detail in the sprites but I think the gameplay would have been negatively impacted. The balance of enemies and shots on the screen is already skewed towards difficult, but it's still pretty fair. The game you're thinking of is Kishin Douji Zenki: Battoru Raiden with the TAS by Dooty.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Very well done! I saw a number of improvements in this final version that weren't present in the WIPs either. It's still a shame that train death cycle is so long though. Yes vote from me. Now that Best Ending is out of the way, I wonder how much time would be shaved from a regular any%. Silver dragon has some pretty unique uses in stage 5, on top of Blue just being so fast everywhere before that. That said, I can't imagine the difference being that much more than 30-60 seconds after all the lost time from waiting on gems comes through.
Post subject: [GG] Sylvan Tale
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I did some work on this game for RTA purposes and have some useful tools and information to share. First off, this is a fantastic little adventure game much in the zelda style. Quick dungeons, a central world, and quite a few optional collectables. I routed out 100%, but any% should have some interesting pieces to it as well. I have a lot more technical details available in my notes, but for now keep this in mind: -Perfect horizontal/vertical movement for each character is given in terms of value + subpixel values. Mouse is fastest, moving exactly double the rate of a walking human. Moving in diagonal will move you at approximately .7x your normal rate in both directions. -Zips exist, although currently are only useful in a couple locations. The hitbox checking has bugs specifically for the Mouse that let you slightly clip into seams in some tilesets. The main use comes from moving the iron balls with the magnetism from either underneath or right, and then using turtle to complete the clip into a wall. Turtle is best because the clipping operates on sup-pixel positioning for continuing zips. -For any%, some skips are possible, but unfortunately there are some hard story triggers that prevent skips. For example, there is a barrier in Turtle Altar until you pick up the Lamp. It would be possible to progress through the Altar without the Lamp, but it doesn't even let you experiment with that. -Lots and lots of quick kills are available for bosses. I found a number of setups in my run that are pretty close to optimal, but I'm sure some can be improved further in a TAS setting. The VoD is available here for reference: https://www.twitch.tv/omnigamer/v/82447016 I will post my hitbox viewer script later when I get access to it again.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
That's a shame then. I noticed the train cycle being an issue during my earlier theory TASes, but I thought the full cycle was around 10 seconds or so. I might do some testing soon to figure out the exact requirements for the scene cutoff. Though unlikely, it may even be manipulable if it's based on something other than the background cycle.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
So a couple things on that. I am almost certain Blue will be optimal for stage 3 once it tightens up a bit because the ending sequence (after you kill the train) varies a bit. I think it's based off of the background cycle, but I'm not exactly sure. Comparing the two, I think your stage 3 blue is pretty close to the threshold for an earlier ending cycle, which makes the difference of quite a few seconds. Only other thing I noticed from stage 3: the laser from the jellyfish can be passed through via a dive attack. You can just barely land on the edge of the platform and avoid being hit for the two jellyfish that are left. It may or may not be any faster than your current movement through that area, but I wanted to bring it up anyway. I was working on a theory TAS for hard mode that was meant to represent real-time strategies. I finally got around to finishing it up a little while ago. I think everything you've done so far is superior to what I went with (as it should be) but I'll post it here anyway in case there are a few details. This is the Hard any%, so silver dragon wheeee. Link to video
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Bug: Version 1.11.6, Game Gear core When using Trace Logger, if a file is selected and being written to, it continues to write to that file regardless of the state of the "Logging" button. There may also be some problems with RAM Watch/Search not updating correctly for this core, but I need to further investigate if there is something else happening toward the end of those frames. Currently there is a discrepancy between some values shown in the trace log and those shown in RAM Watch.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I'm honestly amazed this work was finished so quickly! Lots of clever routing throughout and you can really tell a lot of care was taken in planning out movement. Well done Hetfield; now how about some real-time runs? ;) Yes vote.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Needs more dancing. Yes from me.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
RE: Enemy spawns, sorry, I have no idea how they work and it might be fairly difficult to dig into. As for the ones where a set number of enemies spawn, that should be findable, but it may also be different for each different mission. It is hard to say currently. The one general observation I have is that they will always spawn off-camera. In the coordinate system there's a buffer of some number of pixels to either side of what's visible. You can probably accelerate spawns by swapping directions to force the camera over and reveal some while allowing others to spawn etc.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Been a while. I suddenly had motivation to look into some of the mechanics for this game, so I made a helper script. It has displays for current experience of equipped parts, damage values for shots, HP values for enemies, and hitboxes for most attacks. You can toggle between raw experience values for parts and the in-game percentage by pressing D with the script active. For the best experience, use with BizHawk 1.11.6 or later. http://pastebin.com/kB88ca0q Some other minor things I've noted while digging into the mechanics: -Damage from a lower-level weapon against a higher-level enemy will result in a power of 2 reduction in damage. Thus a one-level difference will halve the damage; 2 levels higher will do a quarter of its full damage, and so on. -The opposite of the above is not true; higher-level weapon fire on a lower-leveled enemy still does the regular shot damage. -You need a cumulative amount of 0x8000 part experience to hit 100%. To hit 120%, you need exactly 0xD666 part experience. Different weapons give different amounts of experience. -Part experience seems to be entirely per-hit and does not care about the actual damage done. This includes leveling your mech by sitting around and getting pelted. -The coordinate system is somewhat of a mystery, but it does have sub-pixel precision at least within the camera view. This means that a few tricks or otherwise may rely on that level of precision, assuming they exist at all. I've got a pretty good feel for the game coding flow in general now. The data structures they set up are pretty straightforward and consistent. If you have specific things that you're curious about, let me know and I should be able to pull it up pretty quickly. Good luck!
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Sadly, the colors are correct. I have tested on original cart and via flash cart. Upping the levels can make it look "right", but it is, for whatever reason, supposed to look dark. Good to see improvements! This is one of those games that is maddening to play in real-time, but is probably a pretty fun exercise when deconstructed for a TAS. Yes Vote.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I haven't watched the full run to completion, so I'll reserve my comments on that for later. Did you apply any brightness or contrast changes to the encoding? In my experience with playing on emulator and real cart, the game is strangely dark, which is not present in the encoding.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I assume you are doing the True Ending route if you are using Green in Stage 2? If so, Green is definitely the best choice for Stage 2 just because the terrain makes it troublesome for movement of the other forms (although Blue is still fastest overall). As you've seen, his attacks are well-suited to the bosses and minibosses as well. With Green out of the way early, it's harder to say which of the two forms is best for the remaining stages. I tend to like Red for 3 & 4 since 4 is almost entirely autoscrollers, but for stage 5 it's a toss-up what works best in a TAS setting. It depends on how much time is actually spent using Blue's dive over the rocks saves vs what the faster overall movement would save during Stage 3. In any case, it's looking really impressive so far! Keep it up!
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
DiscoRico wrote:
How efficient would it be to take a console-verified TAS, re-sync it on console, record that input, and take that input to compare to the original movie? You should be able to see areas where your code could improve, seems like.
I'm not sure what you'd accomplish by doing this. It should be simple enough to make your own inputs log from an already existing TAS, however I have not made a script to do this. Having it play back successfully on console will depend largely on the accuracy of the emulation for that particular game and possible inconsistencies in the hardware itself.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Newest version of this project is up. Major new change is that the logging and playback software/firmwares have been merged so you don't need to load a new firmware whenever you want to switch. Also a much better GUI and more consistent logging in this version. Finally, I included a side project, my Input Mania inputs visualization, into it as well. That said, still lots to improve moving forward. It works fairly well, but games that are especially susceptible to lag will desync both in BizHawk and on console playback sometimes. In any case, binary and code available here: https://sourceforge.net/projects/inputcontrol/
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
A note on the patterns for the worm miniboss (and possibly a few other bosses/minibosses), his cycles are based on a global timer. So you could reasonably swag around for a small bit of time and still wind up with an equivalent time, so long as you get there right as he goes into his vulnerability phase. EDIT: You will undoubtedly need to manipulate RNG for some of the later bosses/minibosses. I have the address for this (although not at the moment), but the main way to advance the RNG is causing enemy explosions. In some areas it will advance pretty aggressively on its own, but for things like the Centipede you'll want to manipulate an optimal pattern by taking out select enemies on the way.
1 2 3 4 5
11 12