Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
Unfortunately not on windows.
Error 3 error C2536: 'TASInputDlg::TASInputDlg::WiiButtons' : cannot specify explicit initializer for arrays (TASInputDlg.cpp 161 1 Dolphin
Ditto with the 5 others. Visual studio doesn't support that.
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
idk, some rerouting can be done to not have to go so far back at the cost of not saving as much time, but i'm not sure how much time would be wasted that way vs optimal route. Perhaps 30 seconds wasted, if we go back to the start of forest temple, but i'm not sure. Still saves a ton of time though..
If pheenoh ever comes back i guess we'll discuss it. Until then though, i don't really want to start over by myself.
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
We aren't at the end though. We're about 30 minutes in, with somewhere around 2 hours left to go. If we were 90% done, then it'd be easy to just ignore and just finish, but we aren't. More than 10% of what we've done can be cut out. That's huge. I could do a really quick and unoptimized tas and get back to where we are now in a week or less, and still be ahead by a couple minutes.
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
AngerFist wrote:
RachelB wrote:
I lost all motivation when a 3(?) minute time saver was found that would require us to basically start over.
I understand your position :( I don't want to sound too bossy but knowing you two are working on a big project like this run, you are more or less bound to suffer from late discoveries which requires you to start all over. Look at the old Mario 64 120star run, several tasers knew there has been a new discovery which would mean they'd have to redo from star X. But some of them reasoned it's better if they finished the run they had, knowing they had reached pretty far and work on another version in the future. So I strongly suggest that you finish your run, because thusfar, it's quite optimized and looks very good.
And how much time could they have saved? I bet it wasn't 3+ minutes.
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
hegyak wrote:
I have yet another odd question.
The L and R triggers have an analog value, and if that value is 255, the L and R buttons are pushed. What is the Minimum value required to make the L and R buttons trigger? Is it only 255?
Edit:
I can now read a single Gamecube Controller data for a selected frame. Now to setup up multiple controller reading. Writing will come after I verify reading.
Just 255 i think.
hegyak wrote:
Another question I have is the Change CD Marker.
What controller(s) get that value? What happens if all connected controllers say, "Change Disc"?
I think all connected controllers say Change Disc. Can anyone confirm this?
No, just the first one to be polled after the disk change is triggered. If all of them have the disk change bit set, then it will attempt to change the disk once for each controller. Which will be annoying if the disk cannot be found automatically because it could prompt the user to change disk multiple times.
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
hegyak wrote:
Found an issue with my program. Since it doesn't read the MD5 hash, it never writes it. This will be a problem for playback.
You should really read the entire header and write it back, including parts that are expected to be entirely 0, so nothing will be lost if anything is added to the header in the future.
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
hegyak wrote:
RachelB,
Thanks. I confirmed the merge was done right. The memory cards, the shared Wii/GC Controller status and the bongos behave. Now I need to calculate the values out.
My guess is that Vertical/Horizontal won't be a major factor for editing input as the player knows what's going on. The Nunchuck stuff, will be more interesting to parse out. I wish there was a way to say, "There be a nunchuk here." but 8X Controllers (4GC, 4Wii) = 255. It's maxed out already since it's using a single byte and changing that would break old DTM files horribly.
Coming Soon:
Version 1.3 release with full support for all kinds of stuff. Including GC and Wii Controllers in a single DTM.
Coming after 1.3 release:
Input data and editing.
The wiimote stuff should be done, and it's been on my TODO for an incredibly long time, but i haven't gotten around to it, and it's not exactly high priority, since wiimotes still don't even always sync i believe. Although they sync pretty well now, so maybe it should be higher priority. You can simply parse the input data to figure it out though, for your dtm editor.
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
Honestly, i doubt anyone encountered these problems before. it only occured if you started recording, then stopped, then started again, but with fewer bongos/memory cards than the previous time. I doubt too many people have ever done that.
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
hegyak wrote:
RachelB wrote:
I'm not sure what you mean. Nothing about wiimotes is saved to the dtm, except which ones are connected.
What's strange is the NSMB Wii DTM from CoolKirby has the Wiimote data of 0x16. The game expects you to have Wiimote Horizontal (sideways) to play.
My Vertical Wiimote DTM has the data of 0x25.
The problem is, when I make a new recording with the Wiimote set to to Horizontal, my value comes out as 0x25 again. Will this be a problem if I attempt to playback the DTM?
The other issue is the Extension. Is that noted/recorded in the DTM as well? Some games require an extension like the Nuncuk or the Classic Controller. Some games do not WANT any extension attached.
Sample games that require an extension:
Mad World
Pop 'N Music
Sample game that do not want any extension:
Wii Sports (any mini game except boxing)
Sample game that can use, but does not demand a Nunchuk:
Bust-A-Move Bash!
Also, I would like to know what version of Dolphin fixed the Bongo and Memory card issues. Or are the not merged in yet?
horizontal/vertical setting is NOT recorded.
16 = 1 wiimote, no gc pads. 25 = 1 wiimote, and a gc controllers in port 1, and 4.
Again, NOTHING about wiimotes are saved to the dtm except which ones are connected.
Also, I would like to know what version of Dolphin fixed the Bongo and Memory card issues. Or are the not merged in yet?
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
RachelB wrote:
Found the bug with memory cards. It happens if you start recording, then stop, then disconnect a memory card, then start recording again. I'll get that fixed.
This+bongos is fixed now, thanks for reporting it.
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
Found the bug with memory cards. It happens if you start recording, then stop, then disconnect a memory card, then start recording again. I'll get that fixed.
Seems to be same thing with bongos.
For wiimotes, check http://wiibrew.org/wiki/Wiimote
I also need to determine how a mixture of WiiMote and Gamecube controllers is written and handle that as well.
It's written to the dtm in the order they are polled. Both are polled at regular intervals (1/60 sec for gc, and 1/200 for wiimote), so it shouldn't be much trouble.
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
It's a bitfield as well.
For memory card A the first bit is set, ie 0000 0001
For memory card B the second bit is set, ie 000 0010
For both, both bits are set, ie 0000 0011
It's same as controllers.
Really i recommend just reading it directly into the DTMHeader struct, and then you don't have to worry about any of this. Parsing it bit by bit is silly when you can do the entire file at once.
Do the Non-Bongo Controllers have anything special? I don't see anything about that.
Only gamecube controllers, bongos, and wiimotes are supported.
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
Number of controllers is not actually the number of controllers, it is a bitfield, generated as such:
for (int i = 0; i < 4; i++)
{
if (SConfig::GetInstance().m_SIDevice[i] == SIDEVICE_GC_CONTROLLER || SConfig::GetInstance().m_SIDevice[i] == SIDEVICE_GC_TARUKONGA)
controllers |= (1 << i);
if (g_wiimote_sources[i] != WIIMOTE_SRC_NONE)
controllers |= (1 << (i + 4));
}
Same with bongos.
Also, can you not simply include the struct from https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/Movie.h#L60 and then just read the dtm file into that struct? Not sure if c# has a convenient way to do that, since i know nothing about it, but it will pretty much just make everything work automatically, including keeping unknown values (so it doesn't totally break if the format is updated). In c++ reading the file is as simple as
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
jlun2 wrote:
RachelB wrote:
(posting in English because i'm tired and don't feel like thinking right now)
We can't merge natt's a/v sync hack because there are a few problems with it, and it's not very clean code. Someone is planning to rewrite the video dumping feature from scratch, but it's going to take a while. In the mean time, we unfortunately, just have to keep doing what we have been.
I know this is kinda late, but is there an issue report on this so I can follow the progress?
