LiveSplit/LiveSplit#931

livesplit-core supports this now.

That will probably require us to load the wasm binary before including any React component that uses livesplit-core, in order to ensure that the wasm binary is loaded before it gets used. So some form of a loading screen is required for this.

Also we definitely want to keep the asm.js fallback for older browsers. So that should possibly reside in an external file (not in the bundle), to ensure we don't load livesplit-core twice in modern browsers (both asm.js and wasm).

Hotkey Settings, Splits I/O Login, ...

This should obviously only happen if the run is modified, like in the original LiveSplit. I'm not quite sure how well this works in livesplit-core. So it might need some patching.

Checking the box to enable them does absolutely nothing as the componment itself does not even have code written to display them.

It's not really bad, but I think we should be using requestAnimationFrame() or something, but last time I tried it, it was super janky, so we should look into this more.

Whenever they get passed an empty Run / Layout, their creation method is returning null now. Before, livesplit-core just panicked, which was not ideal. With the Timer not being able to be created when having an empty Run, there might not ever be a code path that actually leads to the Run Editor being opened with an empty Run. Similarly with the Layout Editor.

A simple About dialog to show copyright, creators and a link to the GitHub repo, similar to LiveSplit's.

As long as we don't have mobile apps, the web version is the way to go, so we should improve the Mobile Layout.

• Layout Renderer
• Run Editor
• Layout Editor
• Settings

Not sure if this would require changes to livesplit-core because it would essentially just be changing attributes on the html itself.

Customization will obviously not be possible initially, but being able to show it is enough until we have layouts with settings.

I'm not sure what causes this, but at least in Chrome the file dialog sometimes just doesn't call its "success" event.

The Sidebar is beginning to get really cluttered. I'd prefer to group together the actions available in the sidebar and have a submenu for each one of them that shows the actual actions, kind of like the right click menu in the original LiveSplit.

React seems to polyfill the keyboard events, which seems to merge the normal digits and the digits on the numpad. This obviously only applies to old browsers. The problem is that all the digits are recognized as normal digits now, but we require the actual numpad keys in the default configuration. In order to solve it, we polyfill all the normal digits to be recognized as numpad keys in livesplit-hotkey, which is fairly suboptimal, as this really only applies to React.

Instead, LiveSplit One itself should handle this situation and swap the default Hotkey configuration to the digits instead of the numpad. Alternatively we could figure out a way to prevent from polyfilling it like that. Thinking about it, we could load a different polyfill before React can bring in its own.

Issue description

Steps to reproduce the issue

1. Open https://livesplit.github.io/LiveSplitOne, I recommend doing this in a private browser window so your localStorage does not get overwritten
2. Finish a run, even if it's only the default run with one split so you have split times
3. Save or export the file file
4. Refresh the tab
5. Import your savefile

What's the expected result?

• On refreshing the tab in (4.) I expect the split times to be included so I can compare my next run to them
• Same goes for the exported xml in (5.)
• When I download a sample xml from splits.io the split times are actually included in the xml file

What's the actual result?

• On refreshing the tab in (4.) the restored xml in the localStorage does not include the split times generated in (2.)
• Same goes for the exported xml in (5.)

Additional details / screenshot

This might be an issue with livesplit-core instead of LiveSplitOne

There's some weird overlapping going on:

Downloading splits sometimes doesn't work on Chrome and some mobile browsers. I think encoding as base64 may help there. This is one of those files that don't work on Chrome: https://cryze.github.io/LiveSplitOne/#/splits-io/fgh

Submitting every valid intermediate state causes the fixing algorithms to run on those intermediate states, which often causes the Best Segment Times and the following segments to get fixed in an unintended way.

At the moment it causes a force refresh of the page, but that's absolutely not necessary at all.

This will be important as we want to turn LiveSplit One into a larger scale web page, and not just the web equivalent of the original LiveSplit. I already began working on it a bit, and it doesn't seem too hard.

No idea why, but Chrome spits out a warning. Maybe it's an error on Firefox, so that's why it doesn't work there.

Shouldn't be all too hard, but requires an alternative CSS that aligns everything to the left in case there is a game icon.

livesplit-core now supports showing the Finished Runs Count and hiding the Attempt Count. The Title Component needs to be updated to handle this.

CryZe/livesplit-core@4ca2c24

This used to be blocked by livesplit-core, but due to all the async changes happening in Rust, I'd like to implement the Web Communication with normal TypeScript first and later move that stuff over into Rust, once the Rust ecosystem is ready.

This used to be blocked by livesplit-core, but due to all the async changes happening in Rust, I'd like to implement the Web Communication with normal TypeScript first and later move that stuff over into Rust, once the Rust ecosystem is ready.

#58 accidentally removed them:

So Can You Guys Make It So You Can Zoom Out And In? I Can Barley See Any of My Splits And I Would Love It If We Could Be Able To Zoom Out And In To See More Of Our Splits. Thanks!

While trying to raise the FPS to 60, I noticed a huge spike in CPU usage, so I decided to investigate. Using the React Developer Tools, I was able to see that the entire layout was updating, and not just the parts that actually changed. The screenshot below shows all the updates happening on the layout every frame.

Due to the large amount of layout updates, React has a hard time keeping up on low end hardware. (caused by dev build.) If we can reduce the amount of updates React is having to process, we can reduce the amount of CPU usage. #

At the moment, the split button is small requiring quite a bit of effort to press, especially on a phone. By making the layout act as a split button, the timer is so much more useful on moble. However, the layout should not start the timer in order to prevent accidentally starting the timer.

livesplit-core provides all the component states as objects that you can traverse. Exposing their states as JSON was quite a fun idea, as that can be directly converted into a JavaScript object. However serializing into JSON and back into a JavaScript object is potentially more expensive than using the state objects directly. So we should try using those and see if it's faster.

I tried to get it to compile after installing all the components I could find like the nightly build of Rust/Cargo and the target "asmjs-unknown-emscripten" but I can't seem to get it to compile and always get given an extremely lengthy and cryptic error:
Debug.txt

Any assistance in solving this error would be appreciated or tips on compiling.

This used to be blocked by livesplit-core, but due to all the async changes happening in Rust, I'd like to implement the Web Communication with normal TypeScript first and later move that stuff over into Rust, once the Rust ecosystem is ready.

This issue specifically may however still be somewhat blocked by livesplit-core, as it probably requires changes in the Run Editor's state.

So here is the deal. I was 2 minutes ahead of my PB, until I hit the fucking back button on my phone by mistake. If there was a message that popped up asking me if I wanted to close the page, I would not have lost that run.

Edit: I apologize for the slightly hateful tone. This was written after I just lost the run.

Can We Please Have This As A Mobile App In The Appstore Please I Would Literally Pay $0-$10 Dollars For The App. So If You Good Can Please Make This A App Because I Tried Tops And It Was WAAAAAAAY Better Then My App I Have (Msplit) And I Would Be Very Grateful :D

http://sass-lang.com/

LiveSplit/livesplit-core#63

Specifically Mobile Browsers and Firefox.

Exactly the same as LiveSplit, just a dialog to share and export as different formats.

Seems like Forms aren't considered valid table rows (which kinda makes sense).

The idea is that clients (such as auto-splitters) would be able to connect to LiveSplitOne to split/reset/etc.

As a lot of you may already know, localStorage normally has a quota of 5MB, (can vary across browsers), and attempting to store more than that limit will result in an error. In Firefox and Opera, this limit can be raised as needed by the user, but other browsers have to deal with this limit. Currently LiveSplit One is saving and loading splits from localStorage, and split files like to grow when icons are added and attempts are recorded. This will cause issues when saving, meaning users will eventually have to start importing and exporting their splits in order to continue using them.