world modified

[makanyane]

Interesting results playing around with .worldvegetation tga4 (pure black 0,0,0 around the perimeter of the settlement); normally placing a settlement on a coastal hex would displace all the water far into the ocean;
made this teutonic village into an ambient settlement also, hoping to see it spawn on a settlement battle map here soon to observe the results. As a settlement model or fort this would need a worldterrrain "land bridge" if it was placed near water.

thanks for info... interesting - as far as we understood all the pure black bits meant was that there was no vegetation added - the regular green dots which normally cover most of it give positions of shrubs (or grass depending on the climate), I thought they just ended up under water level if there was water there.... they certainly do on moats.

are you sure its that making the difference and not the 'alpha' effect from the terrain file meaning the settlement heights for that area are being superseded by the battlemap ones?


I want to try and make a moated settlement with proper bridge - its something I was working on a long while back and never finished, will report back if it works.



thanks for de-bug link that looks very useful (most of the CTD's I get messing around with this stuff don't give anything useful in log.... that might be a lot more helpful)

[wolfslayer]

Setting up 2 shortcuts to your game mod; a windowed bat/cfg and ae full screen bat/cfg is one of the most important things a modder should do. I usually run windowed when modding and playing campaign..then save and go restart fullscreen for the big battles.

One of the single most important utilities I have for world modding is DEBUGVIEW. If you don't have it, get it! It is basically the systemlog in realtime, telling you exactly which files are loading, which textures are referenced and also 90% of the time tells me why and where my game is crashing (like a wrong hex value in .worldpkgdesc file)

http://technet.microsoft.com/en-us/s.../bb896647.aspx

Spoiler Alert, click show to read: 

"faction_variations" texture folders are ONLY used in settlement/fort battles, otherwise "variations" is used (north_european is default, ie., root folder). The game will always prioritize the most extreme end of the tree, in this case mods/Stainless_Steel_6/data/faction_variations/milan/variations/south_european
for loading textures. If they dont exist (I don't have special textures for milan in this battle), the game moves back up the tree between your mod and vanilla folders, then to the .packs to find the textures it needs.
This is just a basic overview, there are numerous other variables in texture loading..but the possiblilties for variety here are significant.

http://www.examine32.com/ Examine32 super for searching through files for a string, it will then list all and just doubleclick on one you want to edit. Great for searching through .world and .worldpkgdesc files.
Not sure if latest is time trial or limited, you'll have to try. possibly other similar freeware utilities available.

[SigniferOne]

http://www.examine32.com/ Examine32 super for searching through files for a string, it will then list all and just doubleclick on one you want to edit. Great for searching through .world and .worldpkgdesc files.
Not sure if latest is time trial or limited, you'll have to try. possibly other similar freeware utilities available.

This feature was replaced by Windows 7, where a simple Ctrl+F automatically searches within all given files. Otherwise great list of tools, especially DebugView.

[wolfslayer]

This feature was replaced by Windows 7, where a simple Ctrl+F automatically searches within all given files. Otherwise great list of tools, especially DebugView.

That's good to know when I upgrade ;-) I skipped vista but 7 can support the extra memory I need.

To wilddog: The World Complex TGA can be very useful for pathfinding editing. Is there as reason they always generate at 1761 x 1761?
It seems all settlement models have a very large terrain flattening square around them, I wonder where it is referenced and whether it is editable.
It surely isnt in the world terrain file, I wonder if it is in the world file itself. It's even larger than the wireframe selector used in the battle editor.

[makanyane]

To wilddog: The World Complex TGA can be very useful for pathfinding editing. Is there as reason they always generate at 1761 x 1761?

WD's adding option to select the size it prints for next version.

It seems all settlement models have a very large terrain flattening square around them, I wonder where it is referenced and whether it is editable.
It surely isnt in the world terrain file, I wonder if it is in the world file itself. It's even larger than the wireframe selector used in the battle editor.

does it make any difference what level the settlement thinks it is? e.g. if you use a stone_fort .world for huge city sized settlement do you get smaller flat area or not?

We were mainly going the other way and trying to use deliberately larger terrain files to control area around settlement & impose localised hills / valleys like on:

so I've not investigated trying to reduce it.

Can't think of anything unidentified in .world file it could be

22 serialization::archive 3 4 4 4 264 0 267 0 0 0 2 0 552.547912598 0
# =====================================================================
# Table 1
# ========

number at top is only possible candidate.... I previously thought that had fixed relationship to the 'octree' structure on left side of table 1, but found at least one file that didn't follow rule, don't think its much bigger than the building area though...

there's some unidentified floats on most of the settlement files at end of perimeters section at bottom of game objects like:

6877 6878 6879 6880 6881 6882 6883 6884 6885 7891 7895 7893 7894 7890 7892 7897
7896 7495 7898 7483
-1 4 0 0 0 0
0 0 [ 7] 0 0
-135.6774902 +109.5804825 -0.7660444 -0.6427876 +0.0000000 +0.0000000 16
+2.3955123 -39.8283730 +0.0000002 -1.0000000 +0.0000000 +0.0000000 16
+200.0825348 +26.6942673 +0.6427877 -0.7660445 +0.0000000 +0.0000000 16
+278.6511536 -140.6930237 +0.7071067 +0.7071069 +0.0000000 +0.0000000 16
+222.8454590 -258.1384583 +0.6427877 -0.7660445 +0.0000000 +0.0000000 16
-3.1998255 -283.5426636 -0.0000002 -1.0000000 +0.0000000 +0.0000000 16
-133.5457458 -231.1146698 -0.0000002 -1.0000000 +0.0000000 +0.0000000 16
# ------------------------------------------
# Beginning of Anim Strings Section
# ------------------------------------------
0 0 [ nentries = 27] 0 0
5
17 DamageTransition0

we don't know what that does but co-ordinates don't seem large enough to be either your flat area, or related to the attackers deployment area (which is the other thing I'd like to know how you alter!)

[makanyane]

please excuse the DP as its a different issue:

As we're now able to add more stuff, I'm getting increasingly frustrated with the lighting versus smoothing issues.... its what I was trying to explain here:
http://www.twcenter.net/forums/showt...85#post6568485

If you extract existing structure to ms3d and rotate it to be placed somewhere else, it tries to keep its original lighting directions see:

I've copied the gatehouse from other end and rotated it 180, in game its still showing shadow as if it were in original rotation (the lit side is even messier, that goes stripey )

The only way I can so far find to fix that is to assign it all to new smoothing group and then clear the smoothing (or anything else that resets the smoothing in milkshape) but then I lose the 'roundness'


I can sort of see why it does that.... johnwhile was quite correct in his post here:
http://www.twcenter.net/forums/showt...20#post6569520
about the need to detach vertexes at the corners or else game really completely mangles the lighting.....

if you start with cylindrical object and only detach vertexes (by deleting alternate sections and replacing the missing bits from a duplicate cylinder for example) then it seems to keep looking circular OK, but as soon as you move / rotate it and get the above problem you can't then get back to smoothed shape as (presumably) it can't recognise it as circular once the vertexes are split??


anyone got any ideas what you could do in milkshape, or possibly in converter to fix this issue?

[wolfslayer]

Resized generated world complex 50%, rotate anticlockwise 90 degrees, cropped and blended with generated pathfinding tga. Very close and can be used for some fairly accurate path editing, this is my me castle fort pathfinding I "eyeballed" edited a while back using the raw file method,

Quick post, I'll work and this some more later and try to get an exact alignment..

[makanyane]

the rotate bit, wilddog has noticed and will fix in next version so they come out same way...

getting them to relate when scaled is more difficult.


the complex plotter prints one pixel per vertex (roughly as most are on 4 x 4 grid in terms of ms3d coordinate....) the pathfinding relates to the centre of that grid as shown in image and blocks out the 4 x 4 area.... however in pixel terms that means you have .5 offset when you try to correlate them....

this is same problem as occurs with match between map_regions and map_heights in the campaign map files.... solution seems similar



is complex file at 721 image size reduced to 360 image size ( -1 and /2) via. nearest neighbour resizing, which stops the blur, then duplicated into pathfinding tga.... (weird bits are me messing about with moat)

anyway that's not wonderful as it's lost the less dense vertex points at inner bits of walls - eventual solution might be to get tool to make expanded version of pathfinding.... but I'm not sure how reliably it could decide what to exclude on reduction back down to its required points???

[wolfslayer]

I see what you mean with the .5 difference when resizing, optimally the world complex tga should generate as the exact size and proportion as the worldpathfinding tga.
But even this method is a lot easier than the previous one, after painting in the interior of the castle, I will copy/paste the original walls pathfinding into my modified pathfinding, recompile and test.
3 or more green (0,63,0) pixels = path
1 or more blue (0,0,255) pixels = block
Of course not all the little alleyways and archways line up exactly with the available path pixels (see pic), the world model would have to be modified to shift and enlarge those slightly, to remove carts and enlarge fence openings,etc..

I can always highlight the paths around interior buildings and shift one pixel in the tga, recompile and reload the battle, you just have to reload and move some units around and see how they react and move around..the sally out battle i have saved is perfect test, enemy regroups outside why i can explore the interior at my own leisure.

[wilddog]

I see what you mean with the .5 difference when resizing, optimally the world complex tga should generate as the exact size and proportion as the worldpathfinding tga.

Yes sorry about that it was because of the way I set up the vegetation files originally so you could add individual trees. On that scale I needed a pixel for 0, 0 and that's why I set the world TGA up the same way (it was also a bit of a quick and dirty).

I'm actually radically fiddling around with the interface at the moment.

[wolfslayer]

Yes sorry about that it was because of the way I set up the vegetation files originally so you could add individual trees. On that scale I needed a pixel for 0, 0 and that's why I set the world TGA up the same way (it was also a bit of a quick and dirty).

I'm actually radically fiddling around with the interface at the moment.

Even with the extra steps to resize and align the complex with the pathfinding, I did a rough full pathfinding for me_large_castle in about an hour, a huge time savings; figured out a few extra shortcuts in the process..

[wilddog]

To wilddog: The World Complex TGA can be very useful for pathfinding editing. Is there as reason they always generate at 1761 x 1761?
It seems all settlement models have a very large terrain flattening square around them, I wonder where it is referenced and whether it is editable.
It surely isnt in the world terrain file, I wonder if it is in the world file itself. It's even larger than the wireframe selector used in the battle editor.

Hi, I Didn't spot this question before. The 1761*1761 was a simple default as its the size which covers a full battlemap that you can deploy on. It was also the maximum I set the wolrdterrain, worldpathfinding and world vegetation to be. Its based off of the 221 vertices used for the base in worldterrain. The 3 mentioned files all refer to it in some way but the actual world map doesn't. I'm changing this to be editable so people can align with the worldvegetation and I'll see how to remove the one pixel difference later.

As a work in progress I am building a lot of changes to the interface (and correcting some bits which didn't work). One of the main things is a window where you can see the world file directly as well. I need to see to expand that process for some other things also.

[makanyane]

I've been messing around trying to get new gates (or at least new gates that look the same as original ones) to animate.... its the only animation aspect I'm personally very bothered about - I don't mind not having animated bits of tower falling off, but gates that units can walk through without them appearing to open look very daft....


it seems it can be done, at the moment only by copying and pasting relevant chunks of animinstances around with a hex editor, interestingly it revealed that the animation mesh isn't rotated by the animinstances section but by the rotation matrix in the .worldcollision entry

the collision model entry has to be entered in the same orientation as suits the default animation, and then the matrix in table three of .worldcollision used to rotate both the model and the animation to the direction you want.


shows a gate animation rotated to 45degrees using johnwhile's matrix calculator to find the settings

[wolfslayer]

You can see from the screen, where I have the battle editor open in a window for reference, how the complex tga blends in with the path tga; I just cropped and copied the keep section to see if I can get units to move through the rats maze in the keep, and if AI can make it through.
I always open and save in photoshop, but copy/paste into paintshop pro for editing.
Once I paint in the paths and areas I want open; I don't have to color in all these areas, I convert the image to 16 colors and edit the palette so all the greens are 0,63,0 and all the blues are 0,0,255.
Then I just copy/paste into the stock pathfind I have open in photoshop and save.
Recompiling and creating a new "fort" from the me_fortress that I can test in a custom battle only takes a few minutes.
Then I can watch units move and make minor adjustments that are needed.

[wolfslayer]

The twin gates in the keep of se_fortress are fully functional; at first I had 2 paths here, but the units would just jam against the gate before it opened (2nd pic); added the normal blue block for a gate here and they function normally, just like other gates, as they have their own trigger and pathfinding that overrides the pathfinding file. Now to put all my units here and see if the enemy AI walks right in or has to use a ram..

[dmesa]

very nice... i like those twin gates, they're perfect for a faster retreat

[twmodder]

I've read here about the ''nearby disapearance problem''.
Now I have the same problem, as I wanted to add a new structure by duplicating other objects.
Is there any way to avoid this? Or how can I solve it without having to use a hex editor?

If I would create an object completely new, this wouldnt happen to me?

Maybe it also has something to do with the worldcollison, because the new objects haven't an own collision yet.

[wilddog]

've read here about the ''nearby disapearance problem''.
Now I have the same problem, as I wanted to add a new structure by duplicating other objects.
Is there any way to avoid this? Or how can I solve it without having to use a hex editor?

It should be resolved int he enxt release of the tool, It was the first item.

http://www.twcenter.net/forums/showt...67#post6569667

[twmodder]

Thanks for creating this great tool, I already use the beta! Then I'll wait for the next version

[makanyane]

twmodder

if you mean the same thing that was happening to me here:
http://www.twcenter.net/forums/showt...93#post5738693

Argantonio's reply below might help you fix it for yourself in the interim - you don't need to use hex editor
do binary > text conversion with IWTE tool. in the _world.txt file it creates you need to make changes to table 1 only, then convert back text > binary

in a row like

 -54.6276321  +33.1988678  +15.5502224   2   2   2  -1  -1   2  -1  -1   2   2  -1  -1   2  -1  -1   2  13  -97.1874084   +6.7234941   -6.5896578  -31.2611084  +41.6415939  +39.7039948

the 13 is the complex number the
-97.1874084 +6.7234941 -6.5896578
need to be lower than the minimum x,y,z milkshape co-ordinates for everything in the complex
the
-31.2611084 +41.6415939 +39.7039948
need to be higher than the maximum x,y,z co-ordinates
(remembering that the x value is reversed in milkshape)

the complication is that you also need to find the line higher up table 1 that includes that row inside it.... see if you can follow Argantonio's explanation of that bit, what you're looking for is basically the row number (starting 0,1,2 etc...) of the table 1 entry you just altered, where that appears in central section of table that's the next row you need to alter to make sure its min and max values are also large enough, then the same thing with the very first row.



erm.... or wait for next version of tool