livesplit / livesplit-core Goto Github PK

Both LSS files Side By Side

I'm trying to build using the instructions in the README and I get this output:

$ cargo build --release -p livesplit_core_capi
error: package id specification `livesplit_core_capi` matched no packages

Version info if it helps (macOS 10.12.3):

$ cargo --version
cargo-0.17.0-dev (f9e5481 2017-03-03)
$ rustc --version
rustc 1.16.0

Any urn file I try and parse segfaults if it is missing the 'start_delay' key in the json.
I can't really determine if this is a bug in ls-core or from something else, I had issues with both emscripten and a basic C program.

The urn spec says that all keys are optional so not having 'start_delay' shouldn't error.

I don't have any issues loading the same file in the actual urn application.

The fractional part is rounded, so it can sometimes show as .100, which is not what we want. So we should add a small epsilon, truncate and get rid of the .100 case.

In the Python bindings, class Run.parse_file is doing a:

bytes = bytearray(file.read())

But it needs to pick an encoding, at least in my Python 3.6.2 just installed from python.org, such as:

bytes = bytearray(file.read(), 'utf8')

• Windows
• Linux
• macOS
• emscripten

Algorithms shouldn't run while typing.

Port this from here: LiveSplit/LiveSplit.Title@81091e8

The Splits Editor should act similar to a component. So pretty much everything about it should be implemented in livesplit-core. The Splits Editor provides a state object that contains all the necessary information for visualizing it in any kind of UI.

Things to clear up: Should the Splits Editor directly modify the Run object that is in use by the timer and keep a clone in case we need to cancel our progress, or should we just modify the clone in the first place and replace the Run used by the timer once the changes are approved? The former case has a lot of issues with potential race conditions and forces us to introduces reference counting and reader writer locks in most of the code we already wrote. However it models what the original LiveSplit is doing more closely.

I don't have an Android phone, so I have no idea how these splits look like. Help anyone?

So far there's no layouts in livesplit-core at all. They obviously should be handled in some way.

Detected by cargo-fuzz:

oom-72aad0e03b7b54e4f043ee57ec526409fffe1b4f.zip

For some reason I completely forgot about that.

Similarly to the Run Editor, the Layout Editor should also have a UI independent implementation in livesplit-core, that allows placing components, moving them around and changing their settings. The settings of each component should be available in some kind of general description of the settings. So there would be some kind of enum like this:

pub enum Setting {
    Integer { name: String, value: i32 },
    String { name: String, value: String },
    Table(...),
    List(...),
}

This allows for representing 584.554531 years while also being maximally precise.

Update: Actually this seems mostly like an issue when it comes to algorithms that use a seconds / milliseconds / nanoseconds representation. So those should potentially be rewritten to use TimeSpan instead (i.e. extend it to support those use cases). If TimeSpan can't be made to support those use cases, they should at least switch to a u64 nanoseconds representation. Summing up and averaging could theoretically be problematic in case the sum overflows the 584 years, which is unlikely but could happen.

With the components supporting most "logic settings" by now, we want to be able to also implement the color and font settings. This is however blocked by the Layout Settings, as that's where the default colors and fonts are specified.

LiveSplitCore is not defined.
Looks like something changed for the typescript bindings but didn't get changed for the JS bindings.

We should reduce unnecessary allocations as much as possible. I wasn't all too sure if Cow plays well with serde, so I didn't use it until now, but I just tested it and it works to seem fine, so yeah, we should use it.

Seems to be an issue in normal LiveSplit as well, except that we prevent you from entering negative times there.

Best Segment times should be fixed based on the comparison times before the Segment History times are adjusted to be at least as long as the Best Segment.

LiveSplit/LiveSplit@f2331c9

LiveSplit/LiveSplit@a514f11#diff-f44c785c85846d6fc25ca87e23a308d4R82

Seems like we don't properly handle this in most of the language bindings.

Languages to check / fix:

Output:

• JavaScript / TypeScript for emscripten
• JavaScript / TypeScript for Node
• JavaScript / TypeScript for WASM
• C#
• Java JNA
• Java JNI
• Kotlin JNI
• Swift
• Ruby
• Python

Input (apparently we have no function that takes a nullable string as input atm):

• JavaScript / TypeScript for emscripten
• JavaScript / TypeScript for Node
• JavaScript / TypeScript for WASM
• C#
• Java JNA
• Java JNI
• Kotlin JNI
• Swift
• Ruby
• Python

Detected through cargo-fuzz:

crash-52cdb28f04f0c80d84609394d18ed2c0b8fedb7f.zip

I'm not sure if it even should be a component

Requires Speedrun.com API Support

This is far enough into development that we can move it over.

It is way too large and causes huge diffs, which increases the size of this repository. Maybe use GitHub Releases to provide the current version of the JavaScript library.

They should finally merge in livesplit-core.

LiveSplit/LiveSplit@238e8ba

We have all the information necessary for calculating the extended category name, so we should show it.

We most likely want something less passive, but also not too intrusive. ESA wants this, so this should be implemented fairly soon. For it to be done so soon, it probably won't stay the final solution, as I want to be able to switch around all kinds of timer sources for synchronization and unit testing purposes, which the initial design probably won't entail.

There's now Automatic, Left and Centered as the Text Alignment Options.

In the Detailed Timer an uninitialized Game Time is shown as a dash on the segment timer, which is not what the original LiveSplit is doing there. I presume that's because I don't reuse any of logic of the Timer Component for the Segment Timer in livesplit-core, only the State, while the original LiveSplit uses more of it.

It generally doesn't make much sense too store super large images, so we re-encode them as JPEGS < 256x256 (while keeping the aspect ratio in mind).

BTreeMap automatically solves this problem, so it should be preferred over a HashMap.

Splitting, resetting and other operations should affect the scroll offset like it does in the old LiveSplit.

I'm not quite sure how this would work yet, as you need the emscripten compiler, and that requires you to compile LLVM which takes over an hour, so that's not a feasible solution. However the rust repository has automatic cross compilations of the standard library via CI, so we can potentially replicate what they do.