Posts for Omnigamer

1 2 3
11 12
Posted: 7/30/2018 6:01 AM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
It has the potential to generate a better monster, yes. Better, in this case, just means perfect selection of stat seeds. There are 2 stat seeds used to create monsters; I have the stat table for at least one of those seeds, it is unknown if the second seed uses the same table. For example, using the values from this table, and assuming that the game uses the same table for both seeds, you could possibly generate a monster with dual Seed 34. This would give a magic-based powerhouse, if that was the particular strategy you were trying to set up. Or perhaps a balance across the board would be better. It's all a planning game at that point, but you are still limited by what's already in the stat table.
Posted: 7/29/2018 4:33 PM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I think what NK was referring to was getting back to this exact monster type without generating from a disc. That would involve waiting for Pixie to be in the seasonal market rotation, and also doing an abundance of quests (including training another, separate monster) until you could obtain an item that would give the dragon subtype on combine. The game is intended to be played with monsters generated from discs; you are severely limited in your options otherwise. For an SRAM-anchored movie, it would be set up as a NG+ scenario. With an appropriate SRAM that enables all monster types and has the ranch built up enough, any possible monster that can be generated could be used. This increases the number of monsters you can work with by about 40%, but also changes strategy a fair bit. But to the core of your question, no, having an SRAM-anchored movie would not be enough to avoid using a separate, specific disc. Unless, of course, you allowed for modifying the SRAM to also incorporate a monster, which would allow for any arbitrary type or stats. If you wanted to allow SRAM modification as a means of bypassing using another disc altogether, I think you'd still have to share the appropriate TOC values that would resolve the monster in question. This isn't possible yet, but with a bit more reverse engineering and research probably could be. FWIW, the Pixie/Dragon "Daina" used by NK in this movie is a good monster, but possibly not the best. It is also not a "special" monster; many different discs have been found that can resolve it. Other stat seeds may lead to a better overall monster, depending on the strategy. It may not even be an optimal monster type, but it's a very wide pool to search through and strategize for.
Posted: 7/29/2018 3:31 PM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
The data used from the TOC are the following: MR1: -Total CD time (minutes, seconds) -1st track seconds -Total tracks MR2: -Total CD time (minutes, seconds) -1st track seconds -Last track seconds In that context, sure, it is not hard to create a "perfect" disc. However, the amount of things you can control even with perfect control would lead to only a marginally better monster. That, and it's perfectly reasonable that a commercial disc might exist that resolves to the same set. There are several hard-coded monsters in either game, where specific exact TOC values resolve to a special monster, usually of a unique breed or stats. For example, using the MR1 disc in MR2's shrine creates a Sueki Suezo. This special monster is unique and has great stats across the board, but only lives one week. In MR2, a number of breeds are locked out from a new game. Even if you make a disc that would resolve to them, you would not be allowed to recruit them until meeting certain in-game milestones. This limits choice for some of the more powerful breeds. As far as I remember, monster generation from discs is the main way you're supposed to obtain new monsters. I think MR2 also allows you to buy monsters, but they are only of basic type and stats. NK mentioned combining monsters - which has the potential to lead to some extremely powerful monsters, but afaik is not fully understood. You still need monsters to combine to begin with, so still requires generation from disc to be functional. Without special in-game items though, the combining typically resolves to something like mixing the major breeds and averaging stats between them.
Posted: 7/28/2018 12:59 AM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
For this specific game, if I'm remembering right, out-of-range values are either empty lines in the data tables or are zeroed out, depending on the case. That doesn't really matter for setting precedent, but I also don't know how many other games use a system that allows for arbitrary discs.
Posted: 7/27/2018 1:51 PM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
From the game's perspective, they are all legitimate discs - it doesn't care where it came from. Any arbitrary burned music CD also generates a monster just fine. Limiting the disc pool to only commercial releases is an arbitrary restriction to the game, and significantly more work for a player to find an appropriate disc. For what it's worth, generating a disc does not trivialize strategy. The breed, sub-breed, and stats cannot be finely controlled. You can control two individual stat seeds, where each seed contributes a set amount to each attribute. For example, Seed 0x17 might give a POW a boost of 10 points, but takes SPD down by 8. IN MR1, there was also the caveat that one of the seeds also directly determined subclass, which gave a breed/stat tradeoff. There is challenge in identifying the best stat seeds and monster types for a given strategy, even with complete control of monster generation.
Posted: 7/27/2018 2:13 AM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Hi. I haven't watched the run for this yet, but I might be able to provide a little more info for standardizing these kinds of games. As discussed so far, Monster Rancher 1 and 2 have a special feature that allows reading from arbitrary discs to create a monster. What's actually read from the discs has long been studied, and while accurate information is out there, a lot of inaccurate stuff is out there too. A while back I spent some time reverse engineering the monster generation algorithm in Monster Rancher 1. It was pretty straightforward, and used only a few values from the disc TOC. I used this, as well as some data tables in the game, to create a program that generates arbitrary monsters with appropriate stats. You can find it here: https://github.com/OmnigamerSDA/MonsterMaker Monster Rancher 2 uses slightly different values from the TOC, but still functions in mostly the same way. The stat seeds, monster breeds, and subbreed tables are also currently unknown, but that's fairly straightforward to find. The game has more caveats - a number of breeds are locked right from the start, and others require larger barns and other ranch buildings. This just means you can't access all of them from a fresh file though. In any case, for future submissions, I would recommend using these generated ISOs instead of mandating specific commercial discs. There's no equivalent Maker for MR2 yet, but it shouldn't be too much work to develop. I just don't have the time to put in on it for at least a couple months.
Posted: 7/26/2018 6:41 PM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Great work by sniq! This has been a year or more in the making, and I'm glad it's all wrapped up. There were many new tricks and mechanics discovered over the course of making it, which I think led to a very entertaining improvement. I'm sure sniq will cover this in the submission notes, but there are a couple instances throughout the run where the RNG is good, but maybe not the best possible. This occurs in several places that require a sequence of several RNG calls to resolve to appropriate values. Sniq landed on the best sequences he could find without exhaustive testing, but there may exist better sequences in the game's (relatively short) RNG cycle. To test for that would require a custom script for enumerating through the RNG, which is not too difficult but just doesn't exist yet. So that's the most likely place to find further improvements of a small handful of frames. Main instances include: -Boss 3's movement patterns -Stage 5-5's flame cycle timer & Boss 5
Posted: 6/9/2018 10:25 PM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I have no idea what this submission is trying to show. Aside from the obvious Early start, the choice in input timings don't seem to fit any reasonable goals. The author goes into 4th gear at around 5 in the countdown, but doesn't engage the gas until what would be the proper race start. You can start motion as soon as you're in gear, so if the point of this new submission is to go for fastest real-time despite an early start, motion should start as soon as the countdown starts. If the goal is to show fastest time assuming a start in 4th gear, ignoring the early start condition - already a bunch of strange restrictions - the chosen inputs are not optimal at all.
Posted: 5/26/2018 6:07 PM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Some additional info: -JP version and US version differ in how jumps operate. They still cover essentially the same distance, but US jumps rise faster, remain at the top longer, and fall faster. JP jumps are more "normal" with how a jump should actually operate with respect to physics. This matters mostly for positioning. -There's a bug with damage and deaths. I don't have the addresses right now, but there are at least two weapon-related values: weapon level and damage. Damage is a function of weapon level, but maxes out at 2 or 3. Weapon level alters the animation and range. However, on a death, the game goes through a routine that effectively does this: weapon_level--; damage = weapon_level; Since weapon level maxes out at 6, and damage is normally at most 2, this can give a substantial damage attack boost. It has the caveat of needing a higher weapon level to be effective though. The current RTA runs use this bug starting at the Mudman boss.
Posted: 5/25/2018 10:09 PM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
The cycle for a natural Hagane RNG is something like 1700 values - I only logged 500 because that's approximately how many are useful for real-time planning. I have a Matlab script for calculating the full sequence, but it should be very easy to recreate in just about any language. I mention "natural" here because it is possible to start the game with a corrupted RNG seed, among other things. Oddities related to this have happened to me numerous times on console, but really shouldn't be considered for a TAS.
Posted: 4/21/2018 8:26 PM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
They aren't among the registers available by emu.getregisters() on any of the cores I've tried. Direct attempts to read the registers via the system bus also turn up as 0, though I think this is because a "read" of those addresses isn't supposed to return the address contents, but register contents. It would be a different story if the read were an actual instruction, but that's not something lua can currently do, as far as I know. EDIT: Submitted as a feature request to the github.
Posted: 4/21/2018 7:37 PM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Is there any way to easily obtain the current V/H scanline positions for a variety of retro cores via a mid-frame lua event? Some of the trace loggers provide it as part of their output, but I haven't seen any functions that expose it to users. Some systems provide hardware registers for that purpose, but it looks like a number of them need a software trigger to actually latch the information.
Posted: 4/4/2018 11:18 PM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
So a couple things: This movie is the same as the prior submission, simply with one input removed. Even if that's all that you needed, if your new goal was to optimize for real time, you could have chopped all the inputs after frame 476 and still achieved a 5.57. Even so, this is very likely not an appropriate starting seed to optimize for real time. There are up to 14 frames to save just from starting the race on an earlier seed. In any case, I don't think that real-time IGT optimization is an interesting goal for this game, relative to the other existing goals.
Posted: 4/1/2018 12:21 AM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I'm glad you found a way to manipulate the geese with current emulators. I briefly investigated the game some months ago, but noticed in this disassembly that it polls for input multiple times per frame. Through some testing I think I found that you could actually have motion without spawning any geese at all, so long as you weren't holding the button at a certain point in the frame. But that kind of manipulation isn't possible in current emulators, so I'm glad there's something else that works for the same purpose. Any thoughts on trying the other game modes? With this much understanding it's just more of the same, but I'm curious what the maxouts are for the other modes as well. Yes vote from me!
Posted: 3/27/2018 5:07 PM
(Edited: 3/27/2018 5:09 PM)
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Thanks for the offer MrWint. I understand feos's points, though. It's not a big deal one way or another, so it's probably best left up to a decision of the publishers/editors. Do what's consistent to the rules and goals of the site.
Posted: 3/27/2018 3:36 PM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I don't want to be "that guy," but it's been bugging me so I'll ask: What are the typical conditions for co-authorship on improvement submissions? I don't want to take anything away from MrWint, who has done a lot of his own investigation into the game mechanics and developed his own programs to verify results. However, I can't shake the feeling that this is still basically the same as my original submission. The major improvement is swapping players to gain a one-frame advantage due to processing order. I admit this was an oversight on my part in the original submission; I had it in my head that I wanted P1 to show the primary goal, and P2 to show the secondary goal. Other than this difference though, the inputs for the primary goal still exactly match my submission's. The other original contribution in this submission is the reworked strategy for the secondary goal. This is a side-effect of being able to move the initial reset earlier due to the primary goal being on a different frame counter "boundary" than before. As such, it is original compared to my submission. The new tertiary goal is not something I considered, but is fair to serve as a "tiebreaker" of sorts. The one-frame advantage on this goal would have been a one-frame disadvantage if my submission's inputs simply swapped players. It is lucky that between both input sets, they end at the same point in game time. Again, not trying to detract from the additional work the MrWint has put into this, and I'm not trying to raise a stink. I'm not familiar with a lot of typical practice for TASVideos submissions, so I don't know the situations and scenarios that merit co-authorship. I just can't shake the feeling that a good chunk of this new submission is essentially the same, only changed by a technicality.
Posted: 3/26/2018 3:22 PM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
For clarity, could you list the frame that input ends for the "fewest inputs" goal between my submission and this one? I think it might be a little misleading to some folks when you mention a 20-frame improvement, but the actual difference in when the last input was entered is only 0-2 frames. Good job! You might also consider using the tool from Benoit Esnard to double-check your program outputs: https://github.com/esnard/dragster
Posted: 2/24/2018 4:09 AM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
It's worth clarifying that this is the SMS (E) version of Psychic World, and not any of the Game Gear versions.
Posted: 2/2/2018 12:23 AM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Ben may provide the schematics and a BOM once he gets them a bit more organized. That's what I suggested during our last chat, anyway.
Posted: 1/3/2018 5:46 AM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I don't know any specifics on it other than it's something Ben wants to do in the next few months. He mentioned making at least 3, but since the volume is already so low it shouldn't take much to ask for a few more boards. Either way, if he sends me one I'm fine with passing it on to the TASBot team.
Posted: 1/3/2018 2:02 AM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
From my discussions with Ben, he plans to turn his test setup into a single PCB and send some off to other folks who could make use of it. Supposedly one is coming my way, but I don't have much use for it since my Atari is toast. Perhaps it would better serve the TASBot folks?
Posted: 12/26/2017 3:37 AM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I was browsing through this file because it's a good resource for console frame rates, but noticed that it hadn't been updated with info for a few of the recently added consoles, particularly N64 and Saturn. Does anybody have info for those?
Posted: 11/2/2017 1:00 AM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I second the idea, though maybe with a different implementation. I find that I'm constantly running low on crucial save states for practice and testing. I either have to apply them judiciously, or make separate folders according to the stage of game. Really, the problem is just no straightforward way of expanding the number of "QuickSave" style slots available. Rather than working with folders, it might be easier to implement "sets" of save states, with a button to cycle between them. The set just corresponds to another digit on the actual savestate files this way.
Posted: 10/30/2017 5:51 PM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I echo the prior comments for better support of the various tools, especially trace logging and eventually debugging. Beyond that, I think it would be good to have support changing controller inputs during input poll events, rather than at video frame boundaries. This might only be helpful for a few systems/games, but it's still an extra TAS capability that's not available on at least some of the cores. For us real-time folks, finding a means to lower the frame rendering latency in BizHawk 2.x would help a bunch, too :)
Posted: 10/29/2017 2:43 PM
Quote
Omnigamer
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Hi! I started working on this game for real-time runs, and made a fair bit of progress in diving into the major mechanics. I'll cover that later if anybody has interest, though. The main thing I want to bring up is a glitch I discovered last night that could potentially be used for ACE. Link to video In summary, the game doesn't have a way to handle hitting these particular enemies with flip-kicks, and leads to a variety of strange effects. I've gotten a lot of different things to happen from only slightly different setups. The degree to which it affects video is similar to another bug I encountered in the past for Dragon View, which overran nearly the entire memory space. I haven't taken time to look into the exact mechanics of this bug yet, but it looks promising for TAS use at least.
1 2 3
11 12