Search results

Thanks (._. )

We should take a habit of using Preferences.resetToDefault( String ), rather than manually setting every preference to a set value, in ValhallaManager.resetPerAscensionCounters() I did the transition myself, and am ready to submit a patch, but while doing it, I found four discrepancies. Two of...

The new constants in SkillPool.java are out of order :(

chatlogs conserve the HTML, right? So if they just submit their chatlog for the day, you can just search for mod announcements, and open the inspector?

No, not really. While both currently only lead to a simple exception throwing, the latter will end up causing the method to be exited early, since we can't tell if we're still parsing an aggregate. With the former, we know we're still in one.

Looking at my finished/destination version... it definitely seems possible to work around bringing it back. In an earlier version, there was a point where it was needed, but where I'm at now, no, it wouldn't really be a "problem". It's really just redundant code that I can't fathom the point...

Here

Sooooo... was that a "it's better if you do it like this next time(s)", or was that a "could you please re-submit all of these as a single patch / group them"?

3rd batch. Same thing. Again.

2nd batch. Same thing.

Also, if we discover that one of the file we're currently parsing is being imported by another file/script. This is a behaviour/necessity I am hoping to get rid of, but currently, yes, it's a reason to interrupt the parsing.

some methods will abort early, because they know too little about what's in front of them to know if it's even worth trying to match what it is with what is "expected", but if you mean aborting the whole parsing, no, there's no benefit to that. Well, actually, yes, there's one. From the...

Here's the first batch. There's a lot of them, but again, this is just because I'm splitting them as small as possible. I'm currently making 1 patch per method. If I'm going too small, just say it. These are, as noted above, only small conditional changes. They are independent from each other...

This should be the end of the "first" major step for the language server. Onto the second and third. Second and third are: Always reach the end of the file. I.e. even if there's an error, continue parsing while trying to get our bearings back. Implement the use of Locations, i.e. allow every...

Welp, that was painful. Here's hoping I never do that again. This is an update of parseAggregateType, split into 4 steps for easier review. fix the unwanted behaviour we discussed earlier wrap the last case in an "else" conditional In other words, transitions from if (x) { [...]...

(i.e. it doesn't understand that they're both supposed to point to the same file)

@heeheehee btw, how'd you manage to make a patch that's "a modified version vs another modified version"? I don't see a way to "store" a version of a file to diff. it against a later version of it, and if I make a copy of the file, and diff. that copy vs the updated original, it gives this: ---...

It's not "harm", per se, but it's redundant logic that needs to be altered in the future to accommodate one of the incoming changes, meaning the change would need to be applied twice, while there's no need for it. Wouldn't anonymous functions still just go in parseValue? Just like how...

Anything I can do to help? I prefer to not have too many submissions open at once , so I'm currently not really doing anything, meanwhile...

Yes, it's just for the "abrupt line termination" (or just "there's not as many characters as we expect") ? \1 or \12 triggers it..? these errors don't "only" trigger for \u and \x (i.e. a linebreak "right after" the special character) they trigger for: \x \x1 \u \u1 \u12 \u123 \1 \12