Jump to content

[SOLVED] Problems archiving core


photo

Recommended Posts

Hello,

 

I'm having a world of trouble trying to archive the core folder for my release. I use the archiver command to package it as so;

 

ung_x86.exe -p ********** -o "C:\Unigine binary SDK\data\core.ung" -d "core"

(where ********** is my password set in the C++ part of the program)

 

Now if I copy across the core folder without archiving it, all works fine. But if I replace it with my core.ung I cannot seem to load all of the core materials. (see log output below)

 

14:30:58 Loading "core/locale/unigine.en" dictionary

14:30:58 Loading "core/materials/default/unigine_post.mat" 20 materials 44 shaders 1ms

14:30:58 Loading "core/materials/default/unigine_render.mat" 40 materials 4666 shaders 16ms

14:30:58 Xml::load(): can't open "core/materials/default/unigine_meshes.mat" file

14:30:58 MaterialManager::load(): can't open "core/materials/default/unigine_meshes.mat" file

14:30:58 Xml::load(): can't open "core/materials/default/unigine_terrains.mat" file

14:30:58 MaterialManager::load(): can't open "core/materials/default/unigine_terrains.mat" file

14:30:58 Loading "core/materials/default/unigine_grass.mat" 1 material 138 shaders 4ms

14:30:58 Loading "core/materials/default/unigine_particles.mat" 1 material 101 shaders 4ms

14:30:58 Loading "core/materials/default/unigine_billboards.mat" 1 material 816 shaders 3ms

14:30:58 Xml::load(): can't open "core/materials/default/unigine_volumes.mat" file

14:30:58 MaterialManager::load(): can't open "core/materials/default/unigine_volumes.mat" file

14:30:58 Xml::load(): can't open "core/materials/default/unigine_guis.mat" file

14:30:58 MaterialManager::load(): can't open "core/materials/default/unigine_guis.mat" file

14:30:58 Loading "core/materials/default/unigine_water.mat" 1 material 205 shaders 34ms

14:30:58 Xml::load(): can't open "core/materials/default/unigine_skies.mat" file

14:30:58 MaterialManager::load(): can't open "core/materials/default/unigine_skies.mat" file

14:30:58 Xml::load(): can't open "core/materials/default/unigine_decals.mat" file

14:30:58 MaterialManager::load(): can't open "core/materials/default/unigine_decals.mat" file

14:30:58 Loading "core/properties/unigine.prop" 2 properties 0ms

 

Can anyone shed a little light on this problem? Thanks

Link to comment
  • 2 weeks later...

Can I please have a solution or a reply of some sort?

 

Alternaively as a short term solution, can we release to customers using an unarchived core or is this against the licencing agreement?

Link to comment

Removing password protection makes no difference, as I found a core.ung in the scratch project which produces the same error for my project when I provide no password in the c++ initialisation. An archive alone will not reproduce this unforunately. The strange thing is that everything works fine when the core folder is unarchived. I was hoping someone may have come accross this before or the Unigine team may have a better idea what might be going wrong from the description, the log and the knowledge of how archives are processed differently from unarchived files and folders. If such is not the case then I'll have to see about providing part of the project somehow for further investigation.

Link to comment

Just blind guessing, but based on your description "only happens in my environment" might be related to some path problems or conflicting parallel installation of different unigine versions or multiple core.ung ?!?

 

Also, have you unpacked the problematic packed core.ung archive and double-checked proper existance of error-logged path/files ?

Link to comment

Thanks for the hints Ulf, I've solved it :) . I had a second system.h script in my files that I forgot I had from a long long time ago when I was tampering about with it. While the core was unarchived it was reading the core system.h, but when it was archived, the old outdated system.h was taking precedence. You are right as some of those materials in the log don't exist in the newer versions of Unigine.

Link to comment

It's good to hear the problem is solved. A small note on this topic.

 

To avoid problems with searching through archives (ung and zip ones) and file packages, there should be no files named in with the same way in the root directory and in one of the subdirectories. Moving a root file to any folder solves the issue.

Link to comment
×
×
  • Create New...