This could have been a total disaster for one simple reason. The PU stuff so often causes crash on console. That the team avoided abusing emulator to ignore such crashes was a brilliant decision. Well done on getting the TAS verified on console! Some day I hope the OoT community will follow the great example you guys have set with this TAS. As I have observed the trend in OoT speedrunning, I must admit I was skeptical when you, the authors were so secretive about this TAS in the Super Mario 64 Thread on the forum here. I feared it would be because the run would not play on console. I am happy to be proven wrong. Congratulations on this great run! MOAT DOOR HYPE!
Can you link a specific OoT TAS you'd expect to crash? I want to see if it crashes for the same reason as the SM64 crashes, now that they can be detected without a console.
Route ≠ optimization. Did Tyler make the final optimized one? I was talking about that. Edit: Also I still think snark found the final route. Tyler found the initial improvement, then snark improved upon it a little further IIRC.
Tyler found it, and optimized it to its current state. Maybe you wouldn't hate the 'west' so much if you actually gave them credit for anything.
ALAKTORN wrote:
What improvement do you mean?
The BitFS PU route.
ALAKTORN wrote:
The m64 to what?
You're the one who brought up that they are using the Japanese input with what you consider a unfair deal suggesting they didn't agree to it. As sonicpacker said above "due to us requesting their B2 fight input".
I think snark got to the finalized version first, but I’m not sure. I get the feeling you’re considering snark as part of the “0 star team”, but the teams here are Japan vs. the west, not “0 star” vs. whoever imaginary else.
No Tyler Kehne found the current route. It is comical that you think I'm the one who is confused about the teams, but I digress.
ALAKTORN wrote:
This is just wrong. The Japanese are still working on 120 Stars and never wanted to submit a run in the first place because it wasn’t optimized. The western community forced a run out of their ass in 2012 to get something published. Japan strives for perfection.
Huge difference here. The Japanese didn't want to release a run with a known improvement. The 0 star doesn't necessarily have known improvements rather things that still need to be tested.
Remember these are the same people who took the BitFS improvement that they didn't find, wasn't optimal, and release in their own 0 star video 13 days later.
ALAKTORN wrote:
What arrangement? There isn’t any. Why do you think the SM64 Japanese TASing community hates us?
Really? How do you think they got the m64? It wasn't submitted to tasvideos, it isn't linked to on the video.
…What the hell are you saying? Literally every single statement in this post is wrong. How do you have so much misinformation all at once? Amazing.
Never forget that packer is gonna upload the TAS to his channel and not share a penny with the Japanese TASers, again, btw.
Please humor me then, and explain where I am wrong.
The BitFS improvement was originally upload on July 13, 2015 by MKDasher, and later that day tied by Snark. It took until March 3, 2016 to get the the current state. So only 7.5 months, but both the discovery and ultimately optimization were done by the current 0 star team. If the Japanese are so amazing wouldn't they have optimized it during this time?
Tfw the Japanese TASers would’ve submitted the TAS months ago if packer and friends collaborated with them.
What makes you think that? The BitFS improvement was publically released, and it took 8 months to get to the current version. On top of that the current best run was produced by the 0 star team. None of which suggests to me that the Japanese would have released an optimized 0 star TAS faster.
The only reason to believe the Japanese would have released already. Is because the Japanese tend to release far more incremental improvements rather than trying to get everything perfect the first time.
Clicking wiimote on OSX crashes dolphin in your revision, but doesn't in the newest rev from dolphin-emu.org. Don't know if this is something that you/i caused, or if master was broke when you forked it.
http://pastebin.com/ZsCtQw5F
Hello.
I am about ready to give up on IR though, it is far more complicated :/
Now you figured out why I didn't even put anything in the UI to control IR. While inconvenient to have to put your mouse back if you move it, it is already accurate.
At least I think it is, never actually tested come to think of it.
EDIT:
And why on earth don't the crosshairs show up on windows?
I'm not too familiar with c in general much less the ins and outs of visual studios. Nor do I have a windows computer available to play around with it on.
So the only suggestion I have is the obvious albeit line consuming idea of initializing them in the construction as WiiButtons[0] = ... etc. But with the halfway added wii support the code is still 500 lines shorter than the current implementation. So I cannot imagine anyone complaining about the extra lines.
However I am sure there is probably a better way to initiate it. I just don't know it.
The .h and .cpp were based on different revisions lol.
This will be fun.
Not quite sure how I managed to do that, but below is an explanation of how to get it compiling if you haven't already, and what I think is left to do for the wii.
To get the GC Input working/compiling again all that needs to be changed is
1. the includes statements at the top.
2. change SPADStatus to GCPadStatus,
3. and on line 674 of FrameTools.cpp add g_TASInputDlg->CreateGCLayout();
As far as the the wii input (IIRC) wm_core and wm_accel just need to be passed in and set to the values from the wii tas input.
Oh, and of course you have to make the wii input actually pop up.
Here is a link with the two main files TASInputDlg.cpp/.h http://www.mediafire.com/download/852ac6dw1ar7u6t/Archive_2.zip
For what ever reason it is no longer considered a git repository so I cannot create a patch. There are very few changes outside of these files though, but it doesn't currently compile due to all the changes in dolphin in the past year.
Its not only begins implementing wii support, but also completely redid a lot of the code for the GC input. So the wii and GC could share the code. So when the code does get finished and committed GC input will need to be tested as well.
Who says its not done? Just messing with you. This pictures is from over a year ago, back when I didn't have a job or college to worry about. It was still too buggy to release when I stopped working on it.
Plus at the time wii TASing wasn't stable enough to bother finishing it anyways.
I have now implemented this on my clone http://code.google.com/r/bradenb95-tas/source/list?name=TAS-Input , i will update this post with builds later tonight and will move the changes to the offical dolphin TAS-Input branch sometime.
Edit:Sorry i will not actually be able to provide builds for a while, I had kind of forgotten that i an now on a Mac, which cannot make windows builds.
Input display is already built in, and bzb implemented rapidfire with the TAS input yesterday. He just hasn't released it to the public.
I am curious why he isn't part of team Dolphin. Instead of working by himself, he should officially join them.
Yes, he should get on Dolphin's IRC channel and show his patches so far and ask for commit access. At least when I joined, there were fairly lenient on giving people commit privileges.
Can you please explain to me how to make a patch on git? Because for me "create serial patch" does nothing.
antd wrote:
It seems that way. Still, something was fixed, so maybe it'll be easier to get it working fully now. Or even just working around it by running the different .dtm after loading the previous savestate would work as a temporary solution.
Its extremely easy to fix if i am correct. He just needs to not load the number of frames from the savestate and keep the ones that have already been loaded from the .dtm, but now that dolphin has switched to the new versioning system i am to lazy to try coding anything on it.
Hex editing the frame count in the first .dtm, save stating then recording more doesn't work. It still stops where the original did (where it ran out of input, it ignored the inflated frame count).
It should... Its getting the frame count from the savestate not the dtm(I think). It needs to be getting it from the dtm.
It seems that way. Still, something was fixed, so maybe it'll be easier to get it working fully now. Or even just working around it by running the different .dtm after loading the previous savestate would work as a temporary solution.
Its extremely easy to fix if i am correct. He just needs to not load the number of frames from the savestate and keep the ones that have already been loaded from the .dtm, but now that dolphin has switched to the new versioning system i am to lazy to try coding anything on it.
I'm not looking at the source code right now but i'm pretty sure the issue is he is writing the number of frames to the .sav file . So then when you use that savestate it is getting the number of frames there were in the .dtm at the time of making the save and ending the playback based on that.
I can work on this. Didn't know about this issue because somebody else implemented the read only option.
What should the exact behavior be when a savestate is made/loaded in read-only mode?
Basicly in the LoadInput function of movie.cpp it needs a if/else statement to set the mode to movie_Playing if g_bReadOnly is checked but then you also need to make it continue reading input from the input frame on the dtm...which is where i am stumped so i hope you have better luck then me. Which you probably will.
I have a question what if this run was submitted before the other 0 star? It would have been accepted correct? I highly doubt if this run had came first that anybody would be arguing to replace a quicker run with a slower one because the camera angles are(supposedly) better.Then nobody who has actually tased sm64 is against this improvement, its retarded for a run to get rejected by idiots who have never played the game or are just to dumb to understand whats going on.
Ignorance is not idiocy or being dumb. Some people just don't care about SM64 to spend massive amounts of time learning how it works to watch a 5 minute superplay. I know I don't. Does that make me an idiot or dumb? If so, then you are too, because you don't know Somari inside and out.
Some people played it as a kid and are just amazed to see it broken so quickly.
Yes if i go and vote no on are Somari movie that i know nothing about i'm an idiot, but i'm not going to do that because i accept that i know nothing about Somari and should stay out of its voting process. You cannot vote in the United States till your 18 for a reason. They don't want you voting on stuff you don't understand, same should apply here. Don't vote against a movie because you don't understand whats going on. It pure ignorance to vote against something for no reason other than being too dumb, or lazy to understanding whats going on.
I have a question what if this run was submitted before the other 0 star? It would have been accepted correct? I highly doubt if this run had came first that anybody would be arguing to replace a quicker run with a slower one because the camera angles are(supposedly) better.Then nobody who has actually tased sm64 is against this improvement, its retarded for a run to get rejected by idiots who have never played the game or are just to dumb to understand whats going on.
The gamecube and wii controllers get polled more than once a frame. So even though we still advance a video frame at a time with frame advance your button press(in some cases) will actually get written to the dtm 3 times. Due to the controller actually getting polled more than once a frame.
Plus at the time wii TASing wasn't stable enough to bother finishing it anyways.