Good to know.

The program is only there to make it flash its lights. Without it, robot would not do it.

I mean why is iteven executing it, nonsense.

If it´s not meant to move, why is the program called flash and even has it an executed program.

I'll try to write Blender exporter. Doesn't look difficult to make, but there are some incompatibilities to consider.

I think it doesn't move because it's static. But that's just my opinion.

(Bug)The static target at the shooting battle vs. the static target doesn´t move(it executed the program).

More likely they used 3ds format, but then wouldn't they just stick with this format? Especialy if it have a lot of features that .mod doesn't support.

I don't think game support .max files, and I don't think it ever supported it.

But how they loaded model into game then?

Maybe that's the idea! We should resurect debugmode and see how this mode works with saving changes to MOD files? This mode was used for UV mapping etc.

Nothing in ceebot.zip is looking obvious to me.Looks like there's no such thing. Maybe they converted those MAX with y'know - the game itself in debugmode .

Hmm, good question. How did they exported from max to mod? They had some custom script? Is it somewhere?

Hardcoded informations about vertexes for states would have no sense, it would only make them work more then, without any benefits.

Seems like it is kind of hardcoded, at least with regards to texture names and some states

Ooops, I made a mistake. There's indeed a converter, but any_file -> DAT...

I hope there's no such thing like hardcoded informations about vertexes that are responsible for states... Maybe we should analyze original converter MAX -> MOD from ceebot.zip to figure it out?

Ok, I found it. Gonna analyze it.

In Colobot that is

I want to find code responsible for calculations of UV, but I have no idea where to look for it