Forums  /  Return to Castle Wolfenstein  /  The future of RTCW runs: Opinion Thread
  ModMauZZR
Hello all,

There are a few decisions to be made regarding the rules for this game going forward, so I'm making this thread for runners who intend to continue running the game to share their thoughts. Please weigh in on as many of the following issues as you can.

***ISSUE 1: Save/Load glitch***
The following video was brought to my attention:

Basically, if you save your game and name it some (positive) integer, then load that save, the actual loading is delayed by the same number of seconds as you named your save (for example, the name "35" in the video means 35 seconds of delay before the save loads). The AI stops running as long as you're in this deferred loading state, allowing you to move through the level and kill things without being detected or attacked.

The question: Should this be allowed? Does it warrant a new category?

***ISSUE 2: Player movement cvars (com_maxfps, pmove_fixed)***
Anyone familiar with the q3 engine will know that these cvars affect jump height and distance.

The question: Should we allow these to be changed (e.g. com_maxfps [125 or 333], pmove_fixed 1), or run with the defaults (com_maxfps 85, pmove_fixed 0)?

***ISSUE 3: Game version***
Currently, the preferred game version for running is 1.00 (or 1.0.0 as it prints in the console) since the Heinrich skip was patched out. The steam version of the game is 1.32, and there have since been unofficial patches including the 1.42c version of the game, as well as iortcw, which is an open-source version in the same vein as ioquake3 which adds various enhancements to the engine.

The question: Should we enforce game version in the rules? If so, which version?

Thanks in advance for helping out.

Cheers,
Mouse

EDIT: expanded save glitch explanation
 
  ModMauZZR
My thoughts:

ISSUE 1: This changes the dynamic of the run pretty drastically. As such, I reckon this should get a glitched category or something. Then again, eliminating forest as an annoyance in the run can't be bad, can it?

ISSUE 2: If there's a significant majority in favor of changing these cvars, I'm fine with it. That said, it feels like a bit of an arbitrary change over the stock game. My gut tells me to run with stock values.

ISSUE 3: I don't feel strongly about this one either way. As it stands, 1.00 is at a rather significant advantage with the Heinrich skip, but it's not easy to get your hands on it (legally) unless you own an old copy of the game. As such, mandating a later version of the game would allow new runners to pick up the steam version and start on equal footing, which can only be a good thing.

Cheers.

EDIT: Misused "however"
 
  DraQu
ISSUE 1: Allowing this glitch would completely change the run and in my opinion, it would remove the essence of what makes the RtCW run special & fun. I would ban the use of the glitch from the main category and create a separate one if somebody wants to make a run utilizing it. I honestly wouldn't keep running the game if the glitch was allowed in the current Any% category.

ISSUE 2: I'm in favor of enforcing the use of stock cvars. This is how it is in games like Quake 1 & Quake 2 and how it should be in any game that has cvars that affect physics & shit. Also makes new runners less confused.

ISSUE 3: I think runners should be able to use whichever version of the game they want to, as long as they are aware of the potential advantages / disadvantages of said versions.
 
  Ewil
1) I'm also up for creating a separate category, or at least a variable.

2) Changing com_maxfps to 125 (which is the best value in Q3 engine) is used by several runs already, so I don't see a problem with that. Not sure if pmove_fixed would change anything in RtCW though.

3) As SDA knowledge base says, you should use whichever version is the fastest
 
  Exosum
1.) You can't use it for every map because it sometimes prevents triggers from triggering, and the route remains more or less the same cause you still need to accomplish all objectives to exit the level. It isn't extremely game-breaking but you don't have to worry about HP in few levels where it can be used. (I didn't test it in every level.) I remember that it can't be used in crypt2, first part of escape2 and baseout for example. Also, using save/load is sometimes slower because it can freeze enemies in doors and tight parts of the map / they can't run towards you (which is problem in first part of escape2).

2.) I am up for both.

3.) Most games use newest, official version available, also 1.00 save/load mostly crashed the game (like, 70% of the time. :D) for me which isn't very nice. So I would prefer 1.32 (steam official) or unofficial ones.
 
  ModMauZZR
Alright, given the input so far, I propose the following:

ISSUE 1 PROPOSAL: A new category will be made to allow for this glitch.

ISSUE 2 PROPOSAL: The use of stock player movement cvars will be added to the rules.

ISSUE 3 PROPOSAL: All game versions will be allowed, and a variable will be added to indicate which version of the game was used in a run.

EDIT: Feedback on these changes would be appreciated.
 
  ModMauZZR
Update:

I've gone ahead and implemented the proposed changes above after soliciting feedback from a couple of runners. These seem to be reasonable compromises for everybody.

Happy running!
 
  Ewil
Just wondering, since the rules say you have to use com_maxfps 85, how come runs show 90?
 
  ModMauZZR
That's a quirk of the id Tech 3 engine. If you set com_maxfps to some value that isn't an integer division of 1000 (e.g. 100, 125, etc.), the engine will cap fps at the next highest integer division of 1000. So in this case:

com_maxfps = 85
1000 / 11 ~= 90.90909090909091

Thus cg_drawfps indicates a framerate of 90.

EDIT: removed a gross generalization
EDIT2: improved explanation