Second Modding Summit - 03/03/2014

[Hazbones]

I would love to hear someone ask CA how the heck we can remove the insta-transports for armies on the campaign map. Can we please add that to the list because it severely kills the game for me.

EDIT: Actually, who ever goes to this meeting needs to ask in general, how to eliminate virtually every change they did from Shogun 2 to Rome 2. That would be greaaat... M'kay?

[wangrin]

Some news from forums.totalwar.com :

La date exacte n'a pas encore été confirmée. Il y a du mouvement concernant les outils pour la création de mods et nous devrions être en mesure de publier plus d'informations à ce sujet sous peu.

link : Second événement Modding Summit

Translation :
The exact date is not yet confirmed. There's movement regarding tools to create mods and we should be able to release more informations about this topic soon.

[uanime5]

Some information regarding how to change the area the radar covers on the campaign map in Shogun 2 would be helpful. At present even if you make the map bigger the radar remains the same size, so all the icons are in the wrong place.

[wangrin]

Post #3 (TW:S2 ASSEMBLY KIT FEEDBACK & QUESTIONS) updated
Added :

• CS2 EXPORTER & RAW MODELS - #7 : {campaign map} modding radar map coverage
• OTHERS - #4: Animation exporter

[Kurisu Paifuaa]

I'd like to propose that we ask about the nature of the changes to the variant mesh system. It's already been brought up in threads where developers (Jack) have posted, but without reply thus far.

Specifically, why are we seeing model part variance limited to a maximum of 5 entries per slot in a variant_mesh definition? CA's own unit and model part definition files are not structured properly for this change. Usage of duplicate entries (to control probability) have many current definitions with up to 25 or so entries per slot. As a result, many model part and color variants are not used by the game (even at the maximum detail setting).

It is possible to work around this limitation by re-structuring the definitions, but what I'd like to know is...

1. Is this a deliberate change?

2. If so, do they (CA) intend to correct their definition files to conform to this new standard?

3. How should we proceed when structuring our own definitions? Will these changes to the variant system evolve further?


I think this affects everyone working on unit design projects, color modification or anything related to the variant system. Personally, I have plans to develop a restoration mod for unit variety (vanilla unit and parts definitions) should this turn out to be a permanent condition. The intention would be to serve as a base mod and/or modder's resource until we have full coverage as far as more focused unit design projects are concerned. Obviously, I'd rather not put the effort into that if future development alters the system further or restores the original level of detail.

Who's attending, by the way?

[Destin Faroda]

Shogun 2:
- The unit editor loves to crash for no apparent reason when I try to edit a unit (via the editor window with colours). Can they fix it?
- Both the BAI and CAI are absolutely stupid. We need access to fix it (AI needs to recognize winter attrition and longer winters in games with 12 turns per year)
- Can something be done about the limited building slots? 6 is ridiculously low. Give us at least 10!
- The sound bug is inexcusable and needs to be fixed.
- Can we have buttons for unused abilities like column formation, earthworks and so on?

UPDATE:
- GIVE US PROPER, READABLE CRASHLOGS FOR WARSCAPE GAMES!!!

[HunterWolf]

We would like to get efficient material editor, so, we will be able to tune and assemble materials inside Assembly Кит. We need to import all open file formats in it, iow rigged mesh in fbx format and textures in dds format and tweak material inside editor, if you created application for this shading for Dx Here is example of such program http://forums.taleworlds.com/index.p...c,72279.0.html
And the most important thing – expanded documentation about file formats is necessary. Now we have to use “try and see” method.

[yukishiro1]

My #1 request is a mod tool that handles the settlement_growth tables so we can finally put some damn walls on Syracuse. CA must have a mod tool for it themselves, there's no way they manually deal with all those coordinate entries.

[Kurisu Paifuaa]

I'd like to propose that we ask about the nature of the changes to the variant mesh system. It's already been brought up in threads where developers (Jack) have posted, but without reply thus far.

Specifically, why are we seeing model part variance limited to a maximum of 5 entries per slot in a variant_mesh definition? CA's own unit and model part definition files are not structured properly for this change. Usage of duplicate entries (to control probability) have many current definitions with up to 25 or so entries per slot. As a result, many model part and color variants are not used by the game (even at the maximum detail setting).

It is possible to work around this limitation by re-structuring the definitions, but what I'd like to know is...

1. Is this a deliberate change?

2. If so, do they (CA) intend to correct their definition files to conform to this new standard?

3. How should we proceed when structuring our own definitions? Will these changes to the variant system evolve further?


I think this affects everyone working on unit design projects, color modification or anything related to the variant system. Personally, I have plans to develop a restoration mod for unit variety (vanilla unit and parts definitions) should this turn out to be a permanent condition. The intention would be to serve as a base mod and/or modder's resource until we have full coverage as far as more focused unit design projects are concerned. Obviously, I'd rather not put the effort into that if future development alters the system further or restores the original level of detail.

Who's attending, by the way?

Scratch this request. The problem has been acknowledged by CA and seems to be addressed in patch 9 beta. Hurray

[wangrin]

OP updated : question related to TW:R2 Assembly Kit

#2 : {3d models} issue with directX shaders

ISSUE : Bug with textures when creating custom new model Effect : impossible to process new model exported as CS2 through BoB Description : missing "standard_lighting_R2_3.fx" file Textures and shaders references point to a T drive, T drive that likely refers to a drive existing in CA developpers environment. CA probably try to fix this by giving us another shader(fx) file called "ca_shader.fx" but 3ds max crash when testing Some "ca_shader.fx" point to the T drive too. Notes : CA models use DirectX shaders and not normal ones. User environment : 3ds max 2013 x64 Sources : Warman222 - [Resource] Rome II rigid_model_v2 editor/ exporter ms3d post #61 post #64 post #65 post #67 post #68 post #71

[crzyrndm]

Issues TWeak: DAVE
---- Some forms in the form launcher are not updated for Rome 2
Buildings form: building_chains_to_slots is an irrelevant table as is building_culture_gov_types (not used in vanilla atleast), has neither of the superchain tables (building_superchains and slot_template_to_building_superchain_junctions) building sets or building instances. I also dont see anything for the campaign_display tables which control the models used on the campaign map. Upkeep/ZOC/Demolition cost no longer used.
Attached example showing required tables to create a working new structure (left, PFM view) compared to what the form does for you (right, DAVE view). The form is also very slow to browse, defaults to columns that are too narrow and just generally isn't much use.

Slots form: Entirely irrelevant (there are more of these, but they're also empty. This one acts like it's useful

Suggestions
It seems they already have the functionality required to switch DAVE between multiple source databases (connect to database). Could this be expanded to something similar to PFM's MyMod functionality to allow support for seperate mods from users (required additions would be: create new working database (make copy of raw data for editing), being able to select which database to connect to (one for each mod), and some BoB functionality to select which working data to pack)

The dependency tooltips in the database tables would be nice to have linked into the forms as well (It has the main dependency, but not the individual column dependencies)

[daniu]

Haven't thoroughly read the whole thread and it's probably already been mentioned, but one of the most important things CA can do is to update the source xml data for DAvE when they release an update; only having the ones from a previous patch makes the AK close to useless (depending on the amount of changes).
We should strongly poke them into integrating that release into their distribution process.

[wangrin]

You're right, I've forgotten to note it.

OP updated :

#1 : db schema update with patch

DAvE use a source xml data provided with Assembly Kit. But this document has not been updated when the game was patched and db schema modified. Is it possible that CA provide a db schema update for DAvE (Assembly Kit) in parallel with game patches

I suppose it's true for TW:R2 too.

About the directX shaders "issue", I'm not sure it's a real one.
I mostly rely on warman222 posts as I didn't have time to test it myself.
It seems that HunterWolf didn't have such problem.

[HunterWolf]

The only problem is the missing shader is that it will not be automatically loaded when you open a scene in 3MAKS. More on what is not affected, instead to shaders in the stage need to load the shader that is provided in the folder exporter.
I would like to know why my suggestion(post 47) is not listed?

[Kurisu Paifuaa]

You're right, I've forgotten to note it.

OP updated :

#1 : db schema update with patch

DAvE use a source xml data provided with Assembly Kit. But this document has not been updated when the game was patched and db schema modified. Is it possible that CA provide a db schema update for DAvE (Assembly Kit) in parallel with game patches

I suppose it's true for TW:R2 too.

I think it's important to stress that what we're asking is for raw data to accompany both release and beta patches.

Right now, my inclination is to ignore DAVE, despite it's highly useful features. Either that or ignore betas... constantly opting in/out is too cumbersome given Steam's extremely slim options regarding version control.

Posting raw_data updates for beta patches to their web site would be a decent compromise if the toolkit can't manage multiple data sets... though it looks like it's capable.

[crzyrndm]

Posting raw_data updates for beta patches to their web site would be a decent compromise if the toolkit can't manage multiple data sets... though it looks like it's capable.

DAVE (and by extension, BoB) isn't exactly much use until it can handle multiple raw data sets. How many of us work with just a single mod?

Solve that and the inability to rename tables (atleast, I haven't found a way, but it's required for compatibility), and they might have a useful tool

EDIT

RE: Handling whether to use beta data or not, they could just have it as a beta for the toolkit through steam when they have one for the game.

[AngryTitusPullo]

DAVE works the way a game developer works as a tool which is they already have a design of how to make their game. Mods will be able to fully utilize the tools by having basically the same method, like already having a design of how, what you mods will be and the tools is use in one go from editing the startpost to db to loc. It simply cannot be use the way PFM is used.

[Kurisu Paifuaa]

DAVE (and by extension, BoB) isn't exactly much use until it can handle multiple raw data sets. How many of us work with just a single mod?

Solve that and the inability to rename tables (atleast, I haven't found a way, but it's required for compatibility), and they might have a useful tool

EDIT

RE: Handling whether to use beta data or not, they could just have it as a beta for the toolkit through steam when they have one for the game.

Right on. I guess I could have worded that better... what I meant was that I'd gladly accept a raw data archive file (to be installed manually) until they have the framework to handle simultaneous versions through Steam. But you're right, it shouldn't be too hard to just a use the same beta opt-in facility for the Assembly Kit that they use for the main game.

What's this about Shogun II data not being updated to the final version? That's really lame

[wangrin]

The only problem is the missing shader is that it will not be automatically loaded when you open a scene in 3MAKS. More on what is not affected, instead to shaders in the stage need to load the shader that is provided in the folder exporter.
I would like to know why my suggestion(post 47) is not listed?

I'm not sure to understand what you suggest in #47.
To you mean a tool, like openBRF, that allow to open models, export them as static or rigged mesh, load textures, etc. ?

Assembling and tuning models is generally done when creating it, for example using 3ds max.
But I have to admit that openBRF is a fantastic tool, and CA should have a look to it.
The biggest problem for most modelers is that we can only export .max models to CS2 and then ingame models files format, but not export ingame models to .fbx, .max or any useful file format allowing to modify them.

[GideonAI]

One thing I'm curious about is whether any updates are planned for the Shogun 2 Assembly Kit (i.e. adding an animation exporter), or if they're just going to leave that alone.