Posts for msg555


Joined: 2/27/2017
Posts: 1
Hi all! I'm the author of Dustmod and let me see what light I can shed. First of all let me say that dustmod is created with the generosity of Hitbox Team who donated the source code to me to work on modding. In particular if it comes to releasing code or having it reviewed I'd need to have their permission as they hold the copyright and have asked me not to further distribute.
Also, how much does this tool alter the game? How can we be sure of its faithfulness?
While developing features for Dustmod it was always my intention to leave normal gameplay (no mods selected) unchanged. However, the code base has grown significantly and it's certainly possible there is a mistake (although we have evidence of it's faithfulness in our IL TASes that match on vanilla and dustmod when watched via in-game replays). If it's useful I could create a bare bones mod that just contains what's necessary for these TAS scripts. Despite trying to keep gameplay unchanged, I have patched the following things intentionally to achieve deterministic playback that have some affect on gameplay. 1) Camera shake (created by attacking, landing, etc...) randomly moved the camera minor distances. However the camera position is used to determine what entities should be loaded and simulating. Because of this, when certain entities were loaded in was slightly random. I patched this by only visually simulating the camera shake and leaving the camera unmoved for loading purposes. Such an execution is always consistent with a possible execution in the base game. This is an extremely minor bug that we got pretty far into TASing before finding it to be an issue. 2) The main game loop had to be fixed to be deal with time properly. The original build will feed the game loop the time delta since the last call to the game loop and the logic should forward the game state by that time delta. An unfortunate property of the way the game loop was implemented was that invoking the loop twice for 1ms would not necessarily give the same result as once for 2ms. This manifested itself as occasional input drops and fairly variable load times, sometimes even simulating the world an extra frame before you can move. I fixed this by making the game loop properly additive with respect to time. I also instrumented the vanilla build to find the average load-in and load-out times (in terms of frames) and made dustmod determistically match that. In particular the SYNCLOAD is not actually required for the nexus scripts anymore and could be replaced by blank inputs. It looks like BrotherMojo was mistaken about this aspect in his earlier comments; frame length of the video will be deterministic.
Finally, does the movie recording format for this even have a name?
I've just been calling them 'Nexus Scripts'. If we needed a name for tasvideos 'Dustforce Script' is probably appropriate.
Is this summary for TAS site parsing correct? LOAD - Cheating MOUSE - Ignore SYNCLOAD - Ignore All others - Count as frame?
Unfortunately with the SYNCLOAD command it's difficult to calculate frame counts. However as I mentioned above this command is not needed anymore and is purely convenience at this point. If we remove these commands then the length of the video (in frames) is the number of normal input frames.
There also needs to be a way to dump video. In video dumping mode, since the speed of the machine isn't really relevant, the question is what gets written to video during those segments, and the video dumping process can normalize it. Like all those segments are 3 seconds of blank or repeated frames. Whatever it is, that info should be present (calculable) from the movie format.
Can you point me to any resource on how other systems do this? I'm not certain what's involved here.