IlIIIIlllIlIl

Most lines seem to be fine within the file, I didn't have to do anything to the $fset lines at the start: 10200 ,"$fset %f_tamaki%,0",,,,,,,,,,,,,,,,珠希進行度＝０ The lines I had to change were ones like: 57500 ,,"<!se_24_knc_people00><shake id="0" target="sc" time="700,700" x="12,300,0" y="60,240,0">",,,,,,,,,,,,,,,どんっ！ I got the game to be fine with it after I changed that to: 57500 ,,"<!se_24_knc_people00><shake id=""0"" target=""sc"" time=""700,700"" x=""12,300,0"" y=""60,240,0"">",,,,,,,,,,,,,,,どんっ！ I didn't play through it to verify that the shake effect was still functioning, but I imagine it'd still work. The other thing I noticed was that any Japanese text in the file would be garbled when loading through the csv file, but that was easily fixed by saving the files as Shift-JIS instead of UTF-8.

Hmm, it looks like there's actually two issues going on here. The first I discovered that when trying to load the standard .bcs files in the datascn.tac folder and only including _variable.csv there would be a bunch of pop-ups complaining that it didn't find variables that were being referenced. Looking at the _variable.csv file, it's clear it was trying to define those variables, so I stepped through it with a debugger and it was actually treating the csv file like it was one giant line. So I passed the csv file through unix2dos to change the line endings from LF to CRLF and it stopped complaining and played fine. Once I started incorporating the rest of the CSV files the only ones that caused it to crash were: _define.csv, _stand.csv, 01common.csv, 02tamaki.csv, 03kyoka.csv, 04haruna.csv, and macro.csv. Back into the disassembler, I saw the same std::_Xout_of_range("invalid vector<T> subscript"); exception that you're getting. Specifically, it looks like it's erroring because it's not handling quotation marks correctly. In the function that raises the Xout_of_range exception, it runs through that function once first and parses it as you would expect for a csv file. So just below the Xout_of_range exception, you'll see a ton of comparisons to 0x22 (hexadecimal quote). I haven't stepped through that with the debugger yet, so I don't know where exactly in that function it's failing to parse. I think the easiest csv file to use to look into it is _stand.csv, since the only quotation marks are on line 29 in what appears to be a comment. Trying to start it with _stand.csv included will crash the program, but removing the two quotes from that line and starting it again will let it run fine. It's also worth noting that I was able to replace each quotation mark with two quotation marks to escape them, as expected from csv. That said, you can apply to other files as well, such as with 01common.csv:

Sorry for necroing this thread, but I've been looking into .bcs files this past week and figured I'd post what I've managed to discover about them so far here in hope that someone much smarter than me can help figure out this format. I've upload copies of .bcs files for Noshoujo, Hatsukoi, Shoukoujo, and Shoujo Ramune here: https://mega.nz/file/LF9GUCYD#UGUPyEzfDCmEGauyncCEiYwAi4t5OYhIViLfQc9pYAo The Hatsukoi folder also has the translated CSVs available. Some of the translated files aren't incredibly helpful (like route data), since they're translations and a converted BCS wouldn't output the same file, but ones like V.csv should end up being the same file. I've found that if it can't find datascn.tac then it tries to read in datascn.tac/_variable.csv and then datascn.tac/_variable.bcs. I was able to replicate that by removing the datascn.tac, confirming the game would no longer load, replacing it with a datascn.tac folder with the .bcs files inside, and confirming the game would once again load properly. Digging into it a bit more with Ghidra, There is definitely some sort of tabular structure inside the .bcs files. It seems to be looking for certain column headers based on the .bcs file it's loading. For example: _variable %name% %type% %default% _event %no% %label% %cg% %comment% %type% Like mentioned in the posts above, the files will either start the magic string TSV or BCS . Around the call to where it checks for that TSV magic string, strcmp(&v42, "TSV");, I see references to the vftable for TLibLZSS. Unfortunately I'm not nearly proficient enough at reverse engineering to work my way around the generated pseudocode to figure out what it's doing. I did notice that the first 24 bytes of the file appear to be the header. The first 4 being TSV\0, and then 5 more 4 byte integer fields, the last one likely being some sort of length property. The assumption that the .bcs files are using some sort of LZSS compression seems to be along the right track, I found an archived posts from the Hatsukoi translation team that mentions a variant of LZSS being used: https://warosu.org/jp/thread/3247959#p3259250 https://warosu.org/jp/thread/3247959#p3260079 Since the threads are so old by this point, a lot of the links and images are dead-ends, including what appears to be the holy grail in terms of a link to the source code of a BCS to CSV conversion program: https://warosu.org/jp/thread/3310174#p3325324 The source code for the LZSS variant, spiruneg, seems to be alive and well on GitHub. https://github.com/gocha/spiruneg Though my attempts to throw some BCS data into LSZZ decoder in spiruneg never resulted in producing anything useful. The data it spits outs appears to be mostly 0x00 and 0xFF, and I couldn't see much else of note.