|
|
Post by Ačāla on Feb 9, 2016 21:09:10 GMT
Well, I would like to bring up a couple issues that has been a real big deal for me and my songs. In EoF 1.7, the tempo map is perfect. No issue whatsoever. In EoF 1.8, certain tempo changes force double, or even triple the tempo. This is only an issue with .Chart files, and I just need to know: Can you please fix this up? Also, if you recall my "guitar.ogg" post, you did say you were looking to implement that. I might think about it, but in all likelihood the most I'll probably do is have the save function the use the loaded OGG's file name and not write that file during save if the file exists at the destination. EOF will still have to ask for an OGG to be identified as chart audio. If you don't want to specify an OGG file, you can cancel the prompt and EOF will just have to disable playback functions (as it currently does in this scenario) because those require audio to be present. Either of these would be a definite plus for me, and something I could really use. So, thanks in advance. |
|
|
|
Post by raynebc on Feb 9, 2016 22:32:53 GMT
I haven't seen any such problem with Feedback import. I'm going to need more information, probably including an example .chart file with specific details about what is importing incorrectly.
As for EOF not requiring the OGG file to be named "guitar.ogg" during save, I haven't worked on that yet.
It would be best to not make this a catch-all thread for pending bugs/requests, and to use other threads as appropriate.
|
|
|
|
Post by JarheadHME on Feb 10, 2016 1:28:56 GMT
The chart file I linked earlier was one with an issue. It was forcing double greens. As I showed in both pictures, after some patterns, it'll force a green note that's already after another green note to be a hopo, which as we previously talked about, is not supposed to happen.
|
|
|
|
Post by Ačāla on Feb 10, 2016 2:06:57 GMT
It would be best to not make this a catch-all thread for pending bugs/requests, and to use other threads as appropriate. Just reminding. I know you have a tendency to not do anything, even though you "put in on your list." |
|
|
|
Post by raynebc on Feb 10, 2016 3:29:54 GMT
The chart file I linked earlier was one with an issue. It was forcing double greens. As I showed in both pictures, after some patterns, it'll force a green note that's already after another green note to be a hopo, which as we previously talked about, is not supposed to happen. I mentioned that the wrong HOPO issue is corrected in the next hotfix. If it's still a problem with that release, let me know. Just reminding. I know you have a tendency to not do anything, even though you "put in on your list." The list is real and it is huge, to the point that I prioritize fixing bugs and then pick a feature I personally find rewarding, or one that has been requested by more users, to add as an enhancement. Being condescending toward me doesn't motivate me to favor your priorities. I'll be waiting for a sample Feedback chart that imports with incorrect tempo changes as you described in your previous post, otherwise no changes to the import function will be made since I can't reproduce a problem. |
|
|
|
Post by Ačāla on Feb 10, 2016 6:07:59 GMT
The list is real and it is huge, to the point that I prioritize fixing bugs and then pick a feature I personally find rewarding, or one that has been requested by more users, to add as an enhancement. Being condescending toward me doesn't motivate me to favor your priorities. Well, if that's how you're to say it, I guess that's how it'll be said. Even so, I had no malice intended. I merely said it as you said it to me. I just didn't find the message to quote from. I am sincerely sorry if you took offense, though. I'll be waiting for a sample Feedback chart that imports with incorrect tempo changes as you described in your previous post, otherwise no changes to the import function will be made since I can't reproduce a problem. Here; my own originals. The glitch exists in all of them. dl.dropboxusercontent.com/u/74228127/Paradox%20Series.zipPlease note, on Paradox 4, the current .Chart was formed from the midi, so it has the glitched tempo. |
|
|
|
Post by raynebc on Feb 10, 2016 7:52:59 GMT
Looking at Paradox 1, it seems more like this is caused by how the chart file is authored:
Resolution = 480
...
0 = B 160000
0 = TS 4
80640 = B 160000
80880 = B 161000
81120 = B 162000
81360 = B 163000
81600 = B 164000
...
A resolution of 480 is not typical and would probably not have come from Feedback. This means that the timing is 480 ticks between each beat (like with Rock Band MIDI files), but the .chart file is written with tempo changes every HALF BEAT (240 ticks apart instead of 480 ticks apart). EOF imports this as it is expected to: Inserting beat markers to store each tempo change, and then correcting the tempos to account for what is effectively half-length beats (ie. double tempo). This is the intentional result of such an abnormal conversion. The options here include the following:
1. Correct the conversion. This might not be an option if the tools used are no longer being developed.
or
2. Alter the .chart file before importing into EOF by removing these mid-beat tempo changes.
or
3. Import the file as-is in EOF and then delete every other beat (ie. select one and use Beat>Delete or the associated CTRL+Del shortcut) to effectively halve the number of beats in the affected portions of the chart. Even a chart as glitchy as Paradox 1 should be fixable within 10 minutes or so with this method.
|
|
|
|
Post by Ačāla on Feb 10, 2016 20:14:41 GMT
If I understand what you're saying as well as I think I do, that would still have double the tempo, or more.
I have no idea why Paradox 1 is in resolution 480. I know Paradox 2 isn't. But, as I said, in EoF 1.7, this was not an issue. It did the correct conversion automatically. From what I can gather, it just removes the incorrect tempo changes, and leaves a semi-accurate-to-accurate number every beat. Not doubles/triples etc..
The problem with using EoF 1.7 there is that I have to go through and hand mark every single note as Ho/Po/S, thereby making several of your previous fixes absolutely pointless. Also, in EoF 1.7, it just doesn't support Part Keys... at all. So, it would very much be a great hassle for me to do things through the old system, or as you suggest.
|
|
|
|
Post by raynebc on Feb 10, 2016 21:39:36 GMT
The likely scenario is that EOF 1.71 and older simply ignored such improper tempo changes, but just over 3.5 years ago, I added logic to handle them so that the superfluous tempo changes were stored as anchored beats in EOF. This is something EOF has to do to ensure notes are imported with correct timings, it's not as simple as just ignoring them.
Paradox 2 is using the normal resolution of 192, but it has even worse problems:
Resolution = 192
...
1536 = B 130000
1600 = B 131000
1664 = B 132000
1728 = B 133000
...
Between beat 8 (position 1536) and beat 9 (position 1728), it defines two extra tempo changes that should not be there. This happens in several places throughout the chart. The biggest concern is why whatever chart conversion utility you are using even does this, as I can see no good reason for it. How were these charts authored/converted? It's possible a conversion utility you use is malfunctioning.
|
|
|
|
Post by Ačāla on Feb 10, 2016 21:55:41 GMT
Actually, I made them explicitly like that, straight from feedback. The tempo changes according to what I placed in FL Studio. So, in a way, your programming is in direct conflict of my old methods (usually, nowadays, I don't change tempo in a song). Though, I still don't understand why you would intentionally program a tempo change off of the beat to double/triple/quadruple (we can go higher, but only to two-thousand BPM; I know EoF only allows to that number). What good reason was there? Punishment? Torture? I legitimately have no idea. Maybe there is a good reason, and I just don't understand. Nonetheless, only antagonistic reasons, do I see. I'll just link this .Chart that shouldn't do it (but does); and I didn't make. Probably the same issue, but I haven't looked into it. Warmen_-_Salieri_Strikes_Back.chart (43.3 KB) |
|
|
|
Post by raynebc on Feb 10, 2016 22:46:26 GMT
You always seem so suspicious of others' motives, without understanding the reasons things are done. If EOF didn't process a mid-beat tempo change, the timing gets skewed because Feedback will have taken it into account. EOF has to process the change or else there is risk of note timings being incorrect. The only way EOF can store a tempo change is to put it on a beat marker, so a beat marker is inserted to store it. Since there are now more beats in the same amount of time, the tempo is increased. The best solution would be to not author it that way, and only have one tempo change per beat AT MOST. This is in line with Harmonix's original RBN authoring documentation. Can you provide a good reason to author a tempo change several times per beat? It is an entirely abnormal charting technique.
The chart file you linked to in your previous post also has mid-beat tempo changes. EOF treated these as expected.
It's possible I could program EOF to try to automatically remove the beats associated with the extra tempo changes defined in the .chart file, but that is only treating a symptom and not the problem itself.
|
|
|
|
Post by Ačāla on Feb 10, 2016 23:01:09 GMT
If EOF didn't process a mid-beat tempo change, the timing gets skewed because Feedback will have taken it into account. EOF has to process the change or else there is risk of note timings being incorrect. The only way EOF can store a tempo change is to put it on a beat marker, so a beat marker is inserted to store it. Since there are now more beats in the same amount of time, the tempo is increased. The best solution would be to not author it that way, and only have one tempo change per beat AT MOST. This is in line with Harmonix's original RBN authoring documentation. Can you provide a good reason to author a tempo change several times per beat? It is an entirely abnormal charting technique. I still don't understand your variation of that. From my sources, I can gather that many, many midi tools allow for this mid-beat tempo change. In fact, most of them agree that by the tick is the best solution. Even I, when I do tempo changes nowadays in FL Studio, I interpolate the rise and lower of tempo. It is quite literally by tick. Mainly, though, that's because FL decided that decimal tempo was better than whole numbers, assuming you have the monitor and DPI available. But it's also because I know that will give the "smoothest" results. It's possible I could program EOF to try to automatically remove the beats associated with the extra tempo changes defined in the .chart file, but that is only treating a symptom and not the problem itself. At least you're looking at it as an issue now. I don't plan on changing my charts, as they worked well enough in Guitar Hero III. But, I am willing to change them, only in the aspect that they remain the same as in Guitar Hero III by the looks of the highway in the actual game; and remain on-beat with the tempo. However, even as you said, this goes beyond my .Charts. You always seem so suspicious of others' motives, without understanding the reasons things are done. Sorry about that. I'm usually cautious and suspicious. |
|
|
|
Post by raynebc on Feb 11, 2016 0:13:43 GMT
The reason EOF does this is because it has no way to store a tempo change that is NOT on a beat marker. Only changing tempos on beat markers is generally the only way rhythm game charts have traditionally been made, which is why EOF handles it this way. What MIDI editors will allow is not entirely the same as what various rhythm game engines will handle well.
It's not an issue with EOF, but if you're that convinced this outcome is troublesome, I can try to make a user preference to delete mid-beat tempo changes after import. This will protect the note timings, but that is probably the most I can do to accommodate a fringe authoring style.
|
|
|
|
Post by Ačāla on Feb 11, 2016 0:22:34 GMT
As previously stated, if it still doubles the tempo, that's not really a solution. Though, if you do make into your hotfix, I'll give it a try. We'll have to come up with something from there, if nothing else.
|
|
|
|
Post by raynebc on Feb 11, 2016 1:11:15 GMT
In short, it will remove the beats EOF had to add to counteract all the mid-beat tempo changes, so the net result would be normal tempos.
|
|
I might think about it, but in all likelihood the most I'll probably do is have the save function the use the loaded OGG's file name and not write that file during save if the file exists at the destination. EOF will still have to ask for an OGG to be identified as chart audio. If you don't want to specify an OGG file, you can cancel the prompt and EOF will just have to disable playback functions (as it currently does in this scenario) because those require audio to be present.
