No, no, it's fine.
I'll throw in that I also believe waiting to let the hype die down would be a good reason to wait too. I thought I mentioned that, but I guess not. Whoops.
So like, we should probably have some sort of stupid imposed limit of how long a run has to be published before it gets a star right? Otherwise we could get stuff liek oh em gee~~! Best run ever you need to start it now garblehaaaar~~!!!! STAR!!![/color] like we used to, even on runs that didn't need a star. It just became a way of saying "this run is good."
I think the time limit thing would prevent the HYPE HYPE STAR IT NOW! reaction, or at least keep it unrelated to actual star discussion. Then after a while, when the initial "this is the coolest thing I have seen in the last 20 minutes" dies down, people will be able to think about it more reasonably. Was it really a superspecial run, or was it just a good run of game xyz which you really enjoyed, especially compared to dull activity yza that you were doing before you started watching the run?
I was going somewhere with this post. I'm not sure if I got there.
Xkeeper, many posts ago wrote:
In that case, I would like to bring up the idea of making movies starred only one month after their publication, so that other movies can enjoy whatever spot will be revoked while the run in question merrily sits on the "Newest movies" list.
(With one month being a random time frame)
I'm not really sure if I'm being mocked or agreed with.
Personally, I think multiple categories are great and should be encouraged, so I'm in favor of publishing this.
This is pretty much my opinion on publishing in general. I have never, ever, ever understood the whole stigma of THIS GAME HAS Y CATEGORIES WHEN IT SHOULD ONLY HAVE X REJECTED.
I mean, shit, it isn't like the fucking world's going to end if a game has (heaven forbid) more than one category.
Then again, my publishing guidelines would mostly fall to "Was it well-played? Yes/no" instead of some stupid combination of "Is this game popular? Is this game played well? Does this game have less than 2 categories? Has the author submitted any money to the site?" etc. That would allow for less well-known games instead of rejecting every game only 7 people know (heaven forbid we have a niche audience, oooh nooo).
As much as I seem to clash with Fabian, at least I can agree that the idea of restricting categories based on some arbitrary bullshit is a pretty fucking stupid idea.
Wow, aparrently setting memory.register completely breaks the emulation even though the Hex Editor already has that functionality outside of Lua via "write breakpoint".
And somehow, memory.register aparrently manages to fuck up everything related to registers or some garbage. Better hope you don't accidentally and unknowlingly change some somewhere!
Nevermind the fact this has been a part of FCEU XD since 2005:
But nope, let's create our own breakpoint function that completely fucks over the emulation if you happen to watch specific bytes, even when the original (still included!) debugger works fine.
Jesus christ.
I simply propose that memory.register works like this:
function somefunction(address, newvalue)
gui.text(1, 1, address .. " was changed to ".. newvalue);
end;
memory.register(0x2007, somefunction);
Which can actually provide new uses for things!
These would include
- Being able to use the same function for multiple addresses
- Being able to read values written to registers that are otherwise only readable with the debugger
- And more!
Instead of the current method, which as demonstrates has the amazing ability to completely blow up the emulation if you dare read something unexpected! GASP
I'm not reading/writing from the PPU or anywhere else, just setting a sort of breakpoint to count how many times it is done, as memory.register is relatively useless (now if it was called iwth the old/new value, then...)
For real fun, try memory.register(0x4000). It calls your function with every single memory write :D
Setting memory.register on some values will cause extreme problems. This one is 0x2007 (though most of the PPU ones will probably do it.)
A sample script that does this is http://xkeeper.shacknet.nu:5/emu/nes/lua/kaboom.lua. Don't use this if you have a risk of seizures, because, well.
I will definitely vote for denouncing a judge, who does this kind of stuff! The case is not obvious to me, though. Could you please tell me what was so special about this particular author that his run was rejected? (A list of behavioral characteristics will suffice.)
Just read the damn thread. There's so much bitching and whining between Saturn and others that it's mind-boggling, and this occured in the SM thread before too.
I think some pretty valid reasons were given, and Bablo just stated them again: Bablo wrote:
1) There is already a low% TAS published.
2) Doesn't use glitches, except it does?
3) I don't see a reason to make a fifth category for Super Metoid TASes.
Are there any good arguments against this? The glitch being boring is not really a good argument, as there are three other Super Metroid runs.
If the glitch is so boring, then why include it in the first place? The previous low% worked fine.
Edit: Xkeeper wrote:
I'm just going to come right out and suggest that this TAS's rejection is due to the author.
<irc quotes>
None of your quotes came from the person who actually rejected the movie...
The point here was the community at large. It isn't exactly a surprise that a lot of people here really don't like Saturn.
In that case, I would like to bring up the idea of making movies starred only one month after their publication, so that other movies can enjoy whatever spot will be revoked while the run in question merrily sits on the "Newest movies" list.
(With one month being a random time frame)
The difference between those movies is that one doesn't use the key combo L+R or U+D. That is a pretty non-subjective category, if you ask me.
Then up next: thesemovies.
There are other pairs.
Even then, what is the difference between how the glitch is done and what the glitch accomplishes? As it is, they both putz right though walls and skip a majority of the game by doing so.
The category is vague, is not the lowest% possible, and the criteria requires a subject decision as to what glitches can or cant' be used. In general, such categories are problematic and frowned up on this site.
Then I guess that the Zelda 2movies will want to have a talk with you. Any% without a certain glitch, Any% with (although it's more like low%). You know, heaven forbid we remove a glitch that takes an hour to perform but makes the game longer (oops, Murder Beam!)
Considering that the previous 14% run was left unimproved for 4 years
Stupid reasoning. Zelda 1 2nd quest didn't get a new run for almost 4.5 years (#8, the last published run, was posted 2004-05-13 while it's successor was posted 2008-10-16)
Nice to see somebody agrees with my thoughts too. I just didn't feel like posting them because of the point I'll explain last.
When compared to the three currently published "non-glitched" runs, this movie provides very little additional entertainment value for viewers who do not closely follow Super Metroid techniques and tricks.
While there is an interesting trick done in the 6% run, it's EXTREMELY BORING TO WATCH. Honestly, who wants to spend 10 minutes watching Samus turn left turn right, and slowly creep up while doing the X-Ray beam? Honestly, as a Super Metroid fan, I was disgusted with that. It was boring. 14% is better because it pushes a runner to the limits while still being entertaining to watch. It gives a real sense of completeness that the 6% fails to do. It's ENTERTAINING. Isn't that the purpose of this site?
I would be genuinely surprised if more than 3 people watched that segment without holding down the fastforward button. It's basically the SM64 problem all over again; a run that shows nothing removes all of the gameplay except a few small bits, leaving a run that actually shows part of the game to be forgotten and rejected if anybody actually tries to improve it.
I'm sorry, but I have to say this because while I may not agree with some things, the rejection reasoning is something I REALLY can't stand and feel I have to say something. All I can do is hope that this doesn't fall on deaf ears.
I'm just going to come right out and suggest that this TAS's rejection is due to the author.
*065402 <Tub> yay, extend the flame-wars to the submission-text!
*065847 <adelikat> yeah, OBVIOUS
*065853 <adelikat> why explain such things
*065910 <theenglishman> just ignore the cunt for once
*065915 <adelikat> and how could anyone think that skipping 90% of the game is not a true low%
*070728 <Stickie> hahahaha! FUCK YOU SATURN!
*070732 <Stickie> what a douche
*070738 <Stickie> thank god bossy rejected that
*071528 <theenglishman> mmbossman is my hero now :D
Not that I necessarily like Saturn (far from it, rest assured) but you really can't deny that there is probably tiny bit of bias. Hell, just look though this thread at all the Saturn hate.
Besides, what better way to put your anti-Saturn tastes into action by rejecting his movie?
Personally, I don't really care either way; I'm just throwing some things out there to consider.
Generally, if one star is added, that means another star has to be removed to avoid inflation. I'll mention some of this in the general guidelines.
I greatly despise the idea of "one movie gains, one movie loses".
It would be a better idea to just be a bit more strict with giving them out in the first place, although I hope that this doesn't turn into another "99% of starred movies are from the same X series" disaster.
I'm currently wondering if I should run a few playthoughts though my replay engine to create a movie.
You know, like this.
All I really would need is some playthoughts -- possibly up to 1-4?
The main problem would be keeping the players on screen, as SMB1 doesn't scroll at a very fast pace. Perhaps you should aim for fastest time too? :P
Gist of it:
Upload a FM2 of you playing 1-1 to 1-4 as fast as you can.
I've actually had a lot of random config errors, like the directories being reset to the defaults among other things. There seems to be no real cause for it other than by complete random.
The current interim of fceux will always return a framecount for movie.framecount(), even when no movie is playing. Like on screen, it will then return the number of frames since last reset. Needs a little testing, but I think it's ok. That should solve your problem as well.
Last reset? Eh... since last ROM load would be better, or at least last poweron, but thanks for the tip (much superior to nothing). I don't recall seeing that in the manual, though.
By the way, would you be interested in helping me out with this a bit? I could use somebody who has experience with iup to do an interface, and your help would be greatly appreciated.
http://www.youtube.com/watch?v=biaZSfjy_Vg
6 hours of mindless drooling later, this.
Lua can shove its table system UP. ITS. ASS. Yeah, I said it. Fuck you and your tables, Lua.
Maybe I can get alden (or was it qFox) to help me with a basic interface, and maybe get a way to get frame counts. As it is, the only way to sync it is to ... well, there isn't! Mostly just "pause, reset, record movie, load Lua, start playing" (due to how Lua hijacks the emulator's speed settings...)
Some screenshots without the debug output, showcasing klmz's first version (v1 marker) and his next one:
I dunno; in the specific example mentioned, I don't really see how that's different from using a save game in a game that doesn't save exact stats.
But it does still feel kinda weird.
That's basically how I saw it. No different from save, soft reset, load.
Telling where you are in a movie is not that hard: you just count how many frames have been executed so far.
Savestates can easily break that idea; if you rewind 10 frames, how will the script know that?
This is why I think there should be an easy-to-use "emu.frames" or "emu.playpos". Preferrably like VBA's, that stores both game and movie frames (i.e., starting recording mid-game = game 100, movie 1), that is savestate-persistant.
Another problem with this approach is that every other frame will display something from the other movie: Your loop has two frames, one per movie, per iteration, and this will lead to flickering. You can't fast forward past one of these, since there will be no graphics to capture in that case. I guess this could be worked around by not only adding the secondary movie's graphics to the primary one's, but also the other way around, but this would require two screenshot buffers, and would still lead to flickering in the form of things alternately being in front of and behind each other.
No, what you would do is store an external "replay" file that simply has frame# and a few relevant variables (camerapos, area, player location, animation frame). It would use the replay data instead of switching between two movies.
Still, it would be very nice if you could get this to work! Just because I gave up doesn't mean it's impossible.
If somebody could tell me how to get GD + Lua working in these emulators, I would consider it.
But nope, let's create our own breakpoint function that completely fucks over the emulation if you happen to watch specific bytes, even when the original (still included!) debugger works fine.
Jesus christ.
I simply propose that memory.register works like this:
These would include
- Being able to use the same function for multiple addresses
- Being able to read values written to registers that are otherwise only readable with the debugger
- And more!
Instead of the current method, which as demonstrates has the amazing ability to completely blow up the emulation if you dare read something unexpected! GASP
%20(PRG0)%20[!]-1.png)
%20(PRG0)%20[!]-40.png)
Setting memory.register on some values will cause extreme problems. This one is 0x2007 (though most of the PPU ones will probably do it.)
A sample script that does this is http://xkeeper.shacknet.nu:5/emu/nes/lua/kaboom.lua. Don't use this if you have a risk of seizures, because, well.%20(PRG0)%20[!]-25.png)
%20(PRG0)%20[!]-27.png)
%20(PRG0)%20[!]-29.png)
