|James Wagner (jamesawag)||31.12.2018 11:02|
|# times now GE has broken my maps. tonight it took my i3d file from 60mb to 646 mb in one save. the other night it went from 53mb to 4.5gb? It utterly destroyed another map I was working on. I have back ups but I would love to know why it does this. I am also working on a 4x map I have converted and is almost ready to release. It is also randomly picking something and making it move instead of letting me move around the map to the point i have to move around the map backwards. Anyone else have these issues?
|Bilbo Beutlin (BBeutlin)||31.12.2018 16:34|
|That often happens if you use non-ASCII (eg. language specific) characters or spaces for labels.
Check your i3d in text editor. You should only use in labels charakters 'A-Z', 'a-z', '1-0'(non-leading) and underscore '_'.
Maybe your map can be 'repaired' if you save it once "as binary" and reload.
|James Wagner (jamesawag)||01.01.2019 01:40|
|Yea I know the problem is GE is adding odd stuff like / - # and other characters in. I know the files I brought into the map because I edited them first to make sure they are clean and example is some flowers i brought in. the original file said material="blueflowers" the editor changed it to blueflowers:blueflowers I have just spent the last 5 hours going line by line in my i3d cleaning up stuff GE put in and brought my file size from 649mb to 49mb all from garbage brought in by the editor itself.
|Bilbo Beutlin (BBeutlin)||01.01.2019 03:15|
|No - it's not the GE which wrecks the code.
The main reason is: users with no programming experience tend to name labels in their habitual language. This includes language special characters which the OS inserts as unicode sequence. Depending on system settings eg. UTF-8, UTF-16.
But nearly all programming tools evaluate any character as single char ASCII. So a sequence may be misinterpreted.
Additionally the "space problem". A space is in all programming languages a separator (if not in string). And code parsers do exactly what they are programmed for. They interprete "abc def" as two components "abc" and "def".
This all maybe strange for non-experienced beginners. But it is common in the programmer/developer world.
|James Wagner (jamesawag)||01.01.2019 04:59|
|So what your saying is when i double checked the file before it was imported into my map and the file looks like this
<Material name="flowerclump02" materialId="2543" specularColor="0.0627451 1 0.0392157">
then import it save my map then recheck my fi3d it should say this
<Material name="flowerclump02:flower01_g1" materialId="2543" specularColor="0.0627451 1 0.0392157">
But it is not the editor doing it?
|Bilbo Beutlin (BBeutlin)||01.01.2019 12:45|
|That happens if one of the materials has already a name from 3D editor before (3dsMax, Maya, ..)
But such things should not lead to the effect of enlarged filesize. This is mostly due to xml parser which expects a simple ASCII label and misinterpretes special characters.
|James Wagner (jamesawag)||01.01.2019 16:11|
|So in other words GE 7.1 read it correctly left it as it should be but GE8.1 is misinterpreting it therefore creating a problem that did not exists until the "editor" misinterpreted it. In turn causing other lines to also be misinterpreted and causing it to misinterpret something simple causing possible errors in the text lines that could potentially bloat a maps xml code. Now I sent a 2 i3d files to a friend that has been working for the USAF since the 90s as a programmer he seems to think there is something wrong with what ever program I was using Ie..GE because that should not be happening."
|Bilbo Beutlin (BBeutlin)||01.01.2019 16:56|
|Myself had never trouble with filesize. Neither in GE8 nor in earlier. Maybe because I'm accustomed to write 'proper' syntax due to programming experience.
And most probably it's not the GE wrecking the code, but the xml parser from runtime libraries, usually MS Visual Studio.
Note: Log in to post. Create a new account here.