Hopos in GZ

[callisto2002]

Hopos in Guitar Star follow this definition:

HOPOs are not defined in the midi, per se. They are defined as any note spaced equal to or closer together than 8th note triplets, which at the default GH PPQN rate of 480 ticks per quarter note, means any note seperated by < 161 ticks, that is not part of a chord, that is different from the previous note, that is not the first note of the song, and is not immediately following a chord (GH1 only, GH2 allows this) will be HOPO-able. If you use a different PPQN than 480, adjust the math appropriately (whatever 1/3 of your PPQN is).

Taken from: www.scorehero.com/forum/viewtopic.php?t=3788

Unless someone comes up with a different definition, this will be what GS does.

Bye,
Callisto

[luigi074]

Would a higher PPQN yield more HO/POs or less HO/POs? I'm a bit confused about that. Also, how do you adjust the PPQN rate, if possible?

[txf]

as long as we can get more accurate HoPos, then it'll be all good. Cuz right now the HoPos for alot of songs are messed up. So..yeah. Laid To Rest being of them <.<

[callisto2002]

@luigi
A higher PPQN will yield more HOPOs. Altering the PPQN depends on the file format. For example, in .chart files it is expressed using the "resolution" field.

txf
Again, GZ will follow this definition until another one is found. Therefore, it's not a question of HOPO being "accurate" - they are, according to this definition. Which, BTW, works fine for the songs where I can tell.

[iancer]

well how does Rogue-F do it? he defined a pretty spot on HOPO system...

[callisto2002]

iancer
What exactly is rogue-f? Google finds a lot of crap, but nothing GH related. Anyway, I really don't want to research that myself. If you find out how he/it handles hopos, let me know.

[darthslaw]

I think the default HOPO threshold for Guitar Hero is actually 170 (judging from beatmatcher.dtb) but the 10 click difference is probably just a grace/guarantee margin that the GH developers decided to use. In concept though, the PPQN / 3 formula stands.

For songs like Thunderhorse that have HOPOable 8th notes, the song data (found in songs.dtb) changes that threshold to 250 (~ PPQN / 2 = 240, or half of a quarter note -- an eighth note).



Btw, I think GZ2, when determining HOPOs, currently ignores what the resolution/PPQN/<CLICKS>/etc are in the chart and dat files it reads are. For example, if I make a chart in Feedback with resolution 192 (the default), then GZ2 makes more notes HOPOable, even though many of them are larger notes than 8th note triplets. It's kind of hard to explain...

Here's another wording... I have a song that is PPQN=192 in the chart, and PPQN=480 in the dat (generated from the chart). The dat has "proper" HOPOs while the chart is still being HOPO determined by the PPQN=480 scale, rather than PPQN=192.

Anyway, I think some implementation for changing the HOPO threshold for a song should be implemented before this 480 vs. true resolution issue is fixed. I've currently exploited it to make a (approximately) properly HOPO'd Thunderhorse dat -- link.

I could be wrong or overlooking something, but that's what discussion is for

[delirious1980]

rogue-f is rf-mod for FoF

[callisto2002]

@darthslaw
No, it's actually pretty simple. If you look at notes in a .chart song, the first column gives you the "tick time" or "click time" (whatever time you prefer). Now, GZ takes the .chart "resolution" (let's say 192), divides it by 3 (=64) and says that all notes that are closer together than 64 ticks are hopo-able (given that they are not chords etc.).

It's done similarely for .mid and .dat files. So, again - the question is: If you're of the opinion that this deifnition is wrong, please tell me which one would be right.

[iancer]

@callisto
i dunno if you play any GH songs, but if YOU actualy play Decontrol(GH1), Tattooed Love Boys(GH2), Play With Me(GHE) or Cliffs of Dover(GH3), you would admit the HOPO calculation leaves just a LITTLE to be desired, for the most part it seems, spot on, but facts are it is not. i am using mids, not .charts or .dats. i dunno how but Leff over @ the scorehero forums made an excellent .chart to .mid conversion program. it seems to creat mids with more acurate HOPOs than GHEX, Feedback, or even mid2Dat(i need to use chart2dat from these forums to create accurate .dats). i have yet to dicover a concrete definition of the best or even a "better" HOPO system, but i will research how Leff or Rouge-f(from fof.net) created there systems. your program is the most fun thing ive expierienced in a long while, and we ALL just want to help it be the best it can be, youre a guitar legend callisto, thank you!

@darthslaw
YOU HAVE TO EXPLAIN THE METHOD YOU USED TO CREATED THAT 'CORRECTED' THUNDERHORSE DAT, PLEASE!!!!!1 /caps you rock slaw.

try it yourselves:
i cant deny the fact that GHEX, Feedback, and Mid2Dat WILL NOT create note charts that have the correct HOPOs, only Leffs Chart2Mid2Chart or Chart2Dat works right for me, so there has to be a reason....RIGHT?!?!?!

[darthslaw]

@callisto:

I wasn't saying it's wrong, just that there was a problem in GZ2.

Apparently, that problem was corrected in beta 5, and I didn't realize it, so I withdraw my "complaint." I had an example song in chart format; the original chart was encoded with resolution = 192, and (using Excel + copy/paste methods) I scaled the tick times by 480/192 to "re-encode" it in resolution = 480. The problem I described before was only present when I played the songs in beta 4 update 4a; the same songs yielded no such problems in beta 5a. Same case with that Thunderhorse dat.


@lancer:

I opened the GH2 midi in feedback, saved as a chart, then used the chart2dat converter to convert to a dat at Clicks Per Beat (PPQN) = 192. That's not the exact number to perfectly replicate, but it was close enough for me. Note though, as I just discovered and mentioned above, that the conditions I exploited to make it work are no longer the case in GZ2 beta 5a; it works in Beta 4 update 4a though.

I had also converted Miserlou in a similar fashion to remove all HOPOs (converted at PPQN=2000), making it more playable, I think (my performance doesn't indicate it "beyond all doubt," but the HOPOs were definitely gone)

Oh, and one problem with the method is that the co-op tracks are not preserved. A rhythm.dat feature would fix this, but I have no idea how useful a feature like that would be outside of the context of this conversion technique.

[delirious1980]

Hiya
Having a look at the HOPO issue, I think that the method GZ2 uses is correct - but that the GH games do have SOME additional notes that are HOPO.

www.youtube.com/watch?v=hOLZeeCS0-4

That link is cliffs of dover. At 8 seconds there is a yellow (strum) followed by a green and orange HOPO. The notes are clearly 1/8 or more apart so there must be something else making them HOPO.

I would suggest keeping the system as it is at the moment. If there are any particularly problematic sequences, you can always adjust the tempo of the song to adjust it.

I made a song in 12/8 recently so half the triplets were coming out as HOPOs and the others weren't. By halving the tempo, they all became HOPOs.

Del

[darthslaw]

Okay, for the record:

Guitar Hero 3 MANUALLY assigns HOPO notes in the songs -- it is not (entirely) managed by a single set formula. If I wanted, I could make two notes 10 measures apart HOPO. This is why people have been trying to make correctly HOPO'd GH3 charts, and why success has varied -- because simply scaling the whole song's notes or bpm won't necessarily yield the correct HOPOs (let alone correct HOPOs for all difficulties in the chart). We simply don't have the same control in GZ1,2 and GH1,2,80s to do some of the things GH3 does exactly how GH3 does it.

Guitar Hero, Guitar Hero 2, and Guitar Hero Encore - 80s use the formula system; there is no known way to arbitrarily make certain notes HOPO as this feature exists ONLY in Guitar Hero 3. I reiterate, however, that Guitar Hero 2 and 80s (unsure of GH1) can change the threshold that is used by the formula. In fact, those games probably don't even use the formula directly. As I mentioned before, the game default HOPO_threshold appears to be 170 (for all practical purposes, it's 160: 480/3 = 160 ~= 170; the extra 10 is likely just an extra leeway/grace difference). Some songs change this threshold (this is the only real control modders have over HOPOs in GH 2 and 80s). The only alternative value I've seen is 250 (~240 = 480 / 2). Again, this value is obtained from a formula, a different one from the default value, but that's because it's using a different note size (8th notes -- 1/2 of a quarter note) This value is set on a per-song basis in the games.

The only reason GZ2 should stay with using the formula system is because not all custom songs have PPQN = 480 ; some have 192, others have different values. I think it can be assumed that all Guitar Hero midis are encoded with PPQN = 480, or, at least, that is the convention that Harmonix/RedOctane seem to have adhered to.

Sorry it's so long and dense this time, but I wanted to try to be clearer, since some people still seem to be misinterpreting what I'm saying. I've modded Guitar Hero 2, and I have fiddled with many of the finer features of the GH2 engine (including HOPO thresholds), so I would think I at least have a decent idea of what I'm talking about; please don't think I'm just spitting this out of my *** because I'm not.

Thanks for taking the time to read this, and I hope it helped clear up some ambiguities.


[edit]
Looking back, I think I may have been overreacting a bit... I apologize.

[hulkhaugen]

the little part i understood sounded right.. i'm pretty sure that "Play With Me" is one of the songs with a threshold value at 250. moonflow43 knows alot about this i think..

About the GH3 songs, maybe it's possible to add a file which specify hopo's that avoides the rules. just a .dat or .xml or something else that are clever. maybe even add it to the song.ini?

[callisto2002]

@darthslaw
What you're saying makes snse, especially regarding Gh3. If a file format that also supports HOPOs directly comes out, I'll be sure to support it in the game.

iancer
If that converter is really as good as you're saying, then it would be awesome if you could get any information about how Leff is doing the conversion!! I'd love to put it into the game.

hulkhaugen
I'd rather stick with a formula-based system to have a minimum amount of predictability and compatibility with other progs (i.e. FoF).

[darthslaw]

I've never fiddled with GH3, but I found these on ScoreHero...
Leff's GH3 Song Importer
What allows HOPOs in GH3?

Leff's GH3 importer that I linked to looks for a custom track event "*" in the source chart to create an arbitrary HOPO on a note (or remove it if the note would normally be a HOPO)... maybe you can add that functionality for chart files? Ghex and Chart2mid2chart both ignore unknown events when making a midi file IIRC, so it wouldn't cause problems there; in fact, that probably negates almost any reason for implementing the feature for midi files.

I'm guessing it's a track event (located in, say, [SingleExpert]) and not a song event (located in [Events]) for what I imagine are obvious reasons, but I haven't used the program before, so I might be wrong.

[txf]

Not to be anoying. But wouldn't it work by just making the..um..ticks..or..um..whatever decides the HoPOs(I really don't understand any of this)..just slightly higher/lower(whichever ADDS hopos)..like, i mean just "SLIGHTLY".. Becuase if you play gz, you can tell it's not off by a whole lot. Some songs are pefect, where as others are off. It's just barely off. So couldn't it work fine by just SLIGHTLY changing the number of 'whatever' decides HoPos?

Like I said, I'm not trying to be anoying. It would just seem to be somewhat helpful. Because right now there are definetly songs that aren't really playable with the current HoPos.(including a few official song)..and it wouldn't really 'hurt' the songs that are fine, and it would make the songs that are wrong, better.



Like I said, if I said something wrong, sorry. I really don't understand most of the topic regarding how HoPos work, I just figured my 'idea' could work. :/


I mean, just because Guitar Hero uses that method, doesn't mean that EXACT method is neccesarily best for GZ. So why not slightly modify to make songs more playable?

[callisto2002]

txf
So your idea is to break the songs that are working at the moment and have other songs working instead? Sorry, but I don't really see how this should be helpful?

[txf]

"Break" the songs that are working?...All it would do is make it slightly easier wouldn't it? I'd rather have a few slightly easier songs, and ALL working songs, than have songs I can't even play due to lack of HoPos

:/

[hulkhaugen]

the problem is related to songs having different treshold values, right? most 170 and some 250 i think

[lazerlike42]

As far as I understand it, the issue is about the PPQN being 170 versus 250. It wouldn't be needed to "break" anything. I see either one of two different solutions.

The first is for GZ to read the PPQN rating on the midi file and base what it does on that. I am no expert on any of this, so maybe this is not possible. It may also not be the best idea, if there is not a consistent accuracy with the values of the midi files that are available.

The second is to simply have some sort of line in the song.ini file or something which specifies that the song is a 250 rather than a 160/170. Have a line like "Extra PPQN = True" or something. Have GZ look for this line, and calculate based on 250 if it is true, and on 160/170 if it is false, treating as false any song.inis which do not have the line.

Or, have a line that says "PPQN=" Have GZ treat songs without that line as 160/170, and if the line is present, use the value it specifies.

This way, all anyone has to do if he wants to play like, "Play with Me" or one of the other 250 songs, is to add the line to the song.ini file. Seems simple, should make the unlayable songs playable, and I'm not expert in C#, but I would think it would take about 3 lines of code and one variable to make work.

In any case, I do think that the issue is important. As I can tell, its the only real flaw that the game has right now. Fix this and the rest of the changes/fixes will be largely aesthetic.

[hulkhaugen]

i agree with the idea of putting in a PPQN value in the song.ini if it's not standard(170). But there's also been some talking about an extra file containing spesific hopo's for the gh3 songs etc. maybe have a separate notes.ini to specify these hopos and the ppqn/tresholds, and only songinfo in the song.ini

[iancer]

what does the 'eighthnote' tag in the ini's do?

[txf]

its for a mod in FoF i think <.<

[lazerlike42]

Apr 18, 2008 7:27:23 GMT -5 hulkhaugen said:

i agree with the idea of putting in a PPQN value in the song.ini if it's not standard(170). But there's also been some talking about an extra file containing spesific hopo's for the gh3 songs etc. maybe have a separate notes.ini to specify these hopos and the ppqn/tresholds, and only songinfo in the song.ini

Well, the GH3 issue is an altogether different one. In GH, GH2, and GHE, there is a strict forumla for HoPos. The issue is that GZ only uses one value to callculate it, and in GH2 and GHE some of the songs use a different number. Same formula, different values being plugged in. In GH3, its altogether more complicated because the HoPo system is based off of individual notes being assigned as HoPos rather than merely a formula.

So to make GH3 songs work perfectly, something complicated like that will have to be done. But for GH2 and GHE, all it will take is a quick method to make the computer divide 250 by 3 instead of 170.

In other words, with GH3, we're dealing with unique arrangements for each individual song, each song having many different things that need to be specified in very specific places and times. That will take really a whole new.... it will take creating a unique layout for each song, whether it is included in the midi somehow or in a seperate xml file. With GH2 and GHE, it simply takes one minor change in code and one particular and consistent line added to ini files. GH3 is complicated to fix and has to be done for each and every song individually. For GH2 and GHE, callisto can fix 20 some odd songs with a variable (generally speaking).

[hulkhaugen]

yes, i knew that. kinda what i said, wasn't it?

i remember darthslaw talked about this earlier, but the info for the gh3 hopo's is specified in another file, that's why i suggested a notes.ini. it could contain the gh3 hopos and ppqn/treshold which we need for the gh2 and ghe80s songs..

EDIT: Are u sure all hopos in gh3 are specified? thought only the exeptions were specified...

[darthslaw]

lazerlike42

A few things you said suggest some confusion about the numbers, or at least the definition of PPQN...

all it will take is a quick method to make the computer divide 250 by 3 instead of 170.

the issue is about the PPQN being 170 versus 250.

etc

The PPQN is the number of ticks in a quarter note. In all GH songs, the PPQN is 480. The HoPo threshold for a song is either 250 or 170, depending on what the game's songs.dtb says for that particular song (it's not stored in the midi file). You can get 170 (the default) by dividing the PPQN by 3 (1/3 of a quarter note = eighth note triplet). Yes, 480/3 = 160, but the game designers probably used 170 to have a "safety net" so things wouldn't accidentally break. Same with the 250, which we get from dividing 480 by 2 (one half of a quarter note = an eighth note).


hulkhaugen

I couldn't tell you for sure, but Leff on ScoreHero wrote a converter for GH3 midis that would scan for the "*" event in a chart file and create a HOPO if the note at that event click is not a HOPO, or removes the HOPO if the note is a HOPO already (I also mentioned this a few posts up in this thread). However, for all I know, behind the scenes, the converter is adding HOPO triggers for all notes that should be HOPO, rather than just the non-HoPos marked by '*'.

Here's some pseudo-like code to help illustrate. In this example, the code will add HoPo-enable information for all HoPos in the song, whether naturally HoPo or forced by the '*' event:


int clickTimeLastNote = ...;
int clickTimeCurNote = ...;
int HoPoThreshold = 170; // GH default
boolean isNoteTagged = ...; // if the note is tagged with a '*' event
// if note is naturally a HoPo and is not tagged with '*', OR
// if note is not a natural HoPo but is tagged with '*'
// then make the note a HoPo
if(
((clickTimeCurNote - clickTimeLastNote) <= HoPoThreshold && !isNoteTagged) ||
((clickTimeCurNote - clickTimeLastNote) > HoPoThreshold && isNoteTagged)
)
{
// make note HoPo
}

(Sorry it's not indented or anything... this forum really needs better code tags)

I think the best course for implementing GH3 arbitrary HoPos in GZ would be to follow the convention started by that converter, with the '*' event.

Oh, and regarding the notes.ini, yeah, some file like that would be best for changing the song's HoPo threshold, and changing it only for the one song. There's really no other place such a definition could go, besides song.ini (well, actually, for chart and dat files, it could go right in the song file I guess... only midis would need to use the song.ini/notes.ini)

[txf]

Dunno if this is anything, but meh.

I was playing a song from Melonman67, "Buddydoke"...and it was anoying to play due to lack of HoPos... So I opened the .dat(he used.dats)..I opened it with notepad. I edited the "<CLICKS> #". It was 480, so I tried lowering it to 200(i had no idea what I was doing, but i knew something in the dat had to determine something)... turned out it removed almost, if not ALL the HoPos from the song. the bpm(?) lines on the fretboard didn't change, but it removed the HoPos... so I decided to make the number 1000. Now theres more HoPos, but the bpm lines(?) are the same as they were at 480.

I dunno. I just thought it had to due with modding HoPos, so i'd put it here.

[darthslaw]

Hmm, so it seems GZ2 uses the time in seconds to place things, and not the clicks (if it used the clicks, like GZ1, notes, beat lines, etc would be moved as well)

The click times for the notes are probably still used for determining HoPo notes though, since changing the resolution altered what GZ2 considered to be HoPo. Since the resolution (the scale) is being changed but not the click times of the notes (i.e. not being scaled with the resolution), it allows for some funky manipulation. For a practical example, two notes are 240 clicks away (eighth notes, 480/2) in a resolution/PPQN = 480 dat file. So, to find the new resolution that will make 8th notes HoPo:
n/3 = 240 -> n = 720

Changing the PPQN to 720 should then do the trick. (tested and it does). Cool discovery txf

[lazerlike42]

Now, when I go changing the PPQN on midi files, it messes up the timing of the song... in other words, if I change it from 480 to 720, the tempo is not correct (I forget if its too slow or too fast). How do I change the PPQN properly to acheive the effect you guys got?