IWTE - World editing - (General Discussion)

[leo.civil.uefs]

Which settlement is playing up now? Is it in the released version of the mod?

Dol Guldur. Yes.

Works fine in custom battles. But not in campaign.
Exactly like happened with esgaroth in the past and as I said, I fixed esgaroth by changing the settlement height via IWTE.

[wilddog]

6) Amended the mouse wheel function back to up down scrolling by default. Clicking the wheel button will centre the window on the clicked position and pressing the wheel whilst rotating it will switch to zoom in/out until released.

Next version (not yet released) is being changed as feed back (to above mentioned change) is too awkward (which I agree). The next version will have (for the 2d view):
1) mouse wheel zooms in and out.
2) pressing centre button (wheel button) and holding whilst scrolling in the window will scroll the view (rather than having to use the scroll bars).
3) double clicking the centre button (wheel button) will centre the window on the mouse postion.

The texture list has been amended to remove duplicates to make updating textures a lot easier. ie the list will reduce and differentiate based on texture name, no alpha, alpha, or litter only.

Exporting (some files) via collada file structure is being added ( may be released in a test form prior to importing via same format). This should support direct import into 3dsmax or blender...but is really just in test until importing is fully implemented. Initial release will be for basic world file exports only ie no animations.

[leo.civil.uefs]

While placing a bridge over a river crossing path in the battle editor, the bridge "jumps" while you move it, so I can't place it exacly where I want. It seems that it only can be placed in invisible slots that are there dividing the map.

This causes a bug because the actual rivercrossing path of the map does not match one of these invisible slots precisely. Still I can place the bridge, but out of synchrony with the battlemap rivercrossing path (some meters aside).

So while a unit is crossing the bridge, some men go through the water and die while the others walk over the bridge normally.

Is it possible to move the bridge with precision instead of moving it through these invisible slots so to make it match the rivercrossing exactly?

[makanyane]

While placing a bridge over a river crossing path in the battle editor, the bridge "jumps" while you move it, so I can't place it exacly where I want. It seems that it only can be placed in invisible slots that are there dividing the map.

This causes a bug because the actual rivercrossing path of the map does not match one of these invisible slots precisely. Still I can place the bridge, but out of synchrony with the battlemap rivercrossing path (some meters aside).

So while a unit is crossing the bridge, some men go through the water and die while the others walk over the bridge normally.

Is it possible to move the bridge with precision instead of moving it through these invisible slots so to make it match the rivercrossing exactly?

you could see if you can view the file that the battle editor creates and see if you can spot the x,y co-ordinates - it's binary but I seem to remember the .world name for bridge etc gets written as a text string.

Otherwise maybe adjust the pathfinding for the bridge - pic is for a bridge, it's path and .worldpathfinding shown >


I'm guessing one of the pathfinding elements is 'snapping' to the 2m grid, and the other isn't or is going to point 2m off - if you extended the blocked .worldpathfinding (dark blue) area one square each way to overlap the bridge sides that might fix the falling off problem. (though you might also need a wider bridge...)

[F9WK9]

Hello here. I have few questions

Does anyone know in which order does the game read the .worldpkgdesc files? Like is it based on the file name, location, both or the info within it etc.

Is there any way to get faction specific settlements to work in custom battles or do they only affect campaign?

- - -

Thanks for your hard work on the IWTE project

[makanyane]

Hi F9WK9,
I've made a wiki page here which trys to explain that stuff.

See the note at the bottom about factions - to get it to work in custom-battle you have to make a faction-specific pkg for EVERY faction in the culture. If more than one faction is using the same .world model, you don't need to duplicate the models, just make lots of .worldpkgdesc that point at the same thing.

I don't know what order it reads them in - but useage is based on the CONTENT only - not title or location (except somewhere in \settlements or specified folder), which is why you can very easily get in a mess if you've left behind copies you don't need/don't remember the title of! Hence when I do it I try and make the title descriptive e.g. Spain-LCity-uses-MEFort.worldpkgdesc - which gives you half a chance of figuring out later why something odd is turning up!

[leo.civil.uefs]

Oh dear...

I probably asked this before, but its been almost 10 years building settlements for med2 so Im not surprised to forget something...

Game crashes right when the gate is about to lift (porticullis) or about to be hit by the ram.

Any idea?

I've already removed and replaced the entire structure, set the object as mainobject gate, set the animation etc, just to be sure, and it still crashes.

[makanyane]

ugh - not sure - normally when it can't find an anim things just don't move...

check the file path/name to all the gate animations (in world file) "update animation paths" button

maybe something like it's finding the .anim but you haven't got a .mesh file with the same name in the folder? It needs that...

if not that check that the .texture listed in the .mesh is there


(I'm assuming you haven't been re-making the anims with IWTE yet?)

[leo.civil.uefs]

I just opened a settlement in IWTE (Isengard), edited and saved it, IWTE created 3 new main files in Isengard settlement folder. OK.
But then, using the same IWTE session, I opened Erebor, edited it and saved. And what happened was that 3 new main files of Isengard settlement were created inside Isengard folder.

IWTE does not have a "close" button to shut down the editing of a settlement, you must click "read 3 binary files" to open a new settlement, overlaping the previous one, but according to the experience I just narrated here, the previous settlement is not shut down and this causes a mess.

So you need to close IWTE and open it again to load a new settlement wihout messing up things.

Considering the current version of IWTE takes some time to start, I would say a "close" button beside the "read 3 binary files" one would be useful.


Another thing.
IWTE should memorize the path of the first binary file (.world) you select while opening a settlement. This way the user would not need to navigate all the way to the folder again to select the two other files. (thats really boring for someone like me who is always dealing with IWTE)

Also, automatically saving .worldvegetation and .worldpathfinding inside IWTE SAVE folder does not seem very useful. why not simply save it inside the settlement folder where the original files came from?

[makanyane]

I just opened a settlement in IWTE (Isengard), edited and saved it, IWTE created 3 new main files in Isengard settlement folder. OK.
But then, using the same IWTE session, I opened Erebor, edited it and saved. And what happened was that 3 new main files of Isengard settlement were created inside Isengard folder.

IWTE does not have a "close" button to shut down the editing of a settlement, you must click "read 3 binary files" to open a new settlement, overlaping the previous one, but according to the experience I just narrated here, the previous settlement is not shut down and this causes a mess.

For info what it actually did was save your 3 new Erebor files in the Isengard folder and called them Isengard_2 etc.. it has actually shut down the Isengard file contents and switched to Erebor content... it just hasn't changed the save-name/location

Anyway we agree that is confusing! especially as the latest things in your Isengard folder will now actually be Erebor! - IWTE needs to be fixed to ask you for a new save-name location when you load new files, if possible, WD will look at that - meanwhile if you realise that you've just ended up with your new files in the wrong place you can just cut/paste/re-name them over into the correct folder, sorry!

[makanyane]

Another thing.
IWTE should memorize the path of the first binary file (.world) you select while opening a settlement. This way the user would not need to navigate all the way to the folder again to select the two other files. (thats really boring for someone like me who is always dealing with IWTE)

Slightly confused with this - I've just tried with the .exe and it seems to do that already!?! - I was about to agree with you, because using the python files we use for testing do make you go through the path each time, but the .exe shouldn't be doing that... and doesn't for me!
EDIT: actually the python files don't do that either, they'll go back to same folder for .collision etc, they just don't remember the last folder you opened if you close and re-launch, which the .exe seems to...

Also, automatically saving .worldvegetation and .worldpathfinding inside IWTE SAVE folder does not seem very useful. why not simply save it inside the settlement folder where the original files came from?

yeaahhh - we have a bit of indecision about this - we started doing it as an alternative to adding _1 etc on the names of new files to prevent accidental overwriting - idea being you'd mess about with the files in IWTE SAVE until happy with them, then paste them into place without having to fiddle with re-naming. Some other bits (anims) now do a replace file and make a back-up copy, WD might try extending that so more of the files work that way.

[leo.civil.uefs]

Slightly confused with this - I've just tried with the .exe and it seems to do that already!?! - I was about to agree with you, because using the python files we use for testing do make you go through the path each time, but the .exe shouldn't be doing that... and doesn't for me!
EDIT: actually the python files don't do that either, they'll go back to same folder for .collision etc, they just don't remember the last folder you opened if you close and re-launch, which the .exe seems to...

I tried again (with the .exe of the latest version), and you're right.

BUT... I want to give myself the bennefit of doubt.
I can clearly remember this "problem" happening. Maybe it only happened in a specific circunstance or related to my PC configs? (Sorry if the question sounds stupid).

Ill be quiet for now to avoid wasting your time in case my report is nosense, but if I manage to replicate the case again, Ill tell in more details how it happened.

[leo.civil.uefs]

I think I know now exactly what was happening.
This is true:

I just opened a settlement in IWTE (Isengard), edited and saved it, IWTE created 3 new main files in Isengard settlement folder. OK.
But then, using the same IWTE session, I opened Erebor, edited it and saved. And what happened was that 3 new main files of Isengard settlement were created inside Isengard folder.

IWTE does not have a "close" button to shut down the editing of a settlement, you must click "read 3 binary files" to open a new settlement, overlaping the previous one, but according to the experience I just narrated here, the previous settlement is not shut down and this causes a mess.

So you need to close IWTE and open it again to load a new settlement wihout messing up things.

Considering the current version of IWTE takes some time to start, I would say a "close" button beside the "read 3 binary files" one would be useful.

While this is not. IWTE already memorizes the path:

Another thing.
IWTE should memorize the path of the first binary file (.world) you select while opening a settlement. This way the user would not need to navigate all the way to the folder again to select the two other files. (thats really boring for someone like me who is always dealing with IWTE)

The problem is that since I always had to shut down IWTE and open it again to avoid the problem described in the first quote, I had to drive through the folders again because IWTE does not memorize the path once you shut it down.

So I think that fixing the problem in the first quote will fix everything. In other words, adding a "close" button to IWTE.

The texture list has been amended to remove duplicates to make updating textures a lot easier.

Oh dear... This would have saved me ages of working in the past.
By the way, Im in need of this right now. Changing duplicated textures one by one is boooring.

[wilddog]

Hi Leo
Good comments. I'm hoping to get another release out soon so will see which of the above I can get sorted out to add in with that otherwise they should be doable for the release after that one.

general update and info on the new collada interface that is being developed.
We are testing out a collada interface to support amending the world files via blender or max rather than milkshape. It is likely the interface will encounter quite a few 'new' issues tied to the flexibilty it offers and how people use max and blender. I need to resolve how to add objects to new complexes and the process doesn't directly support deletion of complexes. ie modders have to use the existing processes for that. Naming is changing for the new processes also. As the new process has an in built hierarchy things will also depend if that helps or is a pain to use. The process will also be much slower than the existing processes for editing in terms of reloading and extracting data (I will look to speed this up later). However what it will offer is the ability to extract and edit at the complex level (or multiple complexes) rather than the structure level. It also will handle rebuilding the structures automatically. I'm just starting to look at whether to rebuild complexes automatically also. The complex rebuild will be an option as we're aware that many world models opted not to use complexes correctly and a consequence of a rebuild would be a resetting of a lot of object numbers and complex numbers.
The collada interface
- assumes a complex, -> object undamaged group -> object damaged groups heirarchy
- assumes texture is named (actually as a dds) this drives structure build.
- contains vertex shading data

The interface supports full world, single complex and single object extract from MTW2 to collada
The interface supports importing back of multiple complexes at once. Any complex supplied back will automatically add new objects or remove 'missing' objects from the re-imported files.
Similar to currently any reload of object information will result in renumbering of objects so you can't just re-edit and reload over a revised file.

[leo.civil.uefs]

There is another thing I would like to suggest.
Its something I've dealing with for like... 10 yeas now, lol.

It would be wonderful if IWTE allowed us to add collisions to multiple objects at once, as well as adding collision effetcs to them.

Selecting objects and adding collisions to them one by one takes ages. If we could ctrl + click to sort many different objects and then click only one time in "create object collision", it would be great! (click in first object + shift +click in last object of a uninterrupted sequence of objects in the object list woud also be good).

The same goes to collision effects. Let me give one example, Erebor has many invisible (alpha texture) boxes spread over the wall surfaces, they work like lamps emmiting light effects. But when you have like 50 of these lamp objects, it gets speccially annoying to go one by one assigning collisions and then again one by one giving them collision effects.

Well this is a lot of requests for now, I'll stay quiet and give you guys time to meditate about all I said here.

[makanyane]

But when you have like 50 of these lamp objects, it gets speccially annoying to go one by one assigning collisions and then again one by one giving them collision effects.

On existing version if you re-assign an existing collision (instead of creating a new collision each time) to the next lamp object, so all the similar lamp objects use the SAME collision, then when you change or add the effect it should already add it to all of them, that's been an IWTE function for a long while...

It would be wonderful if IWTE allowed us to add collisions to multiple objects at once,

The problem with that is the directionality - if something is completely symmetrical and doesn't have an anim then it would probably work. For things like wall blocks or towers that are almost symetrical IWTE needs to be given a clue by the user about which direction they face, otherwise the fine detail like battlements, or the anims when they get applied, are likely to end up pointing the wrong way.

Anyway points noted and added to the wish list

[leo.civil.uefs]

Im still not sure about the 3 main files path memorizing issue I reported, but for the .worldpkgdesc file Im sure.

If you actually opened the 3 maisn files in IWTE, then when you click to edit the .worldpkgdesc, IWTE will instantly open the same folder of the 3 main files.
But if you use IWTE only to edit the .worldpkgdesc without first opening the 3 main files, IWTE will not memorize the .worldpkgdesc path for when you click edit worldackage file again.

This path memory is impportant for when you're editing a lot of .worldpkgdesc files (it happens when you're organizing your mod), to avid you navigating all the way again and again through folders.

[makanyane]

Thanks Leo, that's all noted, and will be looked at, unfortunately it's going to take a little while as WD's in the middle of a bit of a re-write to get the option to import/export to blender working, so we need to complete that and check the existing functions haven't been messed up, before we get back to a stable base to make the other amendments from.

[wilddog]

Latest version of IWTE 20_07_A has now been released (see below details).

I've finally got around to adding in an interface (Collada format) to allow links to Blender (2.82) which also helps some of the Max users. The interface essentially overcomes a lot of the hard limits set by the original Milkshape support. A major change is tied to world file data as Milkshape had to handle everything at a structure level with a naming convention to support. The new Collada interface uses a different naming convention and supports multiple complex loading and NOT single structures.


1) New interface in Collada format to support links to Blender and 3dsmax. This has mostly been designed and tested with Blender 2.82. The format is partially supported by Max but not all functions are handled correctly.
2) Introduction of more top line menu options to support the new interfaces.
3) Export via Collada of World, Complex or Object options. These also include the parent complex box.
4) Import via Collada of World option. This reloads/replaces/deletes multiple loaded complexes in one pass. Deleting of a complete complex is still via the delete complex button. Please note that due to naming issues in data loaded to Max models involving alpha textures and reflective planes (water!) are not supported currently.
5) Export via Collada of World terrain data.
6) Import via Collada of World terrain data. This replaces the current terrain height data for the nodes loaded ie it also handles partial reloads of worldterrain data.
7) Export via Collada of World animations (.anim files). This is currently only handled at 30 fps and matrix format (Blender) or baked matrices(max).
8) Import via Collada of World animation data.
9) new option Reset Complex Blocks to allocate objects into complexes and structures.
10) Major speed up in calculating bounding boxes.
11) Further corrections to the Effects and shading processes. This will likely be expanded further
12) Introduction of new thread process and Error message system to handle slow running operations. This is a work in progress. The new Collada processes have been moved to this.
13) Texture naming now uses only single references to a texture rather than the multiple references that Vanilla models use which should ease changing Textures across complexes.
14) Various bugs and corrections.

[makanyane]

Apologies in advance to Leo - we've not managed to get the file path stuff done yet as the Blender changes were rather in-depth (and also in-progress so needed to be completed first to get back to a stable version)

I'm also behind with writing up instructions as usual! There's a start explaining getting things in and out of Blender here:
https://wiki.twcenter.net/index.php?...ender_for_IWTE