NadeoImporter [update 2019/10/09]

[Fix]

No there are no name limitations, but when you move your files in the file explorer, it's just names, no icons, so it is easy to do mistakes : place icon A in the folder B, etc...
That was a suggestion.

note : this possibility to have duplicate names means that the Id of an object is "thepath+thename", so if you re-arrange your directories later, your map will be broken.

[steeffeen]

okay thanks for the clarification (even though i would prefer that the path would be ignored and the names have to be unique )

any information about the problem with the number of custom blocks in a title pack?

btw: i have troubles with some blocks in the Common folder
a map which has been created before the last update can't be opened anymore
screen 1
while the specified blocks are where they are supposed to be...
screen 2

does anyone have the same problems? (it's working with new maps though)

[darmaya]

@steffeen
1. it's happened to me too, especially when i give objects to test to one of my friend:
he NEVER EVER is able to open the objects EVEN if i gave him all the textures and objects: it seems to ignore it completely and give error.(IN CANYON, not in STADIUM)

the problem of dependancies between Maps and Objects is one of the worst i encountered,
because while we do varius experiments, there is often the need to change your mind, about a texture,a directory location, etc., but there are some rigid dependencies that is extenuating to catch up.

I never discovered a way to fix the problem,
i tried:
1. edit and resave the map - nothing
2. recalculate shadows - nothing
3. emptied the cahce - nothing
4. delete the checksum.txt - nothing
5. eradicate the Blocs and recalculated - nothing
I still have 4-6 titles in this state and i wasn't able to recover.

I'm glad that someone other is impacting in this problem..
GLAD!? WHAT I'm saying!!
Sorry, i'm SORRY, not glad...

2.did you put custom textures in Common?

Do Common was supposed to work with internal textures?

3. there are two way to publish a Title with objects:
No texture-attached: first, you make a Object-Pack, the uses Packed Objects to build the map: in this way the object SHOULD BE self-containing, and you don't need to include the textures in your delivery (never worked for me)
Texture-Attached: when you create the title, ADD ALL THE OBJECTS and TEXTURES ONE BY ONE (editing the xml;): in this case, you will have a Title that SEEMS to have the textures included (it is heavy in MB), but is not, you have to download the textures apart, as i've done in my only WORKING O-Title (title wit objects)
THIS IS WEIRD, because 1 you give away the texture 2 is heavy 3 the player got numbers of directory and unccordinated icons that he can't move, otherwise anything go messy.

O gosh!

[steeffeen]

wow that sounds even worse than on my end
i haven't had these problems with the textures yet..
the way i was doing it was just included each folder containing the custom blocks (textures should be included automatically) and it worked so far
that the map can't be opened anymore seems to be a problem caused by the update if you ask me
before the update it could be opened without any problems (the map was built by a friend of mine and i was able to open it on my computer)

[darmaya]

the way i was doing it was just included each folder containing the custom blocks (textures should be included automatically) and it worked so far

what? you "just included each folder?" how!
what it's mean "include each folder" and "textures should be included automatically"?
this is the bit code i ever used: here you have to specify THE WHOLE FILE PATH, not just the folder; and you have to include the textures, otherwirse it do not work:

Code: Select all

<files>
		<file name="Blocks\Canyon\MIB\Snowfield_snow_grass.ObjectInfo.gbx" public="true" internal="false" />
		<file name="Blocks\Canyon\MIB\Texture\snow_D.dds" public="true" internal="false" />
		<file name="Blocks\Canyon\MIB\Texture\snow_N.dds" public="true" internal="false" />
		<file name="Blocks\Canyon\MIB\Texture\snow_S.dds" public="true" internal="false" />
	</files>

steff, i beg your pardon but you travel as a sky-rocket,
while i'm worming for months

that the map can't be opened anymore seems to be a problem caused by the update if you ask me
before the update it could be opened without any problems (the map was built by a friend of mine and i was able to open it on my computer)

maybe...

Anyway, i feel confortable naming the object as the _TDSN_Texture_PhisicalID.fbx,
it help me to remember the texture i used...

[steeffeen]

steff, i beg your pardon but you travel as a sky-rocket,
while i'm worming for months

haha sorry for discouraging you ^^

here you got an extract of my title pack xml

Code: Select all

<files>
	<file name="Maps\MatchSettings\SMStormSpeedBall.txt" public="false" internal="false" />
</files>
<folders>
	<folder name="Blocks\Storm\Wood\" public="false" internal="false" />
	<folder name="Blocks\Storm\Forge\" public="false" internal="false" />
	<folder name="Blocks\Common\MiscProps\" public="false" internal="false" />
	<folder name="Blocks\Storm\Metal\" public="false" internal="false" />
</folders>

the .fbx files are located in these folders and the textures get included automatically because they are referenced in the files

[darmaya]

Ok i swear,
i'll stop to bugging you
but WHERE do you went to know about "folder" instead of "files"???
I never knowed such thing...
i feel like an idiot...

[steeffeen]

hehe
i'm not sure if i read about it or if i just found it in the xml, i think the second ^^

[maxi031]

Hey guys i am having some troubles with light again.
Heres the picture:
https://dl.dropboxusercontent.com/u/117 ... Shot21.jpg

I dont know how to remove that light line in the corner.
I checked lightmap uws and they looks ok. Also smoothing groups are ok.
Whole object is single mesh(no holes).
I really don't have idea what is going on there.
Does anyone know why is this happening?
Thanks

[Fix]

It's part a limitation of the way light is computed, and part from your datas.
You can see that your lightmap looks like saw teeth, it's because your UV2 for this ground rectangular part are in diagonal (I think), and it's always better to be ailgned with horizontal and vertical lines, because pixels are square.
Also, the engine has some precision limitations, visible in concavities where the outside can be seen sometimes, very visible in contrasted areas (dark indoors) and with low resolution lightmaps (the smaller the resolution the bigger these precision artifacts).

By the way, do you have a face on the outside of this tunnel, or is the back of the tunnell roof's face seeing the sky? this is another source of light going where you don't want to.