martin

The format for the models was expanded in several ways, but the underlying structure remains the same. The new keywords mostly have something to do with the support for shaders. We shall publish the full specification sometime in the future, along with other modding information.

I must say that I was taken aback by strict condemnation. I am not going to deny it: obviously the game has bugs, otherwise we wouldn't be working on a patch. Nor I am going to explain why it is so, it was pointed out even in this thread, and in many other places besides it. Suffice to say that I am actually quite happy about the game we shipped, despite the bugs. Our choice was either fewer features and fewer bugs or more features and more bugs, we chose the latter, reasoning that the bugs can be fixed, but no feature can be added later in a patch. In ideal world we would have all the features and no bugs, but in such a world Cenega would have to have in excess of 200k preorders. You might say that we should be more careful about planning the project and promising features, and I can but wholeheartedly agree with you. In an ideal world, we would have a complete game design before the first line of code is written, but this would add another year to development time. Back on topic of the modding tools. I might have promised something along the lines you suggest; I don't remember and am in no mind to search out. Obviously, this was the impression I made. The reality is that, as opposed to Aftermath, our internal tools were much more sophisticated and made designing the game much easier (i.e. possible). However, they are also complex and difficult to set up. I have no problem with releasing the toolkit 'as is': PostgreSQL and ActivePerl are OpenSource projects, everybody can download and install them. Everybody has Excel. Once you manage to get it up and running, you will find it is easier to make modifications: add new items, modify their properties, models, etc. than it was in Aftermath. It was only my naive assumption that there are people in the modding community who would be interested in evolving this toolkit. But I am really sorry if you feel that we betrayed your trust. The modding tools will be released, they will be more powerful; it is yet to be seen how easy to use they will be and when they will be available.

Please rest assured there will be none. We have no time for that, anyway. Mike is right, the system works with designers creating the layout of the mision (we call it "ground"), then specifying "slots" in the ground, for example: "here is slot 'Factory 1' and here 'Garage 2'". Then they go on creating 'Factory 1'. It can have several different outer walls (all of them of the same size, of course) and different possible arrangements of rooms inside.

The polygon count really depends on the target hardware. The models in UFOAM certainly have fewer polygons but on a modern video card, 1k- polygon count is not a problem. The plugin for MilkShape was not written by us and I really don't know anything about the program. For a long time, I am suggesting that the best way forward for modding community would be to have a converter from some familiar game format, e.g. Quake II. Then everybody could use GMax. At present, we don't have resources to write such a converter ourselves; we might think about the problem again when Aftershock is released (the data format is very similar to Aftermath).

What do you mean? There is not a single mention of "consumism" or anything similar on the whole blog. And, BTW, why did you not leave the comment on the blog?

In Aftershock, our approach to configuration data is slightly different. We still use Excel for editing data, but we export them in a sort of pseudo-XML and then import them in a database (Postgres) and check them for internal consistency (this was a nightmare in Aftermath, to make sure that identifiers in one file match those in other files). The database then exports the data in a format quite similar to the one we had in Aftermath and these are in turn read by the game. We would be probably willing to publish the SQL data from the database once the game is released if it was felt that it can help modding (from the preceding discussion I get the feeling it wouldn't); to store the data for one weapon in one file is an idea we can consider but I am afraid it will run into difficulties. The configuration data is interconnected: a weapon is referred in one table, where it is defined what it costs to produce, which building it is produced in, etc. (economic data, pertains to all equipment items), another table defines its caliber, reload time, etc. (unique information for each missile weapon), yet another table defines its range, accuracy, etc. for various modes of fire (multiple information for each missile weapon) -- it is difficult to isolate it. Take for example the relationship item-factory: we cannot have a single file for each weapon and single file for each building, because they are referring to each other. We could of course have a single file for what is now a single line in a table, but this would mean thousands of tiny files.

Actually, I think Sigget may be right. The error you getting is actually generated by the InstallShield and it is related to the way InstallShield (and Windows) store the information about the installed software. You have to look at the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and you will se lot of entries with long numbers. These are GUIDs of your applications. The Aftermath GUID is normally 3699BC50-DA7B-4DA7-BB43-2981C9178FAD (all versions but Polish) so you should check if it is present there. If it is, you should inspect the information contained there and verify if the files being referred there actually exist. If it is not, there is the problem with the installation of the game. You can also contact our technical support at support@altarinteractive.com I am sorry for your problems.

Actually, it is not possible to make a plugin for G-Max just like that. You have to buy a license from Discreet and this costs about $30k, so that's why only some games do it. It would be however possible to do this in two steps: you could use some official plugin for G-Max, e.g. Tempest that uses an open format (Quake II in this case) and then write a converter from that format into our format. I know this is not the most straightforward solution but this is a solution that has no legal problems.

Congratulations, sigget, on extremely cool pieces of software. The Total Commander plugin is very useful, we're going to use it ourselves. And the texture maker -- I think I can appreciate it is not a trivial problem. We had the higher resoltuion textures as well but in the end we included such as would work on lower range of video cards as well (the original minimum specs were 32MB video RAM).

I didn't see the mod, so I don't know what you have really changed. You have to add the weapon to the listofweapon.txt, add a helper into listofcreature.txt and modify listofai.txt -- still there is no guarantee it is going to work, many things with regards to enemy units are simply hardcoded.

That's a very good question and actually we are going to use some sort of database engine in our next project. However, reading text files is much simpler to implement and we didn't want to spend time on developing on something more sophisticated.

Yes, this is going to be part of the modding tools package: we'll provide a convertor from binary to human-readable format of 3d models and specifications for their content. Yes, you are right. The problem is with the video files (*.bik). These are read directly from gamedata file and cannot be put in the patch files. Martin

We are now preparing our modding tools for release and part of it is the description of the configuration files. We are going to include weapons (incl. magazines and armor), Research, Creatures (incl. equipment sets, times and animations), AI, People (incl. heads and exp. levels), Difficulty levels, Bases, Trainings. That includes the following files: \tactical\configs\equipsets\*.* \tactical\configs\game\listofai.txt \tactical\configs\game\listofammo.txt \tactical\configs\game\listofanim_hum.txt \tactical\configs\game\listofanim_mut.txt \tactical\configs\game\listofanim_ret.txt \tactical\configs\game\listofanim_weapons.txt \tactical\configs\game\listofarmor.txt \tactical\configs\game\listofcreature.txt \tactical\configs\game\listofenemy.txt \tactical\configs\game\listofexplevels.txt \tactical\configs\game\listofhead.txt \tactical\configs\game\listofmagazine.txt \tactical\configs\game\listofshapes.txt \tactical\configs\game\listofskills.txt \tactical\configs\game\listoftimes.txt \tactical\configs\game\listoftrain.txt \tactical\configs\game\listofweapon.txt \tactical\configs\game\tactconfig.txt \strategic\configs\ListOfDIFFICULTY.txt \strategic\configs\r&d\listofobjects.txt \strategic\configs\r&d\listoftech.txt \strategic\configs\r&d\listoftechno.txt \strategic\configs\geosphere\listofbase.txt \strategic\configs\geosphere\basesownership.txt \strategic\configs\game\listofphase_content.txt I wonder if there are any other files that anybody is interested in and that are incomperhensible as they are. Please let me know about it and if modding them makes any sense we shall include them as well. Thank you. Martin

Hello everybody, please let me express our support for mods here. We are really impressed by the level of support and commitment our game receives from people like you. I must say Thank You again. For the distribution of patches: 1. It is even now possible to use the system you suggest. If you create a file named "cfg.vfs" and place it in the same directory where you have gamedata.vfs, the files in the former will be preferred over the files in the latter. This is not an ideal solution (we would like this to be more general, so that you have multiple mod files alongside each other), and that's the reason we didn't make it public sooner, but now, seeing the level of support here, I think even this may be useful. 2. We are working on a collection of modding tools: beside the vfs packer and unpacker, we shall also publish the documentation for the configuration files, the documentation for our propriatary 3D format, a tool for converting binary saved files (mostly 3D models) into text files, and a tool for creating custom missions. 3. There will be also a patch that will make the game support the modding better (allow multiple mod.vfs files, allow loading custom missions). Hope this helps. Martin

Yes, Nikua, the US version is exactly the same as the UK version (and the spelling is American in both, but the voices are English -- I especially that tough Manchester guy pretending he's from Texas). So you need the patch for the version you order from UK and it is the same game you would hopefully be able to buy in USA later.

Actually, I quite like the word Phoenix, and I think it is a very good idea. Now just try to think about an appropriate descriptive word, Phoenix Regiment sounds nice, but at the same time is sounds awfully like something from BattleTech. Keep the suggestions coming, I think we are really getting somewhere here.

I am not quite sure, what is the question... Yet, I'll try to answer. We don't want to use any variant of the story of any part of X-COM series for variety of reasons -- we don't want to be accused of derivativeness, and we don't want to be sued. We are not making an X-COM sequel, period. Whether you or me wish to do so, is beyond the point. Similar reasoning applies to terminology. X-DEF, while nice, we would be reluctant to use for reasons outlined above. By the same token, there will be no "UFOPaedia", etc. Back to Council of Earth -- this is an umbrella organisation trying to manage what is left of Earth. The organisation you are in charge of is technically subordinated to it; it is an elite (as much as possible under the circumstances) group of soldiers tasked with solving the most difficult military problems (and it is currently nameless). CoE are de iure your superiors, but basically they will always follow your "recommendations". CoE are the people who are making the research for you, scouting new soldiers for you, etc.

Actually, we are currently calling the survivors "Council of Earth" (CoE), but this is a work-in-progress monicker only. What do you think about it? Does anybody have a better idea?