Here is an ODLC example (Alice in Chains: No Excuses):

 

and here is me trying to recreate it:

 

Aside from some sustain lengths, the xml for both examples are the same.

 

It looks similar, but the extra highlighted fret markers on the second picture are distracting.  Has anyone found a way to manipulate when a fret marker is highlighted?

Another example:

i have issue figuring out what you consider distracting since both screenshot shows exactly the same thing and i don't want to look for 10+ minutes for what is the thing that is bothering you.

 

The numbers in the red boxes are not in the ODLC version.

Seems like it could be related to the fact both chord aren't identical (the open note aren't in yours while the ODLC have them but hidden).

 

At least that would be my first guess would have to play around a bit as i don't really know what is forcing the display on those fret reminder.

Maybe it's toolkit magic that decides when the fret markers are highlighted. :)

I don't think so, the game is quite good at making decision on what it wants to display depending on the chart (for example the fingering can have additional ring around the number and RS decide when to use those to show a specific information that neither the toolkit or EOF control directly. I wouldn't be surprised if this is the same kind of thing where RS decide to add this because he think it needs to due to the logic behind that and without knowing the logic you can't know what to do to avoid it.

 

But as i said, in the ODLC you can see that the number aren't highlighted on the very last chord shown unlike in your example which do seem to indicate that there's a difference that would explain why RS highlight it on the CDLC and not on the ODLC. For me the reason would seem that RS consider it's not the "same chord" in some way in the CDLC and not in the ODLC.

well we actually write that kind of data and it's fixed to some point so it won't write it to each one note'chord > because it will clutter the screen it should trigger about every 12 or so notes iirc not sure if you've undercovered a bug here or is it same link next bug? hmm

@@Alex360 What kind of data? Cause i know for a fact the ring around fingering isn't written by anyone and it's just a byproduct of RS interpretation of data.

 

If you actually mark when the game should highlight some fret number, it would be interesting to at least have some kind of control or at least possibility to adjust it if we need to.

@@firekorn we've got logic to write that fret numbers under the notes right here: https://github.com/rscustom/rocksmith-custom-song-toolkit/blob/master/RocksmithToolkitLib/Sng/Sng2014FileWriter.cs#L1244 it seems we mark it each 8 notes :)

Thanks for the insight.

 

This is just a suggestion:

(I assume) almost no one else in the CDLC community uses the ignore function.  Could you add some magic so when a note/chord is ignored the fret marker is not highlighted?

 

What do you guys think?

 

If this is something you agree with, I can provide examples on when ODLC tends to use ignore, so we don't step on any of those cases.

@@Rockfirstlast for me it's clearly misinterpretation of sequence of notes since it should be per chord I guess, but those chords has 12 notes in row so I could just try to fix this for chords probably, so it would be a bit right than it's now

I don't feel right doing per ignore statues exception for numbering, since we can actually see those in game it's just doesn't score.

Wouldn't that make sense for the user to have control over EOF for all users though? I'm not sure how @@raynebc would feel about it but knowing that i can't control how something is displayed doesn't feel right.

 

For me the toolkit should just convert file to the right format and pack it all together, it shouldn't be altering the chart that was wrote in EOF in any unpredictable or uncontrollable way.

 

Also, i don't look into the toolkit code, i'm not a dev and i don't have the time or knowledge to look around to figure stuff out about what and how the toolkit do things. I trust that you guys know what and how to do it well enough in the first place that i shouldn't be looking over every bit of code that was written. Which is why i assume this was just something RS did, if it's not in EOF and the toolkit doesn't show or explicitly say that he add/create this, how could i know it does?

 

And if this stays in the toolkit could we have at least some kind of control over it?

@@firekorn, sure thing I can easily (or with a bit of hassle) add option at config screen to change this preference - change amount of notes to skip (which initially based on RS2014 lessons charts and surely evolve through years). can I have example files for this bug please?

Actually toolkit's doing it's black magic :D Thing is... sometimes you need no actual control over certain things ( recall those horrible interfaces with huge screen of config parameters :D ) plus EOF already suffering from huge amount of parameters to change.

Toolkit's goal should be 1:1 conversion of input data to output file. Currently all testing in on users shoulders since we have no tests for generators.
I have intention but have no time\skill to perform this coverage thing along with documentations stuff. sorry about that.

 

I'd like to hear from raynebc about this as well. still imo that this is toolkit part of a job. (sng generator should care about where to place things by schema)

@@Alex360 EOF is suffering from a legacy that it has to maintain and an engine that is outdate now. But even with this EOF is incredibly good at what it's supposed to do and i know that what i control in EOF will properly translate over RS the way i expect it too.

 

 

Thing is... sometimes you need no actual control over certain things ( recall those horrible interfaces with huge screen of config parameters :D )

 

That's arguable, it's kinda like FHP in EOF, the user could have no control over it and it could simply be auto generated without actually making CDLC that much worse. I don't mind that something is automatically generated by an algorithm, as long as the result actually work in all use cases. When it doesn't i want to be able to adjust it to fit my expectation :)

 

Note that we are talking about something that won't make a chart break or impossible to play, it's a very small detail that i can easily live without control over as long as i know who actually control it.

 

 

I have intention but have no time\skill to perform this coverage thing along with documentations stuff. sorry about that.

Don't be sorry, i don't expect the toolkit to have a quality control and i don't mind that the users are the one doing it. My issue isn't so much with that than with the fact there is something that the toolkit control without anyone knowing about it except the few devs with insight on the code.

 

I'm sure @@Rockfirstlast can provide you with files that correspond to his test and that this can be sorted out pretty easily.

 

Also if the logic was based on the lesson it might good to probably review a bit how things have evolved in general cause lessons are now quite different or doesn't use something that we now see in oDLC.

Thanks again guys.

 

Here is what's happening for the first 4 notes according to the XML (as unpacked by the latest toolkit test build).

 

 

Maybe I am wrong to trust the unpacked XML.  I noticed every highdensity occurrence in the song is set to 0, which doesn't sound right.

I should add there are no open notes at t=20.525 or t=20.731

@@Rockfirstlast how about xml or eof or sng file? :D

It took me a while to understand that the issue was the numbers displayed to label the frets. I'm not sure what the best solution would be, I'd have thought automating it to be once every # of notes/beats/seconds would be fine. If there's demand for a way the author can control these (ie. define each manually, or define how far apart each one is based on number of beats/notes/seconds), I guess we could make options for it.