Assignment client won't save resources (work-around found)


#1

Everything is working well now on my Debian/Jess box, except this one last issue which has me completely flummoxed!

The assignment-client is reporting in its console that it is:

[entity-server] pruning Octree before saving...
[entity-server] DONE pruning Octree before saving...
[entity-server] saving Octree to file  "resources/models.svo" ...
[entity-server] DONE saving Octree to file...

But the files are not being written. I am expecting them in the same folder as the assignment-client executable under a directory ‘resources’ (which it also isn’t creating if needed). This folder has correct write permissions.

I have an old version of these files from a few days back when I was still experimenting with the compile, so I assume it was working on my system then (no GIT updates have been made since then either).

I wiped out my entire tree and went back to the start using OmegaHerron’s Ubuntu instructions more carefully than ever before :wink: making sure I had equal-or-better versions of everything (upgraded the TTB to 2.3 from intel as Debian still has 2.2 in the repo. Everything else is equal to or greater point version than required - but correct major version).

Sooooooooo close! :smile:


#3

I noticed in the AS debug output this line:

[entity-server] Requesting domain-server settings at "http://localhost:40100/settings.json?type=6"

Having already established that http://localhost:40100/settings is not returning a valid html file to a browser on my system (link), could it be that the entity server is getting an invalid response for where/what/how to store resulting in it silently dumping the data into a black hole rather than saving it?


#4

@b having got a workaround for the web interface access, I was able to set he path to save models.svo.

I did have to make it an absolute path:

/opt/hifi/assignment-client/resources/models.svo

to get it to work. But the file is now there (along with metavoxels.dat)

I set an absolute path to /opt/hifi/assignment-client/resources/voxels.svo while I was there, just in case!

And my entities appear to be persisting across server restarts now!!

On to learning the scripting APIs now :smiley:


#5

The saving of the SVO shouldn’t fail if there are any problems with the webserver piece of the domain-server.

AFAIK right now we aren’t creating that resources folder for you if it doesn’t exist. Did it exist beside the executable when you were testing (I think you mentioned it was there with the correct write permissions)?


#6

Yes, it was there in the same folder as the executable with good perms.


#7

I dont get a metavoxels.dat file in windows. Think there’s more wrong https://alphas.highfidelity.io/t/no-metavoxels-dat-after-importing-heightfield-map/1243


#8

I recall someone mentioning a few days ago that for some reason metavoxels.dat was being stored in a nearby subfolder.