Custom settlement problem in Linux

[Withwnar]

Actually could those with Linux try changing their
packagedb.txt
to look like

; List of directories to search for packages
.\settlements
.\blockset

I think that should force it to cache it early

I tested that with Hornburg and it didn't work

Could be a long shot but...

If the file was edited in a Linux editor then the line break between ".\settlements" and ".\blockset" might have been an LF character (standard Linux line break) instead of the CR+LF pair (Windows) that M2TW is expecting. In which case it would not see those as two separate lines. Possibly.

[Socrates1984]

Could be a long shot but...

If the file was edited in a Linux editor then the line break between ".\settlements" and ".\blockset" might have been an LF character (standard Linux line break) instead of the CR+LF pair (Windows) that M2TW is expecting. In which case it would not see those as two separate lines. Possibly.

I don't know what an LF line break is. Actually, the Internet is wise.

If this was the case shouldn't other text edits I've done suffer from the same problem? I remember editing bmdb, edu and descr_strat without any problem. I mean I added many new lines (new models, new units, new starting buildings respectively) and they were all recognized.
Unless there is something particular in packagedb.txt.

[Gigantus]

One oddity came to my mind: when using custom models for battle banners you need to use a extended path in descr_banner_new else the game would continue to use the vanilla files. Example from 1648 where we came across this:

      <Banner Name="main_spear" MainMesh="mods\1648_2\data\banners\main_spear.mesh" MiniMesh="mods\1648_2\data\banners\mini_spear.mesh" GeneralMesh="mods\1648_2\data\banners\main_general.mesh" BuildingMesh="mods\1648_2\data\banners\main_spear.mesh" EffectOffsetX="0.0" EffectOffsetY="8.1" EffectOffsetZ="-0.1">
         <Textures>
            <Texture Faction="poland" DiffuseMap="banners\textures\Faction_banner_poland.texture" TranslucencyMap="banners\textures\Faction_banner_trans.texture"/>

[makanyane]

One oddity came to my mind: when using custom models for battle banners you need to use a extended path in descr_banner_new else the game would continue to use the vanilla files. Example from 1648 where we came across this:

      <Banner Name="main_spear" MainMesh="mods\1648_2\data\banners\main_spear.mesh" MiniMesh="mods\1648_2\data\banners\mini_spear.mesh" GeneralMesh="mods\1648_2\data\banners\main_general.mesh" BuildingMesh="mods\1648_2\data\banners\main_spear.mesh" EffectOffsetX="0.0" EffectOffsetY="8.1" EffectOffsetZ="-0.1">
         <Textures>
            <Texture Faction="poland" DiffuseMap="banners\textures\Faction_banner_poland.texture" TranslucencyMap="banners\textures\Faction_banner_trans.texture"/>

had seen that earlier and will give it a go... I'm not holding out a lot of hope though as we've already tried getting the Linux users to move the anims (and also the settlements in an earlier test) into m2tw/data/... which would have fixed it if it was just a mod-folder issue

[Gigantus]

had seen that earlier and will give it a go...

Getting old and not getting enough coffee on my side it seems. I should have checked if I mentioned it already.

[makanyane]

If the .db thing didn't work not so sure this will but anyway;
https://www.dropbox.com/s/jmqw7wchkn...hance.rar?dl=0
copy the edoras folder over your unique_settlements/edoras folder so all the stuff overwrites and you also end up with
unique_settlements/edoras/town_wooden_palisade
which will contain the original aztec anims...

am looking at the
mod/data/... version of paths but so far under windows that just ends up with no animations working...

[makanyane]

mods/mod_name/data/... definitely doesn't seem to work in windows

../../../mods/mod_name/data/ seems to

https://www.dropbox.com/s/8g47geodmh...0path.rar?dl=0

has that
copy
edoras over edoras so those files overwrite and also
blockset over blockset so you get mod/blockset/zztec back (if you deleted it - its the same one as before...)

[makanyane]

@Socrates - I wasn't holding out a lot of hope of the packagedb.txt fixing things anyway.

Could you try the two tests above at some stage... and also a favour please. Could you send me some sample files from your vanilla unpacked game? I'd like

m2tw/data/blockset/north_european/animations/wall_animations/town_wooden_palisade - contents
&
m2tw/data/settlements/north_european/settlements/town - contents

wilddog's been having a think about this and we're starting to wonder if your re-released for linux version of the game might actually be a bit different from ours...


EDIT: actually hold-off on that I've got a better idea of what might work - putting new named anims in old folders

on the basis that LINUX should have a problem with the old BlockSet type path calls - do you think the makers of your version might have hardcoded a fix like if "BlockSet/Aztec/..." requested look up "blockset/aztec/..." ?????

[Socrates1984]

If the .db thing didn't work not so sure this will but anyway;
https://www.dropbox.com/s/jmqw7wchkn...hance.rar?dl=0
copy the edoras folder over your unique_settlements/edoras folder so all the stuff overwrites and you also end up with
unique_settlements/edoras/town_wooden_palisade
which will contain the original aztec anims...

Did that and ended up with exactly the folder configuration you describe. It didn't work.

mods/mod_name/data/... definitely doesn't seem to work in windows
../../../mods/mod_name/data/ seems to
https://www.dropbox.com/s/8g47geodmh...0path.rar?dl=0
has that
copy
edoras over edoras so those files overwrite and also
blockset over blockset so you get mod/blockset/zztec back (if you deleted it - its the same one as before...)

Before testing this, I deleted the unique_settlements/edoras/town_wooden_palisade folder from the previous test and overwrote the edoras file afresh, hence having a fresh TATW installation. After that I followed the instructions for the second test and ended up with exactly the files you describe.
It didn't work. BUT this time something happened which is really rare. This window almost never pops up when a CTD occurs. This time it did. I don't think it's important, as a 'net search delivers nothing of importance. It's weird though why this time it popped up.

Spoiler Alert, click show to read: 

[...] and also a favour please. Could you send me some sample files from your vanilla unpacked game? I'd like

m2tw/data/blockset/north_european/animations/wall_animations/town_wooden_palisade - contents
&
m2tw/data/settlements/north_european/settlements/town - contents

Of course. Here you are.

wilddog's been having a think about this and we're starting to wonder if your re-released for linux version of the game might actually be a bit different from ours...

This is not a bad idea. I've noticed that the game is more stable now than when I was using Windows. Which could possibly mean that Feral released the game with slightly different content, e.g. removing some bugs.


By the way I contacted Feral three days ago on the log issue. They have good support and they seem to be remember me from last time I contacted them for the unpacking adventure. When new info comes, I'll keep you updated. Especially if it gets solved.

[makanyane]

Thanks for sending those files - interesting the .mesh files do appear to be different - I don't know if it's anything relevant yet... but it could be messing up the tests - because I've been sending you my vanilla versions to put in the new folder positions.

Can you go back to the 'edoras zztec' test copy the edoras_a.world over the other ones again and this time
into the
mods/tatw/data/blockset/zztec/animations/town_wooden_palisade
folder copy your
m2tw/data/blockset/aztec/animations/town_wooden_palisade/ contents


EDIT; there's a big chunk of binary that's different in the middle which we can't remember what it does at the moment... but more relevantly - they have changed the texture look-up at the end of the file to all lower case - whereas my 'vanilla' files and tatw's modded ones still have upper case - so we might be back to that after all!

[Socrates1984]

Ok, so:
1) I refreshed my TATW installation.
2) I copied the three files from the zztec folder you sent us and pasted/overwrote them in unique_settlements/edoras.
3) After that I noticed there was no zztec folder in the data/blockset/ folder. So I presumed you meant "Do that too, exactly as you did back then for that test". That I did, i.e. copied the zztec folder in there right next to the water folder. And in there I pasted/overwrote the files from vanilla.
4) Tested. It didn't work.

Sorry for being so detailed, but I fear I might be misunderstanding your instructions.

There's also news in the log front.

Spoiler for First reaction: 

EDIT; there's a big chunk of binary that's different in the middle which we can't remember what it does at the moment... but more relevantly - they have changed the texture look-up at the end of the file to all lower case - whereas my 'vanilla' files and tatw's modded ones still have upper case - so we might be back to that after all!

I'll come back later to do the test and edit this testpost.

[makanyane]

hmmm, might be between us we're not getting things quite in the right place...

I'll try changing the case on some of the tatw custom anims later and send those for you to try.

[Socrates1984]

I feared as much. Did I put the files in the wrong place?

This message was sent by my mobile phone.

[makanyane]

Description sounds right... screenie the folder structure showing the town_wooden_palisade bit

There is something still a bit odd that they changed the path within the mesh to lower case but not the ones in .world...
so there still might be some hardcoded look up for those folders. hmmmm

[makanyane]

https://www.dropbox.com/s/dir1ywh2jd...anims.rar?dl=0

am hoping this works...

1st test folder contains edoras folder - copy that over unique_settlements/edoras so that the edoras_a.world/worldcollision/animinstances overwrite

also contains north_european folder - copy that into blockset so it merges with the existing north_european folder and you end up with a new
town_wooden_palisade folder in wall_animations. The contents in that are socrates' versions of the town anims, just re-named, the new edoras_a.world
directs to those.


The town.world you sent has this path for anims;

Spoiler Alert, click show to read: 

I've tried to add the path to the re-named anims in exactly the same case/path but with changed file name

Spoiler Alert, click show to read: 

HAVE INCLUDED THAT PIC SO YOU CAN CHECK MY SPELLING (PLEASE) AND THE LOCATION YOUR FILES END UP IN


If that works - try test 2 which uses same edoras_a.world files but has revised mesh files in the north_european/... folder which would give you back the tatw wall texture.


If none of this works please shoot me

[Socrates1984]

Description sounds right... screenie the folder structure showing the town_wooden_palisade bit

Here it is (for the previous experiment):

Spoiler Alert, click show to read: 

1st test folder contains edoras folder - copy that over unique_settlements/edoras so that the edoras_a.world/worldcollision/animinstances overwrite

1) As always, I first refreshed my TATW installation. Just to be sure, I have a backup copy of all TATW folder elsewhere in my hard drive; when you ask me to do something, because I don't remember what exactly we did in the previous test, I simply delete all blockset and settlements folder from my running TATW installation and paste fresh ones from the backup.
2) Pasted edoras folder and overwrote the three files.

also contains north_european folder - copy that into blockset so it merges with the existing north_european folder and you end up with a new
town_wooden_palisade folder in wall_animations. The contents in that are socrates' versions of the town anims, just re-named, the new edoras_a.world
directs to those.

Did that, ended up with this:

Spoiler Alert, click show to read: 

The town.world you sent has this path for anims;

Spoiler Alert, click show to read: 

I've tried to add the path to the re-named anims in exactly the same case/path but with changed file name

Spoiler Alert, click show to read: 

HAVE INCLUDED THAT PIC SO YOU CAN CHECK MY SPELLING (PLEASE) AND THE LOCATION YOUR FILES END UP IN

As you can see from my picture just above yours, the spelling and the paths seem correct (besides the cases of course). Another one to be sure though never hurts:

Spoiler Alert, click show to read: 

Right, so now I tested it. It didn't work.

If that works - try test 2 which uses same edoras_a.world files but has revised mesh files in the north_european/... folder which would give you back the tatw wall texture.

Redundant?

If none of this works please shoot me

Have we ever in our tests tweaked anything outside of the blockset and settlements folders?

[makanyane]

Have we ever in our tests tweaked anything outside of the blockset and settlements folders?

Only that 'packagedb.txt'

and I did get you to copy the settlement & blockset folders up into m2tw/data at one stage - but I think you already reversed that - (and even if not it shouldn't be affecting this - though you might end up with some spare bits of tatw appearing in other mods...)



you could try copying the "edoras_wall_animation_a...." etc files up into the equivalent town_wooden_palisade folder at
m2tw/data level I suppose - but it really doesn't seem to want to play does it!!!




does anyone have a linux version and windows version of M2? I'd really like to know if it's gained any extra lookup or .db files...

[Socrates1984]

does anyone have a linux version and windows version of M2? I'd really like to know if it's gained any extra lookup or .db files...

This could be possible but difficult to do. What is needed is actually someone with both versions of the game: The Linux-native and the Windows-native. The Windows-native can be played in Linux via a program called WINE (a recursive acronym for Wine Is Not an Emulator). But making one of the versions work makes the alternative redundant. So it is probably difficult to find such a person, although I'll keep an eye out.

Now, it seems we've reached a deadend. From what little I understand we (you) have made the settlements work, not using the (gate?) custom animations but the vanilla ones.

So I wonder: Could we make all settlements work exactly that way?

This would not count as a full solution, but as a working one nonetheless. That is, we have on one hand a CTD situation; and on the other hand we have a non-CTD situation with something less than than fully implemented custom-ness.

If yes, I could write a detailed tutorial on how to do it for current and future Linux (and possibly Mac) users. With your help of course if you agree, as I don't understand what exactly we did in the experiments...

[makanyane]

Could you try one more test for me, not sure if we covered this or not - it's a new path to your original wall anims you sent me. The path inside .world is dropped to all lower-case (last test I didn't as your original .world's didn't, but hey...) path and file names also as short as possible.

Same old procedure;
https://www.dropbox.com/s/isytkzx0yx...anims.rar?dl=0
blockset over blockset so you get a new "newanims" folder
edoras over edoras so the .world/collision/animinstances overwrite.

pic of file paths inside .world so you can double check location/names etc;



after which I have definitely run out of ideas...

Now, it seems we've reached a deadend. From what little I understand we (you) have made the settlements work, not using the (gate?) custom animations but the vanilla ones.

So I wonder: Could we make all settlements work exactly that way?

This would not count as a full solution, but as a working one nonetheless. That is, we have on one hand a CTD situation; and on the other hand we have a non-CTD situation with something less than than fully implemented custom-ness.

If yes, I could write a detailed tutorial on how to do it for current and future Linux (and possibly Mac) users. With your help of course if you agree, as I don't understand what exactly we did in the experiments...

Yep it seems they can be fixed to a non-CTD version by using the original animations AND paths. It's not actually that hard to do that, though it really needs IWTE, I can go through and do that if nothing else works.

What you'll get is the original texture appearing while the animation is in use and a disconcerting switch backwards and forwards.

I'd suggest that you only keep the animation for the gates - you need them animated, otherwise it looks really really stupid and sometimes troops also get 'stuck' on the collision of the un-opened gate.

Walls is a bit more of a matter of opinion... I'd prefer to just remove the animation for them. You'll still get the progression from intact > slightly damaged > very damaged > completely destroyed, it'll just jump instantly between states. I personally think that looks better than having a jump to old texture > animated bit > jump back to new texture.

Let me know your preference, and of course if the test above actually works!!!!

[Socrates1984]

Sure, I will gladly do this test!

As for the less than optimal solution, why do we need IWTE? I haven't used the tool for the tests, just moved files around. So, we (again, you) could upload the final right files, I write the tutorial and link to the download section, giving the due credit of course, if it matters at all.

I'll do the tests and come back with an answer.