RW format conversion expects explicit speed parameter in Track.Announce

[alex-wenzel]

An RW format command such as @announce(\NYCT-V\BwayLafAnn.wav) will raise "Invalid closing parenthesis encountered at line ...". Changing it to @announce(\NYCT-V\BwayLafAnn.wav, 0) resolves the error. Since the CSV documentation says that Track.Announce(FileName; Speed) gives Speed a default value of 0 and the RW quick reference doesn't mention Track.Announce() in its list of behavior difference, I assume that many legacy RW routes will omit explicit values for Speed.

I haven't had a chance yet to sit down and walk my way through the conversion logic, but I'm guessing that this bug comes from some combination of current line 166 and current line 210 in CsvRwRouteParser.Expression.SeparateCommandsAndArguments.

[leezer3]

Frankly, as you can probably see, the route parser is somewhat of a mess to put it mildly, and originally started out life as a single monster file.
I've separated out parts into some more logical functions, but at it could really do with a complete re-write; I've slowly been doing this with the other parsers ( #947 is the latest WIP itineration to convert the CFG based files), but as ever it's actually getting around to that with anything else.....

The RW parser is somewhat worse of a mess, as it internally converts the RW format strings to CSV before parsing.

The function you've linked above is used to replace brackets in filenames (yes, I've found examples of that....) temporarily with the < character so the conversion process doesn't throw a complete fit.

---

RW format:
This is legacy even by BVE standards. It was the default format for the 1.x series of BVE.
BVE2 could also read it, but had CSV as the native format.
It was then deprecated for BVE4.
I think I've got archived somewhere some of the old western documentation for it (this is old Word documents dating back to ~1997....)

---

With all that said, I suspect the error is probably actually elsewhere in your file.
Unfortunately, the bracket conversion process at the point this error is generated simply doesn't care about commands and just matches brackets and works under it's own little subset of rules. An erroneous bracket somewhere can cause havoc.

I'll see about trying a proper test, but might be later in the week before I have a proper chance to dig.

[leezer3]

OK, that's odd, it's definitely hitting the block you linked above.

I can't see why either from an intial head-scratch. The very final condition, e.g. i != Text.Length -1 is false (as in this case i is currently 29, with a string length of 30 chars) and this is exactly what the guard was there for :/
I hate nested ifs....