Posts for BrotherMojo

1 2 3
Posted: 2/28/2017 6:05 AM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
Nach wrote:
Any reason why the RNG isn't seeded consistently at the start, and replacing all time-based RNG lookups to offsets from the current frame count? In other words, keep RNG, but deterministically so.
The game is pretty obviously designed with the plan to have no randomness in its gameplay. There is an RNG, but it's only used for "purely visual" effects, e.g.: how dust particles scatter when you clean dust from surfaces, what kind of harmless woodland creature is freed when you clean a floating lump of leaves... and how the camera shakes when you hit with an attack or fall hard onto a surface. Given that, the fact that camera shake could affect how entities load and unload seemed like an oversight, and so the logical solution seemed to be to just correct that rather than merely make it predictable. ...that said, I understand that's not exactly a decision made in the interest of "being faithful to the original release." The mod is developed for Dustforce players as a whole, it has quite a few great features for TASing but some of the decisions have also been made with the RTA player-base in mind. In that case, the decision was made so that determinism would be preserved on an individual-level basis, so if you miss a critical attack on a group of enemies, that means you positioned yourself incorrectly, or mistimed it, or some other mistake on your part as a player, rather than having gotten bad RNG. Also, because of how the RNG is used, a deterministic RNG could theoretically be implemented for a locked 60 FPS framerate, but normally the RNG can be called any any time a frame is drawn, which would potentially still result in desyncs as framerate climbs and dips normally.
Posted: 2/27/2017 8:40 AM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
Frames, for input purposes, the game tries to keep locked to 1/60th of a second. If things are bogging down, the game will try to poll inputs and process game logic at 60FPS even if it's not rendering at 60FPS. Summary for parsing is a little more complicated than that. I think it's that a line of numbers is an input frame, and anything else is handled as either a command or a comment (i.e. not a frame), but I'll have to get back to you after confirming with msg555 on how exactly Dustmod parses a TAS script file. Regarding load times, the game has 75 levels that are played in the TAS distributed across 3 different "nexus" stages, and playing through the game will involve loading a nexus, then loading a stage from that nexus, then returning after finishing the stage, etc. back and forth. Including the two extra transitions from the "Main Nexus" to the "Nexus" and the "Main Nexus" to the "Virtual Nexus," there will thus be a total of 152 loads over the course of an ideal "all levels" playthrough. ...though hm, there's a trick which lets you skip one load time by going straight from the final Nexus level directly to the Main Nexus without visiting the Nexus in between. Measuring in this fashion, that would take about a quarter second "more time" than just exiting the level followed by exiting the nexus if you don't count load times. We're trying to optimize for real time regardless, but that's slightly awkward.
Posted: 2/27/2017 7:25 AM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
Information regarding Dustmod is available at the developer's blog, and information regarding the TAS script format, specifically, is listed in this post. There are a few commands, such as LOAD, that were used during the development of the TAS but aren't necessary for a full game playback (and the use of which could be considered cheating, since they allow the user to forcibly set certain aspects of the game state such as character position). A full game playback currently only uses: - input lines: which game inputs are being pressed for a given frame - MOUSE commands: act as though a mouse click is happening at a specific point onscreen simultaneously with the next frame of keyboard/controller input, used 4 times during the run - SYNCLOAD commands: wait for load time to complete and for the user to regain control of the character Optionally, INCLUDE commands can be used to allow the script to be broken apart into several files, but the full run could be compiled into a single script file instead. It's comparatively easy to get "frame count excluding loads" by just taking the number of input lines in the script or script files in question. On the other hand, the full length including loads will vary according to the computer it's being played back on. The biggest potential issues I currently see are: - "video-frame length" will vary by computer or potentially playback-to-playback because of variable load times. - the format is currently "dumb" and doesn't include metadata, because it's designed to be human-readable and -editable. But we're fairly certain any viewer with a copy of Dustforce who has installed Dustmod could reset their game save then play back the same input file and get the same result, though again load times may vary. So, if this does not meet requirements, what can we do to correct these issues?
Posted: 2/26/2017 5:07 PM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
To be completely honest, a vanilla game would probably play back the inputs properly. Not as in "we're pretty sure that it works the same," but "there's unpredictability in the vanilla game." Dustforce as a game was designed with a lack of randomness in mind. In theory, everything should happen the same way every time if you use the same inputs. However, there are a few situations with asynchronous race conditions that make this not necessarily work out. For example, rarely during level loading, an extra frame worth of world time will take place before the timer starts and the player gains control of their character, making enemy positions line up slightly differently over the course of the level. Little quirks like this make syncing playback reliably almost impossible, and the fact that unintended randomness could potentially make or break an IL is nightmare for the competitive scene as well, so one of the Dustmod features is to force things to work out as they most commonly would on vanilla and remove those hiccups. This does mean that if one were to try and make a pure input+timing sequence that would play on the vanilla game, however, it would most likely desync somewhere in one of the 150+ level fadein/fadeouts over the course of the game. All that said, however, we've also done our best to ensure that Dustmod remains mechanically identical to vanilla Dustforce. Composed replays play back identically on Dustmod as they do on the original (Windows) game... again, exception being that if your computer is lagging during level loading or something similar, a replay might desync on the original, but will always work properly on Dustmod.
Posted: 2/6/2016 7:22 AM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
Well I feel pretty silly for not thinking of that... though really, by the time I was paying a ton of attention to options like taking damage to prevent fatal falls, I was focusing more on finding skips elsewhere (e.g. area 5, area 3 -> area 8, etc.) than on Area 7. I mean, I'd already found the skip in Area 7, right? :p
Posted: 10/26/2015 12:16 AM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
Working with the replay format is pretty awkward, since it seems to allow for a variety of impossible inputs... e.g. up+downdash, downdashing and then dashing on the next frame, etc. Also I'm a bit confused by how inputting jumps works, since if you don't put a string of 1s in the jump column, you get a short hop, but if your string of jumps is too long you get an airjump, and "too long" can vary. It's also pretty annoying having to rewatch your entire TAS to see the effect of the changes you made at the very end. However, the possibilities are still quite exciting. I'm messing around with a Dustkid:Ruins:Score TAS and it's going pretty well so far, though I think I may have accidentally "published" an unfinished run >_>.
Posted: 6/14/2015 5:09 AM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
Wow, this game looks vicious. What are the significance of the "M" scrolls that the witches leave behind? Understanding them could solve the mystery of 100% vs. any%... has anyone other than the author ever played this game? :S And on the note of optimization, in a few spots it looked initially like it may be possible to push things into place with bubbles rather than doing so manually to save a few frames, but on further examination the awkward mechanics disallowing turning without taking a step likely prevent that from saving time in any of the spots I looked at. The run also seems to avoid the problem where many puzzle game TASes look more like walkthroughs than speedruns due to slower mechanics... quite a few spots appear to have quite tight timing that would be difficult if not unreasonable under more casual conditions. Overall, I was quite entertained, though I can understand why many players wouldn't be. Yes vote from me, for what it matters.
Posted: 3/13/2015 7:43 AM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
Absolutely beautiful. I loved the careful management of homing lasers in chapter 4, so as to chain the enemies behind you outside of the central chamber without having to ever stop eating that delicious bullet spam. Gorgeous!
Posted: 8/20/2014 11:55 PM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
So most of this run is amusing, but Mike Tyson's Hokuto no Mechwarrior had me laughing so hard I could barely breathe. Crazy glitches in an even crazier game, I love it.
Posted: 8/19/2014 6:12 AM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
Dooty wrote:
Also, a "Yes, your run's quite good" sometimes is all a TASer ask for, as it shows that people is supporting his effort.
It's true, but that doesn't change the fact that it's not something that feels good to say. Forum conversation isn't really like actually talking with a room full of people. If someone says or presents something that people approve of, you'll get a lot of murmurs and gestures of appreciation from the crowd. In a forum, however, it takes a lot of effort to actually put those feelings into words... and generally if all you can say is "quite good" it feels awkward. That's often how I feel at least, because I feel like I should be saying more but can't find the words to do so.
Dooty wrote:
Lots of sites require the user to have some kind of "fidelity" to the comunity before one can download, or upload something to the site. Isn't it time to adopt something similar here?
I have to agree with Patashu and mklip2001 here. We already have the review system in place so low-quality runs, whether due to trolling or otherwise, generally won't get published. A rejected submission isn't much different from a WIP and a forum post. Most sites that have such a restriction do so for space and bandwidth concerns. I suspect the site doesn't get so much throughput that the handful of megabytes that the input file and submission text take up could really be a huge problem unless somebody somehow rigged up a bot to spam enormous numbers of submissions.
Posted: 8/15/2014 10:03 PM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
feos wrote:
This run may be optimal, don't know, but how it looks like is completely, totally unbearable to me. The thing that takes a second to do (jumping) repeats thousands of times only changing direction. I tried to look at the later parts, but there it gets only MORE ridiculous! You must JUMP on the same block SEVERAL FUCKING TIMES. WOW. HOW ENTERTAINING.
In terms of gameplay complexity, it actually gets a lot more interesting in later levels where jumping on tiles that are already the "correct" color reverts them to their original color, so backtracking must be much more carefully considered. That said, it is still 22 minutes of Q-bert, which normally isn't really a spectator sport when compared to many of the games run on this site.
Posted: 8/15/2014 9:56 PM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
Dooty wrote:
I just don't get why people pay attention to this kind of submission, when there are lots of legit runs which have almost no replies...
It's because trolls will automatically gain more attention than people doing solid but uninteresting runs of games no-one knows much about. "You sure did play that game really fast I guess" isn't really a post that feels good to make, but sometimes that's all you can really say after watching a run. And sure, it is an assumption that this person is a troll rather than just a newbie... but I'm assuming that a person who joined two days ago, was online for barely over a minute, made 0 posts, and submitted "the best TAS ever" in the "51%" category is a troll rather than someone who's just legitimately confused. I think that assuming this is all part of some elaborate and obscure joke is both the more interesting option as well as the more positive one. If MegYesDKNo really is just new to TASing, I recommend he take some time to do some more research before launching into any future projects. Sure, it takes 30 times the work to spend a month making something good than to throw something together in a day... but the end result is more than 30 times more satisfying. If you're merely uninformed about what this site is about, I recommend reading the FAQ, welcome page, submission rules and guidelines to get a handle on why people are reacting poorly to your submission. If he is a troll, on the other had, I still recommend putting some more effort into it. More people would be able to subject themselves to your creation if you had included an encode on youtube or a similar site. Most rerecording emulators will export a video file, and it doesn't take much work to learn how to produce a passable encode with something like virtualdub. Alternatively, a little more work can add additional layers to the joke, such as uploading your two-hour encode in segments out of order, or recording it by filming your monitor with a hand camera as your emulator plays back the TAS.
Posted: 8/6/2014 2:32 AM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
Those loading screens are pretty oppressive... makes this run an absolute snooze to watch. :( The glitches are amusing, so this run is pretty entertaining in concept but it doesn't make a very good video.
Posted: 4/8/2014 8:45 AM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
Patashu wrote:
The run on the site would have to ban S+Q and teleflings to be optimized for its category - it's simply outdated with all these new finds.
Which is why I lean toward not obsoleting it and instead tagging it "no S+Q," then waiting for someone to make an improved run in that category.
Posted: 4/8/2014 8:37 AM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
I love being present at the moment when a speedrunning community breaks a game in half... <3
thatguy wrote:
One question remains: to obsolete or not to obsolete? I'm leading towards no because I don't want to see such a great run disappear.
"No save+quit" would be a fine category, I think.
Posted: 4/5/2014 4:46 AM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
WST wrote:
I tried TASing some of the games from hamumu.com in 2012, and all of them work fine within Hourglass. I abandoned my project simply because I had no idea how to manipulate luck to get destructive weapons as fast as possible.
Many games use the system timer to generate an initial seed for the RNG. See if changing the initial system clock value in Hourglass results in different random drops. If so, it may be possible to manipulate the RNG independently of your in-game actions using only the system timer, which means you don't need to "slow down" to manipulate randomness. Unfortunately, this also may mean you need to do a lot of experimentation with the system clock to get a sequence of random numbers that works for what you're doing, if you need many random events to turn out your way. Also, not all games use the clock for seeding, so it may have no effect at all. Still, it's worth checking.
Posted: 3/14/2014 6:10 AM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
TheBirdOfPrey wrote:
-Wiring SS is based off of specific "fake" dust patches, and specific "real" dust patches, not based on a # of dust collected etc.
I've done some testing, and I'm pretty sure that it's the old bug with dust blocks not counting for the total... the dust blocks at the end are worth exactly 21 combo, and you seem to be able to miss exactly 21 combo worth of dust throughout the level and still SS. I tested and there are no specific patches of dust that can't be skipped and still get an SS... aside from those patches of dust that are just impossible to skip whatsoever due to their positioning. It's possible to SS with a 269 combo at the end (even less if you kill the last enemy with an attack rather than a super, but that's because of some strange properties of the level end trigger... a super which ends the level counts the combo of the last things it cleans, attacks that end the level do not), and it's possible to AS with a significantly higher combo, but that's due to heavy attacks scattering dust. That dust can be picked up to increase your combo, but it also adds to the total dust count of the level. Notably, the blobs in the level have 3 HP and thus are worth 3 combo... but there's no partial credit. If you hit a blob twice and skip 19 or 20 other dust, you'll get an AS rather than an SS as if you had lost out on all 3 combo from the blob.
Posted: 6/21/2013 11:40 PM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
I would also approve much more of the non-glitched ending. The glitched ending is funny if you know what's going on, but the clean ending is far more satisfying in my opinion. If anything, I'd want the glitchy one to be the alternate encode, though it kind of loses its reason for existence in that case... ...which I think it actually a good argument for why the "clean" ending should be the official one. If the glitchy one is the main one, the clean alternate would exist to "validate" the glitched ending. On the other hand, if the clean ending was the main, than the glitchy ending basically falls to being nothing but an in-joke anyway... and really, I think it'd be better not to give publication priority to the in-joke.
Posted: 6/17/2013 3:55 AM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
natt wrote:
Mouse support? First, brush up on your winapi messaging; you'll definitely want to know all of the ins and outs of all the possible WM_ related to mouse.
I'm already reasonably familiar with that stuff, I've done some game programming before... and for what I don't know, I know where to look to find out. What I'm trying to figure out is all of the places where the mouse-related code would need to go. It needs to be picked up while recording, it needs to be stored in the resulting file, and it needs to be played back later. Am I missing anything? And where in the code are all the keyboard equivalents of these actions? Presumably I'd want them to be in the same place. Also, I know that in DirectX, there are ways to access the actual mouse X/Y velocities that Windows later interprets into changes in mouse cursor position and all that. The WM_ messages seem to all pertain to after that interpretation takes place, since they reference things like the X and Y location on screen where the mouse (has moved to, has clicked, etc.)... I'm not sure if it will be relevant for Dustforce, but does anyone know how those functions could be hooked into?
Posted: 6/17/2013 2:41 AM
(Edited: 6/17/2013 3:12 AM)
Post subject: What do people actually know about the Hourglass code?
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
I've been thinking a lot about TASing Dustforce, but I think I've gotten about as far as I can without actually just diving in and doing it. So I downloaded the Hourglass code to take a look at it to try and figure out how I might go about hacking in some super-simplified mouse support, and well... it's kind of a nightmare so far. I know that people have hacked in other features in the past (e.g. MIDI support for my Nikujin run) so have there been any efforts to actually document where in the code things actually are? The comments in the actually code are fairly inadequate, and it would be unfortunate if every time someone wanted to make any changes they'd have to try to figure out the whole program themselves, so if there isn't already somewhere people have started tracking this stuff, perhaps there should be.
Posted: 6/16/2013 9:07 PM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
Warp wrote:
It's not like this is a question of mathematics, like "what's 4 times 7?"
Indeed, but that's because it's a question that is, at its core, subjective. It's interesting to discuss, but eventually people will have to come to their own conclusions. There's more than one "right" answer, hence the establishment of different categories. But as interesting as the discussion is, it isn't really the issue at hand for this thread. This submission is already being targeted at the "glitched" category, and as such, for the purpose of this thread we should suspend our disbelief (if any) and accept "displays the end screen" as the meaning of "beats the game." That doesn't mean that will always be the win condition we accept, but even in mathematics we always have to begin by accepting some assumptions. Even a question like "what's 4 times 7" makes some assumptions about what "4" and "7" are, as well as what it means to "multiply."
Posted: 6/12/2013 8:27 AM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
Voted meh, because despite the level beginning at 13:39 being basically the best thing ever, the game has an unfortunate amount of running directly to the right slaughtering boring and entirely ineffectual robots.
Posted: 5/31/2013 7:15 PM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
Ilari wrote:
Not faster in long run: 60 sp/f (running) vs. 64 sp/f (jetpacking).
...wow, really? Doesn't running normally move you at 55 sp/f? The conveyor adding only 5 sp/f to that seems pretty strange, especially compared to how slowly you move when running opposite to a conveyor.
Posted: 5/31/2013 5:31 AM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
slamo wrote:
I did try this route first - it's necessary to get the second tank, and by the time you get near the exit the worm is perfectly getting in the way of the last 5 gems, and you can go around but it costs time. It's about a 0.7 s difference between the video I posted.
Hm, unfortunate but it makes sense. How about running on the conveyors that are travelling the same direction you are? It feels a bit faster than Jetpacking when doing it over long distances, but that could be an unfounded belief, and on top of that I'm not sure about in short bursts.
Posted: 5/30/2013 8:11 PM
Quote
BrotherMojo
Experienced Forum User, Published Author, Player (228)
Joined: 4/25/2012
Posts: 73
Um, so I still think that this should be faster for level 02... I think the only potential issue is fuel, but in this route you cover less ground as mentioned, and you end up falling down that long column on the right rather than flying up it. Plus if necessary you could use the yellow teleporter twice to pick up the other tank, if that doesn't use up enough time that you run into the worm. Also, is it not possible/not faster to touch down on the conveyor belts that actually are travelling the same direction as you, and only fly over the ones travelling the other direction? Even if it's not actually faster it could be considered as a way to save a little bit of fuel. And similarly, even though it's a bit slower to run, for long horizontal stretches like the top it may be worthwhile to touch down if that can save you a detour to pick up more fuel. Even if my route ends up slower, you could also experiment to see if it's possible to save enough fuel on your route to need only one tank. EDIT: So I just played through the level at full speed. Even with my human inefficiency, I easily made it to the yellow teleporter before the worm reached it, and even without picking up the second tank I only barely did not have enough fuel to reach the exit on one tank, though that was with walking along the top and the conveyors to save fuel. I wouldn't be surprised if taking a quick jump through the yellow teleporter would save more time overall.
1 2 3