IWTE - World editing - (General Discussion)

[wilddog]

@Roraii - do you mean the generic town and large town ( NE etc) or the ones from the mod? As its the ones from the mod that are corrupted. I will likely have a bit of a look at the corruption later today to see if the routine I made to check for the one type of corruption can be easily amended to handle this new type.

[Rorarii]

i'm talking about the TATW sub-Mod - "Divide and Conquer" but it has generic settlement models for "town" and "Large Town", for the "Beorn" faction that appear unchanged (i think, they look the same) from M2TW kingdoms. Town has pallisade wall, Large Town has wooden wall.

see attached "Large Town" files, first one is an error, trying load saved binary files, last 2 are loading old uncorrupted (unsaved) binary files ok.

R

[wilddog]

Roraii - I was trying to explain this the files are already corrupted. The process is that IWTE reads in the files and then tries to convert to the correct structure for the table 1 references. Except they are already screwed up as explained. Consequently IWTE can't reset them correctly. When the file is saved and then reloaded the routine that does this check simply fails because large chunks of the file are now completely out of sync. This crash gives you the result of the first one. The last two simply are already corrupted and are incorrectly handled in IWTE as a consequence. Its just they haven't been saved yet so you can't easily see its completely screwed. Unfortunately the tool used to create those settlements in the first place had incorrect logic which simply doesn't match the vanilla set up. The routine that crashes in IWTE was part of a routine to resolve this issue for the EDB team but the files you are using are in a different corrupt state. The EDB team used the DBM mod whci at least got the parent to child connections set up correctly they just took it to more levels than they should of and split different parts of the hierarchy down whereas it should be consistent. In the case with the models you are using they have set the max combination as 3 (levels 0,1 and 2) but they linked level 1's together which was completely incorrect. In the end its tied to a simple issue the maximum complexes is suppose to be 64 and these models exceed it (as did the DBM ones). The actual engine doesn't seem to care too much though but that's the result of 'more luck than judgement' in the design of their tool.

You could try editing the text file (table 1) but that's a pain.

[Rorarii]

ok, files are corrupted, i won't try to edit them, except for terrain, which is a seperate file and appears to work ?

R

[wilddog]

Yes, the issue is only with the .world and likely .collision. I'll see if I can sort something out on this next week but trying to finish off something on the painting process for pathfinding first.

[Rorarii]

Thanks but no rush, i've achieved 80% of what i wanted by editing the Terrain files. The other 20% is altering Road markers, fixing some texture files, and trying to make the wooden walls larger to accommodate more soldiers, and to raise the wall-walkway so archers fire straight or down, not loop half their arrows. This last fix would be unnecessary if someone else has created new generic towns / large towns ?? leo ?

So ... low priority.

R

[leo.civil.uefs]

Thanks but no rush, i've achieved 80% of what i wanted by editing the Terrain files. The other 20% is altering Road markers, fixing some texture files, and trying to make the wooden walls larger to accommodate more soldiers, and to raise the wall-walkway so archers fire straight or down, not loop half their arrows. This last fix would be unnecessary if someone else has created new generic towns / large towns ?? leo ?

So ... low priority.

R

Never did something like that.

The 3d wall models need to be the vanilla ones in order to get animations working well so you cannot stretch them to be higher or omething like that.
Howeter, you still can rise the terrain under them... well, actually you should do the contrary way and lower all the terrain except the parts under the walls. Thats because moving the 3d wall models in ms3d and assigning them new animations and all would be a nightmare for you.

The same goes to making them larger for accomodate more units, you would need larger walls, wich means different 3d models, so no animations.

However, if you want unbreakable walls with no animations then you can make them the way you want, higher or lower, larger or narrower, totally custom.
If so, remember TO NOT SET the wall objectcs as "mainobjects" "walls", otherwise the AI will do nothing but try to destroy them and then get stuck after al their catapult/trebuchet projectiles are wasted.

I always recomend to load some of my settlements in IWTE and get the examples. In therms of what could be done in the engine for working custom settlements, I think I have extinguished the possibilities. But who knows.

[Rorarii]

thanks Leo, you're the expert, I'll take your word for it, I just wanted to fix the old bugs from the original M2TW but I'll give it a miss.

R

[wilddog]

@Rorarii - I've written a small routine this morning to convert that table 1 corruption to look the same as the other DBM corrupted ones so the routine which then corrects them will work for these .world files in the next version of IWTE.

[Rorarii]

@Wilddog, thanks.

[wilddog]

Next version should be out before end of this month. I'm just trying to finish off some generic routines tied to some new 'painting processes'. World pathfinding is being changed to fit with it but the basic editing will be the same as the current version. Advantage with this approach is that I should be able to include the other 'TGA' type items fairly easily including the overlays. This should make it easier to edit them whilst showing the 2d views of the actual .world objects.

[leo.civil.uefs]

I dont know what I really want. IWTE has become a masterpiece tool and its nice to see you guys improving it but I honestly want to see you going back to PKH and finishing it, you deserve it now.
Belive I really know the feeling of beeing totally absorved by modding and having no time to play by myself or enjoying my own stuff.

Maybe next version could be the last one in therms of features and then only fixes would come.

Just guessing.

[wilddog]

Maybe next version could be the last one in therms of features and then only fixes would come.

No, next one will have the start of the painter processes and then I'll add the others. Lighting is also in the next version. At his time there are no reported bugs to fix but next version will also contain a fix for the settlements produced from a different tool which have the corrupt table one entries in the .world file.

Not sure I'll really go back to PKH (at least in its original form). I mentioned it to GED that he could delete the thread as we haven't realistically done anything on it for a few years now.

[xHolyCrusader]

Oh those are sad news indeed... no pkh D:

[Arandir Tur-Anion de Bodemloze]

No PKH. We can hope to see the castle one day ?

[wilddog]

new version released. Let me know if any bugs :

with version 14_05_A
1) Added routines to edit the.lighting files (see specials tab)
2) Added new 'painting' process for files accessed via the 'files' tab at the top of the window. The process allows you to set the paintbrush and amend the opacity of an image file. It also supports moving the files up and down a list. Intent is to add other files into this.
3) Changed world pathfinding routines. Old buttons removed (except resizing). You now open the file and edit via the painting process.
4) World vegetation files for adding grass and trees added to the painting process and their buttons removed. Amendment to the blending vegetation file still uses the old process.
5) Minor change to handle codec differences on pathnames that were causing some issues.

@ Rorarii - this should also solve the problems with the settlements created via the other tool.

[Rorarii]

new version released. Let me know if any bugs :

with version 14_05_A
1) Added routines to edit the.lighting files (see specials tab)
2) Added new 'painting' process for files accessed via the 'files' tab at the top of the window. The process allows you to set the paintbrush and amend the opacity of an image file. It also supports moving the files up and down a list. Intent is to add other files into this.
3) Changed world pathfinding routines. Old buttons removed (except resizing). You now open the file and edit via the painting process.
4) World vegetation files for adding grass and trees added to the painting process and their buttons removed. Amendment to the blending vegetation file still uses the old process.
5) Minor change to handle codec differences on pathnames that were causing some issues.

@ Rorarii - this should also solve the problems with the settlements created via the other tool.

Thanks Wilddog, will download it and check it out later.

One change I'll also need to do is Terrain texture editing, move some farm land, add trench pits etc . i assume I'll be able to do that ? haven't looked at this yet.

R

[wilddog]

Oh those are sad news indeed... no pkh D:

No PKH. We can hope to see the castle one day ?

Separate discussions and separate thread..... I want to redo some strat mapping (which may get put into IWTE) but I'm considering a few ideas which change the original mod idea.

Anyway as said not really something to do with IWTE

[leo.civil.uefs]

I want to make a certain climate to load winter textures for vegetation (tree, brushes models) even if it is summer.

How can i do it?

PS1: Im asking here as I suppose that maybe with IWTE I can do it by editing the descr_geography_new.db

PS1: I fixed the ground beeing totally black under night shadows using the new IWTE version. Quite simple, each .lighting file has a SHADOW RGB FLOAT line for RGB values that can be edited in IWTE, for some reason the TATW lighting files were all set as 0,0000 ; 0,0000 ; 0,000. I've just took these values from vanilla med2 and applied to the ones with the 0,0000 values.

Thanks a lot wilddog!

[wilddog]

I want to make a certain climate to load winter textures for vegetation (tree, brushes models) even if it is summer.

How can i do it?

PS1: Im asking here as I suppose that maybe with IWTE I can do it by editing the descr_geography_new.db

Its fairly straight forward and the short answer is you simply make the references for both summer and winter for everything associated with that climate the same.

So depending on the various different parts you are changing you need to amend items listed below :

Stratmap textures = descr_aerial_map_ground_types.txt
descr_climates.txt = to set strat map veg models
descr_geography_new.db = battlefield ground_textures, overlays and overlay modification
vegetation.db = vegetation groups (this allocates the vegetation models amongst other things).
vegetation/models/textures = copy the winter textures and rename them by removing the text "_winter" from the name

In IWTE you can edit the descr_geography_new.db and the vegetation.db. There is also a copy function to copy a season from any climate (in the same db file) to another season/climate combination. You can choose which tables to copy.

I never added a function to copy from a different geography.db file though so if you wanted to do that you would have to copy in the entries you wanted to duplicate first.