Experienced Forum User, Published Author, Player
(131)
Joined: 5/21/2012
Posts: 74
Location: Cary, NC
feos wrote:
EDIT: Since it is a community issue, not a legal one, applying some random lisence is cool, but it's not how we GET this working.
We just must set a community rule added here that if you actually redo someone's input, adjusting it, you own it completely, if you directly copypaste segments, both authors own it and must be credited.
That's actually exactly what the CC BY license that everyone agrees to says: Derivative works are allowed, all derivatives must be properly attributed. It's also irrevocable, meaning that the freedom to create derivatives exists forever even if the author changes their mind.
If you want to get legally picky about this, copying ANY input from the original requires attribution under CC BY, and fair use would probably not apply when the result is a competing work.
As for recreating input for speed optimization: Game strategies are not copyrightable, authors have no claim to any strategy or route used to complete game objectives. They might have a claim to things that are done for entertainment.
Experienced Forum User, Published Author, Player
(131)
Joined: 5/21/2012
Posts: 74
Location: Cary, NC
I don't think the problem is so much that it contains nudity as that it's a blatant shock title, and I think it'd make more sense to aim any sort of rule change at either shock titles or unlicensed titles in general (similar to the existing policy on hacks).
Experienced Forum User, Published Author, Player
(131)
Joined: 5/21/2012
Posts: 74
Location: Cary, NC
IVIrdemonic wrote:
is there any multi tracking lua for gens
I made this script for my 2P Gain Ground run, which may be useful:
http://tasvideos.org/userfiles/info/3644248980008336
It's a bit specialized for Gain Ground and lacks the ability to hold down a non-directional button or hold buttons for opposing directions, but otherwise is a pretty generic input tracker.
It made a number of things easier (i.e. I could try multiple approaches by just commenting out segments and uncomment them if they turned out to be faster, it was a LOT easier than trying to use input hold-downs), but whether it's better than GUI tools is up to you.
Experienced Forum User, Published Author, Player
(131)
Joined: 5/21/2012
Posts: 74
Location: Cary, NC
This was actually made against the correct ROM, just an older emulator version. That's not really a showstopper by itself.
Consider using GoodGBA if you have doubts about whether you're using the correct ROM.
Experienced Forum User, Published Author, Player
(131)
Joined: 5/21/2012
Posts: 74
Location: Cary, NC
Looks like it syncs with svn232, but I don't have time to watch it all right now to find out. Desyncs on the first screen with svn461.
I'll throw a quick encode up tomorrow if someone else doesn't beat me to it.
Experienced Forum User, Published Author, Player
(131)
Joined: 5/21/2012
Posts: 74
Location: Cary, NC
This is a good start! Looks pretty tight so far.
You might want to try playing around with the movement mechanics and find out exactly how certain mechanics affect your movement, especially the character switch. From a quick test, it looks like switching characters in mid-air after a double-jump causes your companion to launch forward much faster, which could be used to gain speed.
Experienced Forum User, Published Author, Player
(131)
Joined: 5/21/2012
Posts: 74
Location: Cary, NC
I'm having the same problem. Doesn't create the main window, process just crashes immediately. I built the latest SVN with C# Express and that actually works fine though.
I can't find 1.2, but I'll try it if someone has a link.
Here's my r4201 build if you want to try: https://www.dropbox.com/s/04p29aaxy6y2jmo/BizHawk%20SVN%20r4201.zip
Experienced Forum User, Published Author, Player
(131)
Joined: 5/21/2012
Posts: 74
Location: Cary, NC
Uploaded a new version to fix the probable cause of the desync issue:
http://code.google.com/p/qtas/downloads/detail?name=glq-rr-v121210a.zip
Server actions that normally execute before the client gains control (4 frames) are now properly executed when rr_framelimit is zero, and time-based RNG advances will no longer desync if frame stop is disabled by a console command.
kyoon = 11+25+15+15+14 = 80
banned = 2+1+14+14+5+4 = 40
banning kyoon is only half of what must happen
always = 1+12+23+1+25+19 = 81
the next step for kyoon is to be always banned
Experienced Forum User, Published Author, Player
(131)
Joined: 5/21/2012
Posts: 74
Location: Cary, NC
jimsfriend wrote:
so if we suppose this would work on console verification, would the game cartridge be irreparably damaged or does it fix at reset?
The system hardware isn't physically capable of changing the ROM data. I'm really surprised this hack works at all, I would have thought these systems would restrict execution to addresses mapped to ROM data.
Experienced Forum User, Published Author, Player
(131)
Joined: 5/21/2012
Posts: 74
Location: Cary, NC
OK, I can't get a good encode out of this right now because it desyncs with the good ROM around frame 16000 (in the Amy/NiGHTS stage). I'll try again when an edited version is submitted.
I think there may be several versions of this too, so a CRC or MD5 of the ROM you used would be helpful.
Experienced Forum User, Published Author, Player
(131)
Joined: 5/21/2012
Posts: 74
Location: Cary, NC
This was made using a hacked ROM and loses 125 frames at the start to skip the hack intro. It looks like it syncs with the good ROM, but IMO you should edit out the first 125 frames and resubmit.
I'll have a quick encode for a good ROM using what I have semi soon.
Experienced Forum User, Published Author, Player
(131)
Joined: 5/21/2012
Posts: 74
Location: Cary, NC
SXL wrote:
TAS Quake ? Human records are already very high, games have been done to death.
How do you intend to (help) make a TAS more entertaining ? Is it even worth the effort ?
There are runs on the site barely faster than the current human record (i.e. SMB), but even barring that, there are plenty of things which could probably be optimized by better movement and shot timing, especially since both are very dependent on timed-fuse explosive boosts.
FWIW, I don't plan on making any runs with this. I know next to nothing about speedrunning Quake, I just know a lot about the engine internals, but I've seen people wishing something like this existed, so I'll make it exist.
abyrvalg wrote:
The only drawback would be non-smooth mouse movements in frame advance demos which could hinder (or just completely destroy) entertainment for casual players.
I'm considering adding playback smoothing to mitigate that if it becomes a problem, viewpoint memo is definitely happening.
except for explosions, which werent visually completely erased after loading a savestate.
Yeah this is kind of expected. Fixing effects that go away on their own is kind of low-priority, but if you run into anything that doesn't go away (i.e. I think door noises are sticky right now), I'll see what I can do.
Also rr_recordinput cvar does not exist?
Fixed the docs, that cvar doesn't exist (use rr_record).
p.s. Is it possible to include a speedometer? Like the one that is used in half-life runs.
Frame counters and other important figures in the HUD are on the short-term todo.
Also, qgl-rr should work with Quake server mods (i.e. new progs.dat), and they should stay synced unless the mod makes unexpected RNG calls.
Experienced Forum User, Published Author, Player
(131)
Joined: 5/21/2012
Posts: 74
Location: Cary, NC
Google Code page:
http://code.google.com/p/qtasI've uploaded an alpha build to the Downloads tab!
See http://code.google.com/p/qtas/wiki/ConsoleCommandsAndCvars for a list of console commands and cvars you can use. Note that you need to actually be in a game for the vast majority of them to work.
If you need to launch it in windowed mode, use the -width -height and -window command line parameters. i.e.:
glq-rr.exe -width 640 -height 480 -window
If you want mouselook permanently enabled, you should create a file named autoexec.cfg in id1 with the text:
+mlook
Known issues:
- Pause does not sync. Pausing from menu and console has been intentionally disabled. It's my intention that pause will be re-enabled in later builds because it can be used to manipulate the RNG, but there are problems with getting it to display correctly.
- View will drift if playing back an input file with mouselook disabled.
Experienced Forum User, Published Author, Player
(131)
Joined: 5/21/2012
Posts: 74
Location: Cary, NC
Sorry if this belongs in Windows Games, I figured it'd be more relevant here since this is about engine modding rather than TASing the actual game...
Short version is, I'm going to be working on glq-rr and q2-rr, which will be rerecording versions of GLQuake and Quake 2.
After some discussion, these are going to be based on as unmodified as possible source bases for maximum authenticity, but with some input timing tweaks to improve consistency.
For Quake 1, authentic behavior is 10-72 FPS depending on how fast the game can get input. However, because Quake 1 uses non-incremental timestamps that are almost always 10 FPS aligned, running at 72 FPS causes animation-bound actions to act 10% slower than intended. Because of this, frame time will be set to 1873 / 2^14 seconds, which is just enough slower than 70 FPS to prevent frame slippage for 80 seconds, a.k.a. the slowest level in QdQwav.
Quake 2's maximum client FPS is configurable, but the default range is 20-83.333 due to the rate limiter being msec based. I'm going to change that to 100 so msec times are consistently 10, also aligning with the server's fixed 10 FPS rate.
The input will allow anything that can be legally sent to a server, which includes effects from manipulating the move speed cvars. Console commands will be allowed in Q2 as long as they are commands that transmit to the server to prevent malicious use.
glq-rr will work with Quake-compatible mods, but q2-rr will not.