Username:
B
I
U
S
"
url
img
#
code
sup
sub
font
size
color
smiley
embarassed
thumbsup
happy
Huh?
Angry
Roll Eyes
Undecided
Lips Sealed
Kiss
Cry
Grin
Wink
Tongue
Shocked
Cheesy
Smiley
Sad
1 page
--
--
List results:
Search options:
Use \ before commas in usernames
Hi. I run Vampire: The Masquerade - Redemption, and I'm having a dilemma whether I should use a console command to change the FPS cap (the engine offers such functionality) mid-run. You can also use the console to load whichever stages you wish, but I think that's obviously considered cheating, and thus much less of a grey area. The hotkey to activate the console only works if you add "-console" to the shortcut.
Why cap the FPS? One, I use it to make a major glitch to skip sequences work conveniently and consistently (if the FPS is uncapped, the chance of it failing increases - as well as the hotkey to do it becoming much more awkward); two, it makes one triple frame perfect trick at the beginning of the game more consistent. Alternatives would be to stomach a less consistent, more RNG dependent way to defeat the first boss, and enable VSync to cap the game to 60 FPS (bothersome because of the game being played in windowed mode and input delay).

Now I understand that most communities nowadays simply establish their own rules on speedrun.com, but for tiny communities such as in the case of VTMR speedrunning, I'm the only person who uses these new strats, so you can imagine my uncertainty.

So, my question is whether it would be categorically against the SDA rules to use the console for submissions of this specific game, as well as if it's typical to make exceptions for cases such as this where I would say it makes all the sense to allow changing the FPS out of convenience - assuming you take my word for it.
Thread title:  
Are we talking about single-segment or segmented runs? And also is there some benefit to having a high FPS in other parts of the run (aside from being generally more smooth and responsive)?
Sigle-segment/Real-time attack. The only application of having high FPS (I think the engine limitation is 100, though) that I can think of would be to skip the dialogue faster with some kind of inhuman mashing of spacebar - based on the fact that setting the FPS to very low makes cutscene skipping quite unresponsive.
So basically if someone comes along running the game on their Atari 2600, they'd gain an advantage in the parts that you mentioned because of having a lower FPS?
No, no - a lower FPS value makes the skipping slower. At 50 FPS you can skip cutscenes very quickly, and I imagine with it maxed out, it would make a tiny difference (frames) if somebody made a TAS, and that'd be it. No meaningful difference for human runners.
Edit history:
LotBlind: 2018-12-25 09:37:34 am
So overall if you had to choose between a fast computer and a slow one, you'd take the fast one for 100 FPS? Just a few parts are faster/more reliable on a low FPS?
I'd say there is like a dozen instances where I have to press Ctrl + Escape to set up a glitch, so to do this reliably I need the game to be at 50-60 FPS or lower. Otherwise, there's quite a significant chance for the trick to fail, and I'd have to rely on a more awkward hotkey (F12), which is slow. If there was absolutely no way to cap the FPS, and I still wanted to use Ctrl + Escape, I'd have to build a crappy PC that runs the game poorly, I suppose. Not sure how else to answer your question honestly.
Edit history:
LotBlind: 2018-12-25 09:59:44 am
Well you can probably see my line of thought here: convenience isn't really, in-and-of-itself, a very strong reason to allow something like this because that particular rabbit hole never ends. Unless there was something about compatibility in modern, supported operating systems, in which case we've allowed even unofficial patches to be used in some cases. But if it's a question of fair competition, it's easier to argue. You could just as well be using external means to make your computer run a bit slower whenever you wanted it to.

We've generally allowed console commands to be used mid-run if they map onto options that were available from the in-game menu. In this game, that would not be the case, and you could argue that the console is there as a kind of debug mode to begin with. This also can't really be called a cosmetic change.

We'll talk about this some more and let you know within a week, if that's okay.

PS: You might already know about this run but just in case it has something useful in it.
Right. From the beginning I was unsure about the whole thing, but decided in favor of it in my own speedruns due to how hugely convenient the setting was - in the case of VTMR the beginning starts out very slow, and is RNG dependent, so it does make for a better speedrun, IMO. It does however allow for performing a triple frame perfect trick consistenly at any point in the run, and while there's no application for it outside the first boss fight for the time being, the possibility is definitely there.

I suppose I could just use two keyboards to make up for the inconveniently placed F12 hotkey, which is hardcoded, and just opt out of the triple frame perfect glitch/find other ways to achieve sufficient consistency without the console. Do you think something like that would be acceptable in the SDA community? The state of the run isn't very optimized as of right now, so I don't have any regrets in terms of submissions, btw. My main goal for the game right now is to seek advice and set the right precedent in my future runs, so I'm glad I was able to shed some light on this subject. Thanks for the timely response and any further information is of course highly appreciated.
Having any amount of control devices plugged in is allowed. That's just the basic workings of a computer.

Did you think about rebinding other keys closer to F12 if that's possible? Also in some cases cheating in your practice runs (whatever that may mean) is a good idea and grinding it out for the submission run much later you can always do.

What exactly does the vsync do BTW? You mean you can't run fullscreen with it enabled? And it also causes unusual input delay? Is that something the game always did or is it a compatibility issue with modern OS?

It'll take us a bit longer to come at a verdict here as I said.
Edit history:
Tionic: 2018-12-29 02:10:51 am
Tionic: 2018-12-29 02:08:27 am
All the hotkeys are hardcoded, so they cannot be changed. I imagine usage of AutoHotKey would be considered illegitimate (it doesn't work anyway), and I also considered using "Microsoft Keyboard Layout Creator" for Windows 7, but its functionality was limited (as in, crucial keys such as Pause/Break couldn't be remapped), and I just couldn't get it to work.

Vertical sync would be helpful to cap the game to 60 FPS, and limiting the FPS helps with the Ctrl + Esc thing. (Skips cutscenes that don't have dialogue. Go to 4m32s to see how it works: ) Vsync only works in full screen AFAIK, and full screen would render the whole glitch using Ctrl + Esc non-functional because the game couldn't really be minimized anymore or it would bug out. The same thing can still be accomplished with F12, but you can imagine how much more of a bother it becomes having to use 2 keyboards. Also, yes - the last time I checked, vsync was making the cursor laggy on a modern system (input delay), but I couldn't say if that's a compatibility issue.
I forgot it's actually allowed to rebind keys using JoyToKey, AutoHotKey etc., in part because we don't really have a means of verifying it wasn't done anyway. So if you can get anything like that to work, go for it. Just actual macroing or anything you couldn't theoretically do using the original control scheme is obviously not okay. Can you try that again? Here's one thread that's about this. Maybe you could try this Sharp Keys idea?

Why do you need to minimize the game mid-run BTW?
SharpKeys would probably work since that appears to be a registry hack, but as someone experienced with the game who feels it would take away from the challenge of speedrunning the game, I'm not going to accept rebinding other keys than F12. It would lead to a change in strategies such as using F6-F9 to change characters over Tab; these keys are not handy and would provide a visible advantage. Personally, I will proceed with 2 keyboard devices for now, as I find that moderately comfortable after some adjusting after all.

Minimizing the game is one way to queue the Escape input into cutscenes (and then use the menu to glitch them) that don't allow said input, but it's not the only method to do so, which is why lagging the game using F12 (takes a screenshot) in conjunction with Escape achieves the same goal.
I think how we'll proceed with this is we'll assume everyone can do the same tricks as you, but if we ever happen to get others running this game, we can't ban them from doing what I described. Aside from non-verifiability, it's generally not going to affect the viewing experience in an adverse way either, which is something of an argument too. Few people watching are likely to think "wow, they really mastered the awkward controls" unless they're really what the game is known for.

The third reason is this kind of system-modding (which isn't game-modding) is typical of PC users anyway and it's virtually impossible to describe "the intended PC setup", a far cry from the consoles. I know you could apply the same logic to using macros to automate tasks... PC running is one big gray area as someone wise recently put it. Better to have some principles though, instead of falling into the kind of anarchy you might sometimes see on Speedrun.com.

BTW: Another technique that's been allowed is Windows Mouse Keys, which is just a way to convert the keypad into a mouse cursor, with the side effect of making the cursor move in set increments, meaning repetitive tasks sometimes become a lot faster. This was used with at least Elipsis' run for Where's an Egg. Another compatibility feature we've allowed is remapping the keys in any DOS game when running it in DOSBox, the way it's mostly done. It's compatibility because some keyboards have different layouts, or may not even work right at all without it (UK/US/EU...),

Sharp Keys: look at it this way. If some console had a hidden feature that allowed you to arbitrarily remap your controller keys, even if few people knew of it, doesn't mean it's not a perfectly legitimate thing you could do with your OS. The smart thing, in that case. Another way to look at it would be this: if there were keyboards that had some keys better-placed than most keyboards, would you rather make it a necessity for the runners to all go buy one, or just allow rebinding and be done with it? Is it really worth the hassle? Would you like to force every other runner to have to keep a whole second keyboard on their desks just to match what you're doing? Yet another way to look at it is, if I was to play some [PC] game competitively, would I not do the same since it's not exactly banned?

We can't have two sets of standards in verification, as I'm sure you understand. Even though it's a bit muddy, we have to adhere to certain policies because they're the only ones we can ultimately enforce. That's not to say that we haven't accepted countless runs that didn't use these kinds of advantages (the verifiers don't nearly always know the games that well), but it's difficult to justify, AFAICS, why it's a better run because of seeking this kind of "authenticity". You could even think about whether the devs themselves would see it important that you have used the binds they implemented that they might not even be happy with themselves. I know some of these arguments are quite subjective in nature, and can't really be taken too far, but perhaps so are the counter-arguments.

As for the hidden console: even though there are cases where some console commands are allowed in speedruns (mostly for cosmetics), because in this case the console is completely hidden, we'd rather not touch it until really put to it.
I want to force people to use 2 keyboards? My plan to use the second keyboard was for F12, which I said would be allowed for remapping because there are already so many ways to achieve the glitch anyway. My main reasoning for not liking registry hacks is that they render your keyboard unusable for normal typing and aren't conducive to having an experience you want to return to, but I suppose it would be just 2 keys mostly - Pause/Break and F12 - so not exactly the end of the world.

What I really don't understand, though is your fixation with banning the console. Why not let people cap the FPS to 60 just like VSync would in windowed mode? That way, no remapping would be needed. If using the console mid run is the problem, allow to do it before the run starts. I could argue capping the FPS is just as undetectable as remapping the controls because you could do it using software such as Dxtory and no one would know. Not to mention that, again, it's exactly what vsync does.
Edit history:
LotBlind: 2019-01-03 11:35:05 am
Okay, so let's make sure there's been no misunderstandings.

I re-read what you said, and I noticed that I'd mistakenly fallen under the impression remapping keys (or using that other keyboard) had solved the problem, in which case we had no incentives left to mess with the console, but there's still that first boss fight that you mentioned isn't there? So a slower PC in theory gets the advantage there, but might lose time elsewhere due to slower mashing or such. Then again if the FPS is capped, then a slower PC is at a small disadvantage possibly. I think most people's PCs can probably manage a steady 60 FPS on a game from the early 2000s though.

Looks like the mouse lag thing using Vsync is something that directly relates to the way it works, and is not a compatibility issue as such, or at least it's one that always existed. If the lag is just one frame, at least. Maybe it's more?

So I think you can safely use the console to set a framecap for now, because that could be done using a number of ways including by editing your graphics card settings, as far as I know, and as you pointed out. Not sure about changing it mid-run though, but apparently that's not really needed despite your original question? From a video quality point-of-view, 60 FPS is definitely high enough.
I really wouldn't want to say that there's a noticeable cutscene skipping speed at 50-60 FPS vs uncapped; I just know that at 5 FPS, if you try to twitch your arm and mash space rapidly, the game doesn't budge - no skipping happens; you then have to slowly tap spacebar one tap per second (more or less) for it to work.

The boss at the beginning: that would've been correct, but I've made a new discovery; you can use F12 to queue the needed inputs frame perfectly, and timing is no longer a factor like it used to be. Remapping F12 or using a second keyboard is needed to avoid some serious awkwardness. (You'd have to either lift the mouse, press F12 and then escape while holding the mouse or press escape with the mid section of your left arm. Three hands needed kind of thing basically.)
Now whether you want to allow to do this glitch using the 5 FPS thing is up to you; I know I won't be doing it that way, but it's the same argument as before - 2 keyboards + rebinding for new runners would be a frustration, etc. Either way, the outcome is the same and lowering FPS has no other application for the time being.

Also, before you conclude that this is perfect, and capping the FPS to what VSync would be on, even before the run starts, should be banned: I had a thing happen with uncapped FPS (go to 10m30s: - just to denote what specifically gave me trouble) where the glitch to skip the dialogue wouldn't work. Granted, it was just 2 instances where in one I couldn't do it after a dozen retries, and in the session after that, it worked for no apparent reason, but I still think not limiting the FPS adds an obnoxious randomness factor (something pathing related) that would give PCs with low specs an advantage. I will do runs with uncapped FPS in the future and report back if necessary, but I imagine the better the computer specs, the more of an issue this would become.
Yeah, what I meant was we'll definitely allow the pre-run framecapping here. I just wasn't sure whether changing frame caps in the middle of the run was cool or not. This doesn't crop up too much...

Hmm... you're saying "not limiting the FPS adds RNG related to pathing that works better for low-end computers" but a frame cap doesn't remedy that, it just makes it less important to have a powerful computer. Maybe you meant something else? Basically if there's a trick that's completely un-doable without lowering the setting to something like that 5 FPS then such tricks can probably be ruled out separately, but if it's more like you CAN sometimes do it at 60, but it's a little bit easier at 50, easier still at 40 etc. then it may become a necessity to allow live FPS cap changes so fast computers are on even grounds with slow/slowed-down ones.

For the record, we've allowed basically any FPS for games without a natural cap down to 30 (e.g. Max Payne is run at 30), but 60 seems like a good choice unless proven otherwise.

Good luck with your planning, testing etc. and yeah, just keep posting here.
Edit history:
Tionic: 2019-01-08 05:11:27 pm
It's more like something that is easy to do most of the time, but uncapped FPS makes it not work sometimes - I'd really have to have a semblance of understanding to describe it as something else than some nonsense that just happens. For now I just accept it as unexplained randomness and not RNG or any such thing; so if you asked me, I'd say having a PC that was bad enough not to go into too high FPS values would be an advantage. Although if you're saying capping was always allowed, then there's no point in continuing that argument, I suppose.
Also, do you allow some 3rd party software (like Dxtory) to cap the FPS with? Generally speaking, cause obviously VTMR's engine already lets you do it.

And thanks. Maybe I'll consider making a segmented thing with optimal RNG if I figure out a way to record from the autosave conveniently since the site seems to be more about a decent showcase of the run than what's possible under RTA rules.
I honestly don't know how it's been handled in the past (I'm relatively new here, and compatibility issues such as these are a recent development as well) but seeing as we can't enforce any other policies, we'll allow any which frame capping techniques for games with no natural caps.

Yeah, segmented runs are obviously accepted alongside RTA/IGT ones whenever games allow for it. It seems building on that other guy's run wouldn't be a bad idea. Wonder if he gave up.

What's the issue with recording from autosaves?
Eh, the routing in that run was too basic to build on. It also had too many mob encounters, so there would have been a ton of RNG to subtract while optimizings segs. Sometimes people just don't know how to address issues with routing, hence the waning interest which I think was the case for Blackout. Not to mention that being imprecise with the cursor is quite punishing, so optimizing the muscle memory is a grind as any other.

As for recording, the lossless codec I'm using places keyframes at around 5 second intervals, so I think I couldn't cut up the footage without introducing artifacts and such. Maybe if I figure out a comfy hotkey to start recording upon loading, but it doesn't sound too good for perfecting repetition.
You mean you couldn't just keep recording everything, then pause it after you've got a good segment attempt in to cut out the last part manually? Because of resolution changes or what? If it's something complicated, you could try posting under Tech Support. I don't know if I can be of help.
No issues with the resolution, no. I just wouldn't know how to handle raw recording files. I knew that the safest way to split encoded footage is to cut at the keyframes, but it's probably different for raw files.

No worries - I'll be sure to ask there if I get to it. I'd have to do some testing and pinpoint the exact problem first anyway.