Editor Troubles

[TheGreatCthulhu]

This question/comment is directed first and foremost to Frictional Games devs, and than also to anyone familiar with the topic.

About the tools: there must be something I'm missing here...
I've used Notepad++ to open some of the files generated by one editor or the other, and to my surprise, some of the resources are defined using the absolute path...


What in the world would cause this - because, unless manually corrected, such files wouldn't work on another person's system.
I'm guessing you guys didn't manually edit all the files shipped with the final game...
So, something must be causing this behavior, and that something is not documented.

Next, when importing COLLADA files, do they need to be textured beforehand, or must not have materials, so that engine-specific format can be applied? The model editor often behaves funny with materials - if I try to assign/change, it appears it works, but then it doesn't show when tested, the path in the file is absolute, and sometimes the map won't load the entity at all. Why? What steps are required to make this work as expected? Dunno, because it's not documented.

If you try to create a "total conversion", you have to deal with a bunch of config file options, most of which are not documented, and when you finally think you figured it out, you start up the game, and it crashes because some resource could not be loaded, and then you realize that you'd have to spend the whole day hoping to guess how the game works internally and what data it looks for to find out where to find stuff it needs just so that you can start up the damned thing, again all because any of it is not documented.
Is it possible for a "total conversion" mod to use both the resources from the original game and the new content?
Has anyone successfully created a total conversion yet?

So basically we are all stuck with custom stories, but there are potential problems even with that if the editors prefer to use absolute paths...
Now, I know that some custom stories have been published - and I tried running a few myself - which means that people were able to create them successfully. Then, why am I seeing this behavior with regard to the editors?
It seems to me that if one wants to create something beyond a simple level or a connected array of them, if anyone wants to go beyond rearranging the premade models and entities, than one must be a psychic and read the minds of the developers, so that one can have a clue how the various parts of the system interact.

Thus, my question is, are there any special requirements which will make the editors behave as expected, and when we may expect all this to be documented in a more organized fashion?

Until then, if any of this is actually written somewhere, where is that metaphorical needle in the haystack?

[Nye]

I appreciate that I'm not directly answering your question. However, the number of full-time employees at Frictional Games you can count on one hand.

There is plenty of scope to go outside the box using the tools provided by Frictional Games. Most games don't offer this kind of facility and a lot of thought and dedication has gone into releasing/patching the tools/creating the wiki pages etc. etc.

I think that what you are asking for is something that would involve rewriting much of the game. Especially with such a small development team, which are already working hard to release their next game, implementing changes to the core of the game wouldn't be in the devs interests, especially as the community for custom stories is relatively small.

If you play around making a custom story, you will see that there is a MASSIVE range of possibilities and that most custom stories stick to only the most basic things. I'm sure if you put your mind to it, you could do nearly anything with the game

[TheGreatCthulhu]

Thanks for the reply.
I have a rather good understanding of what kind of flexibility the game and the tools aim to provide. I'm sorry if the question seems a bit unforgiving - I am aware that Frictional is a small team and can't accomplish every single thing one hopes for; however, to successfully use the tools and the script language, everything has to be documented. I know this takes time, so I'm asking when can this be expected? (If anyone can give an estimate, that is)
The HPL2 scripting language is not that much of a problem, since the functions are mostly listed, with comments where appropriate, and their correct usage and functionality can with little trouble be inferred from the script files that power Amnesia itself, especially if you know a thing or two about programming and application development to start with. It's the editors that give me significant trouble.

So, I'm not asking for anything to be rewritten: I'm asking for more information on how the various components of the system, as it exist now, are intended to be used. I'm under the impression that the team designed the game so that custom stories and "full conversion" mods are a possibility, but that the end result was not extensively tested (which is not unusual - it requires time and other resources that the small team might put to better use). If so, than there may exist some design flaws and other problems that might impact the intended flexibility, and these need to be exposed, in order for all this to work.

Other than that, I'm also interested in why the editors now and then store the path data using an absolute path, and can this be avoided?

P.S. BTW, you said "releasing/patching the tools" - I downloaded the tools from the wiki page, but i didn't notice any patch downloads. Are there any patches?

[Nye]

They released a single patch for Mac/Linux tools

I have no idea how the game works (to the detail you want), I would hope that one of the devs will post here

[Srh420]

the editors lag really bad on my computer and the only editor that will fit my screen is the level editor, cause i can change the resolution.

[TheGreatCthulhu]

I managed to get an answer to some of my questions from Thomas (here):

Thomas said...
About editor paths:

The absolute paths are not a problem. While this should not be the case (most are relative), the engine just uses the paths to pick the correct resource if there are several with the same file name. The engine keeps a list of all files (search paths are in resources.cfg), and can therefor load files even if just the name (no path) is given.

If there are several with the same name it works its way backwards (the folder the actual file is in) and then checks for each identically named files how many directories fit, in the end picking the file which most picks.

Also, I found this at the hpl2 wiki - the 3rd party tools section, under Blender entry:

Important information about images

Textures(.dds, .jpg. tga and other general image formats) and material files(.mat, the engine specific file) - The material file is an XML file that contains information on what images is used in the material to create the texture and other properties. When the game loads a 3D model it searches for the name of the image used as a texture for the model(the .dds etc) and then replaces that name with the extension .mat to know what material file to use. Because of this it is important that the texture used has the same name as the material file, with the exception of the extension.
[emphasis by me]

If any of the members of Frictional happens to read this - if I may suggest something: the above is pretty important engine-related information that should be located in a more appropriate page, instead of just being a side note on the Blender page.

This is somewhat non-standard behavior, but I can see why it was implemented that way - no modifications to the exported COLLADA file are needed.
As a side effect, if one tries to assign an (engine-specific) material file with a name that doesn't adhere to this design, it won't work.

This info probably needs to be put somewhere where it'll be available to anyone...


I'd also like to know more about animations (in case where one wants to create a brand new entity). It seems that the scenario is similar here, but I'm not sure what exactly are the underlying rules. If someone can shed more light on that.
For example, are the *.dae_anim just renamed *.dae files, or there's more to it?

[MrBigzy]

I think the anim files are simply animation files that are exported out of the .dae when you load the model in the modelviewer. Obviously there's no problem then for exporting, but I'm not sure if you can import the animations back into your modeling program unless you have the original model.

The wiki has pretty much all the information you need for all this, even a detailed explanation on exporting collada and such. Yea, there are some things missing, and some things don't have the highest detail possible, but that's what these forums are for I suppose.

[TheGreatCthulhu]

Tnx. What I'm asking is how to import a brand new *.dae file containing an animation without the engine crashing - say, if you want to create a new character.
(And you're right - if you rename a *.dae_anim file back to *.dae, it can be imported into the model editor just fine.)

From the error log and the function call stack (and from the way Amnesia entities are constructed), I can see that Amnesia is basically reusing the COLLADA loader class used in HPL1, so I guess many, if not all, animation-related recommendations from the Penumbra content creation doc apply.

Namely, I find the following to be the most important:

When creating the skeleton for an object then the joints can NOT be rotated. You may only use translations for the initial placement. Rotation may be used in animations as normal though.

This is a bit vague. The grunt model definitely has the bones rotated in it's bind pose - otherwise, the bones couldn't have been aligned to the limbs. Maybe they meant not to rotate them after the skin is applied?

Then there's:

When using skeletal animations make sure that the skeleton root is at the root of the scene. If not, the engine will not find it.

By "root", does they mean that it shouldn't have a parent object, or that the mesh should be linked to it, or both?

This also:

Animation files: These files should contain exactly the same data as the main file except for colliders.

At the moment the engine cannot load animation data alone since it depends on whether the model is skinned or not and the placement of nodes. So the extra animation files must also contain all other data as the main file. However the animation files should not contain physics data like colliders. These should only be in the main file.

I noticed that when the animation is stopped in one of the grunt animation files in model viewer, the grunt assumes the bind pose... Is this pose stored in the file, too? Are there any special conventions, any reserved frames, or something?

In any case, studying the HPL1 implementation of the loader classes might provide some insight, so I'll take a look. But it will take time...
MeshLoaderCollada.h
MeshLoaderCollada.cpp
MeshLoaderColladaLoader.cpp

P.S. Nice job by you and pandemoneus on the wiki.

[MrBigzy]

He did most of the work, I just brought up the idea. D:

Yeah. I'm doing a full conversion soon and I'm going to make my own monster, so I won't really be looking into that until then (in a few weeks, when exams are done).