giseldo/neodataset huggingface dataset:
Error when clicking single player from main menu

I'm getting this error while compiling from `cargo clean` then `cargo run --bin veloren-voxygen`. I've deleted my local repo folder and re-cloned as well, and the first time I compiled I got passed the singleplayer screen, but then got another error at the character selection screen

This is the error message,
```
PanicInfo { payload: Any, message: None, location: Location { file: "voxygen/src/menu/main/start_singleplayer.rs", line: 38, col: 43 } }
Gtk-Message: 14:06:34.727: GtkDialog mapped without a transient parent. This is discouraged.
```

The code at that location is
```
// Client creation
let client = loop {
    match client_init.poll() {
        Some(Ok(client)) => break client,
        // Should always work
        Some(Err(err)) => unreachable!(), // This line threw the error
        _ => {}
    }
};
```

System info

Veloren version
c96bfa6ddd458e590104245ee0fada158bcfbd9f on Master

Rust toolchain version
```
active toolchain
----------------

nightly-x86_64-unknown-linux-gnu (default)
rustc 1.36.0-nightly (8dd4aae9a 2019-05-04)
```

Running Ubuntu 18.04.2 LTS

Story points: 2.0
Fetching of submodules fails

When following the instructions on https://book.veloren.net/dl/compiling.html the updating of the submodule fails with the following message:
``` powershell
Submodule 'assets/voxygen' (https://gitlab.com/veloren/fresh-assets/voxygen.git) registered for path 'assets/voxygen'
Cloning into 'D:/projects/rust/veloren/assets/voxygen'...
error: Server does not allow request for unadvertised object cff10b010db25ce9af5edbdfb5ef0af889dd741a
Fetched in submodule path 'assets/voxygen', but it did not contain cff10b010db25ce9af5edbdfb5ef0af889dd741a. Direct fetching of that commit failed.
```

I managed to fix it with appending "--depth 50"
``` powershell
git submodule update --init --recursive --depth 50
```

I don't know if there is anything you can do about it, but you should at least update the documentation.

Story points: 1.0
Issue in Vek crate gives compile time warnings

When compiling, Vek throws many warnings similar to this.

```bash
warning[E0502]: cannot borrow `rows` as immutable because it is also borrowed as mutable
    --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/vek-0.9.7/src/mat.rs:1897:31
     |
1897 |                 rows[3][0] += rows[0].dot(t);
     |                 --------------^^^^----------
     |                 |             |
     |                 |             immutable borrow occurs here
     |                 mutable borrow occurs here
     |                 mutable borrow later used here
...
3952 |     mat_declare_modules!{}
     |     ---------------------- in this macro invocation
```

This is a known issue on the Vek crate, and when it is fixed, we should bump Vek to the fixed version.
The issue: https://github.com/yoanlcq/vek/issues/25

Story points: 1.0
Gitlab CI runner paradigm

So there is a rather large issue with how Gilab CI fundamentally works. Since MRs originate from the contributor's repo, Gitlab CI is run from their repo as well. This means that unless it is specially configured on their end, they will be making use of shared runners for the entirety of the MR, and only when they merge to master will their code be verified by the main repo's CI.

This has always been an issue I think. As you can see [here](https://gitlab.com/zesterer/fresh/-/jobs/200371247), at the top it is using `docker-auto-scale ed2dce3a`, which is a shared runner, not our runner. This means much longer build times, as it has to compile without the cache our runners have.

Gitlab has known about this problem with their paradigm for a bit, but they haven't come up with a good solution yet. You can see the current status here,
https://gitlab.com/gitlab-org/gitlab-ce/issues/21991

Currently, I see a few options.

1. Give instructions to all contributors on how to disable shared runners, and enable ours. This solution is mediocre, as it has a few downsides,
- Getting users to go through the process could be a hassle on the debugging side if something goes wrong
- This is assuming that each contributor has an up to date version of `gitlab-ci.yaml`. If they don't, then they won't be running the same CI as the main repo, which could lead to issues after merging.

2. Get contributors to make branches and work on master. Again, a mediocre solution, but I think it has more positives than negatives.

|       Pros;
- CI on MRs will always be the same
- People can see what branches and code is being worked on

|       Cons;
- Lots of branches could clutter up the repo
- Need to give developer access to everyone who wants to work on Veloren

I haven't found any more solutions, but I'll keep reading about what other companies have done.

Story points: 3.0
Don't create a new specs dispatcher every frame

https://gitlab.com/veloren/veloren/blob/9dd6a9595331893b8d96fb6761cf674fe64f86c4/common/src/state.rs#L206-210

`build()`ing a dispatcher creates a new thread pool with a number of threads every single tick. On Windows, thread creation is a fair bit slower, which impacts performance a lot. The dispatcher should only be created once, either by passing it to `tick` or by keeping it in a (thread local?) static.

Story points: 1.0
Create a login server

Right now, anyone can log in with any username. There is no verification done to make sure a malicious actor doesn't try to impersonate someone. Right now this isn't really a problem, but as our playerbase grows and world state starts getting stored, it will become an issue.

The login server should be separate from the game server. This will enable a central authentication server. A central authentication server will let people use one username in all game servers that subscribe to it. 

To store passwords, we should use the `ring` crate's pbkf2 implementation to hash the passwords. [More info here.](https://briansmith.org/rustdoc/ring/pbkdf2/index.html)

There should still be an option to run servers with no authentication being performed for basic servers run for small groups.

~server ~networking

Story points: 10.0
Generate help text from keybindings

In `voxygen/src/hud.mod.rs`
Currently this:
```rs
Text::new(
       "Tab = Free Cursor       \n\
        Esc = Open/Close Menus  \n\
        \n\
        F1 = Toggle this Window \n\
        F2 = Toggle Interface   \n\
        \n\
        Enter = Open Chat       \n\
        Mouse Wheel = Scroll Chat\n\
        \n\
        M = Map                 \n\
        B = Bag                 \n\
        L = Quest-Log           \n\
        C = Character Window    \n\
        O = Social              \n\
        P = Spellbook           \n\
        N = Settings",
)
```

Story points: 1.0
Add client states

To simplify switching between multiple client states, like Disconnected (no connection), Connected (Doesn't have access to the world), Spectator (Can look at the world) and Character (Has a character in the world) a state machine should be implemented.

Proposed implementation:
When the client sends the `RequestState` message to the server, it answers with a `StateAnswer` message, which is a `Result<ClientState, (RequestStateError, ClientState)>`.

For events where the client has to provide some information in order to change state, like when connecting the Player struct which contains the player's name, a special RequestState message should be sent, in this case `Connect { player: Player} `. The server should still answer with a `StateAnswer`.

Story points: 2.0
CI: Folder font can't be found in voxygen.

```bash
$ rm -r -f nightly
$ mkdir nightly
$ cp target/debug/veloren-server-cli nightly
$ cp target/debug/veloren-voxygen nightly
$ cp -r assets nightly/
$ cp -r voxygen/shaders nightly/
$ cp -r voxygen/fonts nightly/
cp: cannot stat 'voxygen/fonts': No such file or directory
ERROR: Job failed: exit status 1
```

Story points: 1.0
Add support for controllers

The current code relies on a keyboard for input. Gamepads would be nice to have! Preferably both should work at the same time. [See this article](https://www.gamasutra.com/blogs/LarsDoucet/20170125/289904/The_Steam_Controller_Configurators_Untapped_Power.php) for why. This will touch on the input system and the settings system implemented in !30

Story points: 2.0
Users timeout when connecting to the server using a debug build

Cargo defaults to building Debug builds. Some individuals compiling and connecting for the first time will run into a client / server timeout while transitioning from the Login to the Character Selection screen.

The bug is that the UI images for character selection are loaded on the main event loop. This halts client/server polling so the server times out and disconnects the client.

Order of events:
*  voxygen/src/menu/main/mod.rs: `MainMenuState::play` is handling UI events. As the player clicks Login, `CharSelectionState::new` is called to initialize the character selection UI. This is called within the UI event handling.
*  voxygen/src/menu/char_selection/mod.rs: `CharSelectionState::new` calls `CharSelectionUi::new`.
*  voxygen/src/menu/char_selection/ui.rs: `CharSelectionUi::new` calls `Imgs::new`.
*  voxygen/src/menu/char_selection/ui.rs: `Imgs::new` loads 61 images. This takes some time, holding up the UI event loop and preventing the client from sending keep-alives.

Possible solution:
*  `CharSelectionState::play` handles this new window's event loop. Add code to the beginning to spawn the `CharSelectionUi::new` logic in a new thread (recommend rename of this method from new to load_async?). While CharSelectionUi is loading, alternate between polling it state for completion and handling the client. Once loading is complete, continue into the current event loop.

Story points: 2.0
Make the camera change aspect ratio upon window resize

The functionality already exists, we just need to connect the two things up.

There's the handle_input_event method in `voxygen/src/scene/mod.rs`, and also the set_aspect_ratio method in `voxygen/src/scene/camera.rs`.

It should be a matter of just adding an extra match branch. Info about the `Event` type is in `voxygen/src/window.rs`

Story points: 1.0
Use non-linear interpolation to smooth server/client physics prediction

This might need an architectural change in Sphynx, such as allowing it to differentiate between components that need sending every frame and those that do not. We need to find a way to differentiate between the server "forcing" a client's physic attributes (such as during teleportation) and requesting that they be updated. The old engine solved this by having a way of forcing component updates vs suggesting them. Ideally, we'd have something similar in Sphynx.

Story points: 5.0
Better README and Contrinbution Guide

Hello, as a new developer I would like a some indication to make way around the code faster.
This should include a better readme indicating how to build Veloren (f.e. overriding the nightly toolchain), which part of the code does what (to run the game and experiment, should I first run the server-cli?).

Making this should make contribution more easy for new developer.

Story points: 1.0
Multiple Targets (lp:#956560)

[Original report](https://bugs.launchpad.net/bugs/956560) created by **Thomas (th-h)**
```
I would consider it very usefull to improve duplicity in a way that it can
handle multiple backup targets.

E.G. if i have 500 Gigs of data to backup and i need to distribute the
backup to 5 different Webdav Accounts it would be very nice if i could tell
duplicity the upper limit for each account and than duplicity will
automaticly distribute the slices over several hosts. In my example i would
use 1 Gig Slice size and would than tell duplicity to write the first 100
slices to webdav account a and the second 100 slices to account b and so
on...
```

Story points: 18.0
sftp backend should properly report write failure when destination full (lp:#936770)

[Original report](https://bugs.launchpad.net/bugs/936770) created by **Olivier Berger (oberger)**
```
When the remote destination is full, the sftp backend will try writing the
(usually big) file, then detect a failure, and report, but in a way that is
not really obvious (see http://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=659008#10 for instance).

I guess that before copying a big file to the destination, there may be a
way to check for empty space there, and doing the calculation for potential
problems... provided that no better diagnostic (like "file system full")
can be otained at failure time, then maybe a warning about checking disk
space could be issued, then.

Of course, there may be simultaneous other programs changing the
destination usage, so this would just be a hint for the user, if there's no
such way as getting a proper "file system full" through paramiko and sftp
;-)

Hope this helps.

Thanks in advance.
```

Story points: 6.0
Option to skip existing files with restore action and --force (lp:#935644)

[Original report](https://bugs.launchpad.net/bugs/935644) created by **Christopher Foo (chris.foo)**
```
I decided to restore to another external hdd and left it overnight. I
checked this morning and I got hit by bug LP#862485 and bug LP#749876.
Attempting to restore again will give the usual

 Restore destination directory [blahblah] already exists.
 Will not overwrite.

so I tried using the --force argument as well. Unfortunatly, that means it
has to do restore everything again..

So, it would be nice if there was an option that proceeds with restoring
into an existing directory but skips existing files in the destination.

Duplicity version: rev 831 from duplicity-0.6-series + hax patch from
LP#662442
Python version: Python 2.7.2+
OS Distro and version: ubuntu 11.10
Type of target filesystem: ntfs
Command: PYTHONPATH=. bin/duplicity restore
file:///media/CHFOO2/backups/backups-laptop /media/HP\
SimpleSave/chris/restore/ --verbosity info --force

(I tried looking at the source code to see if I can write up a quick hax
but it looks like theres too many deltrees() in the logic.. )
```

Story points: 6.0
Inconsistent Verify: Invalid data - SHA1 hash mismatch : ErrorReturnCode=21 (lp:#930866)

[Original report](https://bugs.launchpad.net/bugs/930866) created by **Rodrigo Alvarez (rodrigo-alvarez-i)**
```
Short story:

When I run duplicity in verify mode on a given set, it sometimes passes,
and it sometimes fails with reporting:
Invalid data - SHA1 hash mismatch for file:
 SOME_VOLUME.difftar.gpg
 Calculated hash: SOME_HASH
 Manifest hash: ANOTHER_HASH

If I run it again, SOME_VOLUME gets through and ANOTHER_VOLUME reports the
error.   If I restart the server, then verify passes (sometimes).

Yes, the Hard drive where the volumes are stored is healthy (as reported by
SMART) and when diff(ed) with its off-site mirror reports no differences.

The details:
I have several backup sets {Projects, Documents, Code, etc...} on Ubuntu
10.04 which I backup with duplicity 0.6.17 to an internal hard drive--the
primary backup target.

Once a month I run duplicity in verify mode to make sure that my primary
backup is still a backup.  This month two sets failed.  This was not a
problem as have an offsite mirror that was synced 15 days ago.   I ran
`diff primary_backup mirror_backup` and the supposedly corrupt volumes were
identical; as expected, the only differences where the backup volumes
generated during the last 15 days.  Weird, right?   So I run duplicity
verify on the primary_target and another volume-deeper in the set-reports a
hash mismatch.  Weirder, right? Now i run duplicity verify on the mirror:
it passes.

Somehow my primary backup got messes up, right? I clobber it and replace it
with its older mirror and run duplicity verify to make sure all is good.
It fails, the primary_backup fails.  I run another `diff primary_backup
mirror_backup` and now they are identical.  Ok, the drive that stores the
primary_backup is failing, but wait: SMART long test says it is perfectly
healthy and has no bad blocks or read/write errors in its entire history (I
run these once a week).   I delete duplicity cache, and temp files and
rerun duplicity verify on primary_target and it fails: a new volume with
bad hash.  Now I go brute force and run duplicity verify 10 times and each
time a different volume shows a bad hash. Sometime volume 3, somtimes
volume 1000.   What?

I now reboot the server--a few days have gone by and I've spent about 5 hrs
looking at this--and I run duplicity verify on the primary_backup and it
passess.   What? This is the exact data that had failed 10 times?
Seriously?   Nevermind, this is what I expected and how things should be.
Just to make sure all is good I rerun duplicity verify on all my sets and
wait.   What? Now two new sets report errors but the ones that originaly
reported errors are fine.

Help!  Can we trust verify?   Why does it fail sometime and pass other
times?   Can it be the hard drive even if diff  and SMART pass? Is there a
bug in duplicity or gpg?
```

Story points: 22.0
Backup restart/resume marks files deleted (lp:#914777)

[Original report](https://bugs.launchpad.net/bugs/914777) created by **krbvroc1 (kbass)**
```
Duplicity 0.6.17
Python 2.4.3
Centos 5.6
Target is custom backend

Summary: When a RESTART occurs, all files prior to the restart will be
marked deleted and re-backed up in subsequent backups

To reproduce:

1) Kick off a full backup. Wait until several volumes have been uploaded
and then hit Ctrl-C during the upload of a volume. You will probably have
to hit Ctrl-C five times to abort each of the five retry attempts. The goal
is to exit back to the shell.

2) Run the same backup command and let it complete. Duplicity will print
something like
"RESTART: Volumes 2 to 3 failed to upload before termination.
         Restarting backup at volume 2."

At this point you are supposed to have a completed full backup set.

3) Run the same backup command and let it complete. This will be your first
incremental. All files located in volumes prior to the RESTART will be
marked as deleted.

4) Run the same backup command and let it complete. This will be your
second incremental. All files marked deleted will be backed up again and
marked deleted again.
```

Story points: 26.0
Successful but incomplete full backup (lp:#914504)

[Original report](https://bugs.launchpad.net/bugs/914504) created by **Alphazo (alphazo)**
```
I started an initial full backup on 408GB of photos and videos using the
configuration and duply version found below. Source and destination are
found on the same local system so encryption was disabled. The only
significant change I applied in the configuration was the volume size of
3.5GB rather than the default 25MB.
Initial backup went fine (but took a very long time) with no error
reported. I then started a second backup of the same data set which has not
been modified at all. The incremental backup took longer than expected and
86GB could be found in the incremental data set.
Listing (duply list) and comparing the files in the initial full backup and
incremental one revealed that the full backup stopped in the middle of a
directory toward the end. The incremental backup just finished what should
have been done by the initial full backup.
For information I used the exact same configuration on a different data set
that are not photos & videos (only 240GB) and the initial full backup went
fine and was complete. Incremental backup was very fast with no data added.

Has anyone experience such incomplete backup? Could that be linked to the
3.5GB volume size?

GPG_KEY='disabled'
GPG_PW='_GPG_PASSWORD_'
TARGET='file:///mnt/user/BACKUPS/snapshots/photos-backup'
SOURCE='/mnt/user/PHOTOS'
MAX_AGE=6M
VOLSIZE=3500
DUPL_PARAMS="$DUPL_PARAMS --volsize $VOLSIZE "
TEMP_DIR=/mnt/user/duplicity-cache_tmp/tmp
ARCH_DIR=/mnt/user/duplicity-cache_tmp/.cache


duply 1.5.5.4
duplicity 0.6.17
python 2.6.4
gpg 1.4.10
awk 'GNU Awk 3.1.8'
bash '4.1.7(2)
```

Story points: 18.0
Duplicity 0.6.17 Hardy PPA package cannot be installed (lp:#913650)

[Original report](https://bugs.launchpad.net/bugs/913650) created by **goofrider (goofrider)**
```
When installing Duplicity 0.6.17 Hardy package from PPA, I encountered the
following error:

===============
The following packages have unmet dependencies:
  duplicity: Depends: python-pexpect (>= 2.3-1) but 2.1-1build1 is to be
installed
E: Broken packages
===============

Manually upgrading python-pexpect to 2.3-1 caused the following error:

===============
Setting up python2.4 (2.4.5-1ubuntu4) ...

Setting up duplicity (0.6.17-0ubuntu0ppa9~hardy1) ...
Compiling /usr/lib/python2.4/site-
packages/duplicity/backends/_boto_multi.py ...
  File "/usr/lib/python2.4/site-
packages/duplicity/backends/_boto_multi.py", line 405
    with FileChunkIO(filename, 'r', offset=offset * bytes, bytes=bytes) as
fd:
                   ^
SyntaxError: invalid syntax

Compiling /usr/lib/python2.4/site-packages/duplicity/filechunkio.py ...
  File "/usr/lib/python2.4/site-packages/duplicity/filechunkio.py", line 80
    except TypeError as err:
                      ^
SyntaxError: invalid syntax

pycentral: pycentral pkginstall: error byte-compiling files (48)
pycentral pkginstall: error byte-compiling files (48)
dpkg: error processing duplicity (--configure):
 subprocess post-installation script returned error exit status 1
Processing triggers for libc6 ...
ldconfig deferred processing now taking place
Errors were encountered while processing:
 duplicity
E: Sub-process /usr/bin/dpkg returned an error code (1)
===============

I could try upgrade to newer version of Python (>=2.6), but it warns me
about needing to upgrade libc6 so I decided not to risk breaking entire
system and stick with Python2.4.

In the end I have to revert back to an older version of Duplicity from
Debian Lenny
```
Original tags: hardy

Story points: 10.0
Prompts for passphrase for key which doesn't require one (lp:#913375)

[Original report](https://bugs.launchpad.net/bugs/913375) created by **Adam Porter (alphapapa)**
```
I've been using Duplicity for several years off and on.  I just tried
0.6.15 and 0.6.17.  I use a key with an empty passphrase to sign my
backups, and I use symmetric encryption with an exported passphrase.

Both 0.6.15 and 06.17 prompt for a passphrase for my signing key, but when
I hit enter without typing anything, it works.  Previous versions didn't
prompt for the passphrase.

Using Kubuntu Oneiric.
```

Story points: 6.0
Crash while doing full backup (lp:#910186)

[Original report](https://bugs.launchpad.net/bugs/910186) created by **Milan Bouchet-Valat (nalimilan)**
```
I just got this crash while doing a full backup. Happened about 30 minutes
after I started it...

This looks very similar to bug 229457, but it was fixed years ago.

I'm using duplicity 0.6.14 on Fedora 15.

$ duplicity full /home/milan  file:///media/VERBATIM/Sauvegardes/milan.new
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
GnuPG passphrase:
Retype passphrase to confirm:
Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1311, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1304, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1274, in main
    full_backup(col_stats)
  File "/usr/bin/duplicity", line 447, in full_backup
    globals.backend)
  File "/usr/bin/duplicity", line 325, in write_multivol
    globals.gpg_profile, globals.volsize)
  File "/usr/lib64/python2.7/site-packages/duplicity/gpg.py", line 307, in
GPGWriteFile
    top_off(target_size - cursize, file)
  File "/usr/lib64/python2.7/site-packages/duplicity/gpg.py", line 280, in
top_off
    assert misc.copyfileobj(incompressible_fp, file.gpg_input, bytes) ==
bytes
  File "/usr/lib64/python2.7/site-packages/duplicity/misc.py", line 180, in
copyfileobj
    outfp.write(buf)
IOError: [Errno 32] Broken pipe
```

Story points: 6.0