20pacgal-pac

[kernzy]

game plays back to 155470 both with and without nvram.

[CrazyKongFan]

Yeah, I get the same score, but it only works for me with nvram. It gets stuck on the "factory settings restored" screen for awhile without nvram, then starts a ms pac game that ends quickly.

[Chad]

I get samething as CKF. 155470 with default nvram, but the game doesn't go out of sync at all, last life just dies legit at 7th key. I think it's a wrong upload. I'll label as such since three people can't pb it.

http://replay.marpirc.net/r/20pacgal-pac

[kernzy]

right! who's next!
(sorry nibbler!!)

[kernzy]

BARRY SAID "[claimed 171,110, DQed for using default NVRAM -br]"
I played this back and it went to the advertised score.
can someone please explain why it was disqualified? i don't understand.
cheers!

[mahlemiut]

Exactly what it says, played with default NVRAM. For me, it did not playback with no NVRAM present (inputs were recorded too early), with default NVRAM present, it played back fine.

[Chad]

BARRY SAID "[claimed 171,110, DQed for using default NVRAM -br]"
I played this back and it went to the advertised score.
can someone please explain why it was disqualified? i don't understand.
cheers!
8)

If this recording playsback for you then you are not playing back inps correctly. It's the rule here that you must remove nvram files (by removing the file or by making sure you null out the nvram directory or by using the null nvram option) before recording OR playingback anything. This helps keep inps from breaking in a random way, where if you record with an nvram file It may be next to impossible to attempt to play the inp you are making back again. Most of the time default nvram will playback these rule-breaking inps, but that is not a consolation from breaking the rule.

As Barry pointed out, I really should have dqued the 357010 recording because it only got far with a default nvram, it probably was recording with a non default nvram and thus why it can't be playe dback.

[kernzy]

thanks mate. that explains alot.
maybe wolfmame could be modded especially for MARP, so this never happens? maybe in future releases? that would solve issues and save a hell of a lot of time.
cheers chaps.

[mahlemiut]

Last time I tried that (somewhere just before 0.106) there were issues when MAME Plus started changing NVRAM functionality for their own uses.

I prefer to have WolfMAME operating as close as possible to MAME, makes it easier to keep up to date.

Easiest solution is to just open mame.ini, and set nvram_directory to NUL. (Or /dev/null for Linux/BSD/OS X users)

[Chad]

the best solution for users of marp and also make updates fairly trivial would be to to force a wolfmame to start with the nvram_directory being NUL. Assuming a live nvram folder at startup is a flaw of mame when -playback and -record are used. This should be null by default and only be an option for users who don't care that they are starting at a potentially random past nvram state.

[BeeJay]

Perhaps someone with inside access to the Mame Dev team could suggest that the default behaviour for Mame itself, when -playback or -record options are being used, is to behave the same as nvram_directory being set to NUL. Then, there could be a new option that forces nvram back on, even though -record and -playback are being used, for the very rare occasions when it may be necessary to have a default nvram for playback and recording to work?

Cheers,
BeeJay.

[mahlemiut]

Problem is, NUL is Windows-specific, I'm not adding anything that isn't cross-platform. That's why it's in record.bat and playback.bat instead.

[Chad]

if (fileexists("/dev/null"))
use /dev/null
else
use NUL: