Closed XyLe-GBP closed 1 year ago
Hi! Thanks for testing with your game!
Could you upload the log without these changes of your machine booting to the main menu, and then trying all of the test mode functions?
What is the baud rate, does it need a parity bit, etc. Also do you know what card reader is meant to be used for this game? S31 (LR compatible)?
No problem. Attached is a log file of my test mode attempts. Idolmaster uses the same CRP-1231LR-10NAB as Wangan Midnight Tune 1, 2 or Mario Kart. S31 and 1231BR will not work. The baud rate is 9600, no parity bits are used.
The game uses two cards, called producer cards and unit cards, and cannot function without the ability to swap cards in the middle of the game.
Thanks for the baud info.
With the log, can you build the program in debug mode so I can see the actual data being sent?
I want to try and avoid special game handing if possible. Does the game eject the first card and then the player is required to insert the second, or does it "eat" the first one then you put the 2nd. If it ejects, you should be able to insert the 2nd already via the UI, just change the card then insert.
Understood. I will build the program in debug and let you know the result. Idolmaster ejects the first card and then inserts the second card, but the first play is special: the first card is ejected during game play, and then the second card is ejected after data is written to the first card at the end of game play. With the unmodified stock program, the data of the second card is overwritten on the first card during the first play, making it impossible to break through the first play. As you say, changing the card from the webUI before it is overwritten can solve this problem, but for me it is inconvenient and I would like to automate it if possible.
Could this be automated externally using the Web API?
It may be possible to automate it externally, but we have not tried it at this time. Although not external, we have modified CardIo.cpp and CardIo.h ourselves and have been able to automate the process.
With the unmodified stock program, the data of the second card is overwritten on the first card during the first play, making it impossible to break through the first play.
Ah, okay so it's a smallish bug. What's likely happening is...
abc.bin
abc.bin
which already has the data of the 1st card storedI thought about this happening before. An easy fix would be just to append a number on the cardName
if the file already exists programmatically. Some annoyances that may come from that, are when the card goes to renew, although, some games actually allow you to use the discarded cards and this would facilitate that functionality.
We can confirm this once I get the logs. Don't feel the need to document what action you're doing in the log, the debug trace log will be massive, just give a estimate of where you think it breaks.
Switching cards worked when I changed the program that way (using conditional branches, etc.). I believe the program is working properly. In the meantime, here is the debug log
CLEANING, READ/WRITE TEST, CARD DISPENSER TEST, PRINT TEST, CHECK CARD DATA, and all major operations were fine. However, the test passes, but if the first card is not copied in Explorer after the first card is generated, the game will not be able to read the card and hang as it is because the second card data is overwritten directly on the first card.
To replace the card in the stock program, it is necessary to copy the first card data in Explorer before it is overwritten, rewrite the name of the card, and Insert the first card by name in WebIO after the second card data has been written and the game has ejected the second card.
I tried specifying a card with the appropriate number appended to the original card name in WebIO at the time of this action, but that does not work.
Thanks for that, I just like having logs to verify functionality -- and to eventually write test cases if I get bored enough.
Could you explain the additional command, the log you provided doesn't contain it.
In the mean time I'm trying to think of a portable way to do what you need, like I said, I'd like to avoid specific patches for games as the program should be generic/close enough to the real thing.
I'm certain what's happening based on what you've said, but I'm not sure how to implement it cleanly without causing issues for normal game play on other games. We could something like a recentlyEjected
flag, but then that would be an issue if you wanted exit the game then bought a new card. Perhaps we could require users to manually eject the card, and only then do we write out the track data, and if we get a new eject without manually inserting (machine dispensed a card) we know to make a new card. But then most people who use this want little interaction as possible... (party because my UI is bad)
I'm not sure. Let me get your thoughts.
I am sorry to be truly selfish, but if it is possible, I would like you to improve the program so that it can run Idolmaster. If it is not possible, I will close this request... The code I added this time, but since I added my own key to the [config] section of the ini file, the code I added should not run unless you change the [emulateIdolmaster] key to true, so it should not affect the operation of the other games. If you want to emulate Idolmaster, simply change the [emulateIdolmaster] key in the ini file from false to true. For games other than Idolmaster, set it to false. From my testing, even with this modification, the operation of playing with a new card after exiting the game works fine. The basic idea is not to mess with the stock YACardEmu code. It is just a form of inheriting the stock code and changing the behavior with flags. If the flags are not activated, the behavior is the same as the stock YACardEmu.
I would like you to improve the program so that it can run Idolmaster.
This is something that I want as well. I just don't wish to do with the way you've done here. Your solution involves a method that only targets 1 specific game which we're trying to avoid. The application should be generalized enough to support everything. What I've been trying to push you towards in this PR is to move to a more generalized solution.
I've taken it upon myself to create a fix for this using what I think is the best solution.
Please checkout this branch.
The game will no-longer overwrite cards if you haven't inserted one (which is what the actual bug is), and if the file exists then it will append a number to the end of the file, so it should be possible to play this game now. Please note that if you have any data already you wish to save, you'll need to create a single file with all 3 tracks contained within as the program will no longer use the .track_x
system.
Please test and let me know if this fix works for you. 🙂
Okay, I see what you are saying. It is true that my code was a forced approach, and I was focused on moving one game at a time. I apologize for that. I am very sorry, but I sent this request in a bad way, thinking that maybe you could respond to make this game work, and as a result, you agreed to do so. At any rate, thank you for fixing the program. I just got home from work today and tried it out and this branch works fine. Switching cards also works fine if I change the number from the WebUI, Change and then press Insert. I was able to get through the first game play without any problems. What I wanted to do was to use two cards and automate the card switching without using Change and Insert, so I decided to use the flag format. Idolmaster is more convenient that way. However, I don't think this change is desired, so I will close this request once the conversation is over anyway. The master branch can work with some ingenuity, but it requires the use of Explorer, which is much more comfortable thanks to this change. I appreciate it very much. Thank you very much.
I've merged the branch functionality to master which should satisfy your requirements, and now advertise compatibility with THE iDOLM@STER.
In terms of automation to change cards, I'd suggest looking at the small API provided by the webserver. You'll be able to tell when a card is inserted, when it's not, to change the card, etc. A small script could interact with this. Eventually I'd like to have it have more direct access over the CardIo class but that's for another day.
Thank you again for testing, and thank you for your work. :)
Thank you for creating this wonderful application. I had a problem with Idolmaster card switching, so I changed the code. After the change, this works fine. I have confirmed it works on my system256.