IWTE - World editing - (General Discussion)

[King Kong]

just genious wilddog, you are faster with making all these changes and releasing them than I could write an answer here.
A big big thanks for that, I already tested the version a bit and the pathfinding, the item and the docking point changes really makes the IWTE life easier and more comfortable.
But I just discovered a little bug (probably): I can't change the plaza position anymore (the change plaza button doesn't appear) and the deployment changes also don't seem to work.
I get the following error message:

Spoiler Alert, click show to read: 

Other than that, it all seems to be working well and also I'm looking forward to try out this "world vector change" which could become very handy with Osgiliath.


@makSince you mentioned something about it, I can confirm that arrow towers are working even if they are not part of a link/ladder path. Here is what my (working) towers look in the IWTE:

Spoiler Alert, click show to read: 

However, somehow the arrow towers are still troubling from time to time and refuse to shoot, but I suppose it has more to do with the fire angles from the descr_walls.txt.
And as second remark: you mentioned that the distance for the units, so that they activate the towers, couldn't be adjusted, but they are also adjustable in the descr_walls.txt.

[wilddog]

Hi KingKong
I'll sort out the issues on the centre point bit tomorrow. Think its pretty simple. I had a silly issue trying to get the very first time the 'point' items (firing positions, roadmarkers, etc) appeared in the centre of the 2d view as they wouldn't centre and then realised I'd missed a call of a particular command. I kept trying different things before I realised my mistake and I think that's where I've introduced the error (always introduce something).

Should be OK to sort out tomorrow .. after the rugby matches.

PS Tried to rep you on Osgiliath.. that looks really great... ( except it wouldn't allow me as I hadn't reped enough.. sorry).

The vector change is in each direction so it doesn't equalise nearest points necessarily. What it does is check for a particular axis and then sees if anything is within the parameter (for that axis) . If it finds anything it will set them to the average of those values. It proceeds along that basis until it finds no more points within the parameter and the average. Then it starts again.. should handle most things though particularly if the parameter is set around the 0.001-0.003 mark (ie 1-3cm).

[wilddog]

Yep, I accidentally deleted one extra line.

Fix now out latest version IWTE_6_2_1 October 1st.

[Devils_Advocate]

Thanks a lot, as always!

Will test it the next week.

[King Kong]

yep, thanks a lot for the quick fixes!
However, I think you forgot one, because assigning collisions is not possible anymore (maybe introduced through the new angle display?)
I get this message:

Spoiler Alert, click show to read: 

[wilddog]

Hi Thanks for spotting that King Kong. I copied an extra line from the animation routines to the select collision process. (it was tied to adding in the default docking positions).

new version IWTE_2_2_2 released October 2nd

I also added in the additional collision related routines :

with version 6_2_2 - minor updates to functionality usage and a couple of special items.
1) On Special items there is an option "world vector change" which allows you to move and/or do 90 degree rotations on a world file and its collisions.There is also an averaging parameter which averages values along a single axis which are within that parameter distance of each other.
2) On Special items there is an option to create a basic cas file which can be loaded into 3dsmax via Vercingetorix script.
3) process for setting deployment outline has been simplified.
4) Creating collisions via the collision/animation buttons automatically adds in docking points as well as asking you for the breach information.
5) adding certain game objects now adds them to the centre of the 2d window (rather than zero, zero point).
6) Drag selection allowed on some items to speed up editing.
7) Options to view object collisions transformed to object positions
8) Option to use mirrored image of previously created collisions (not really needed but CA uses it on some vanilla settlements)

[wolfslayer]

The drag select feature for wpf is very helpful! I can now "paint" the large areas with my screencap/raster layer method and then do fine editing with IWTE, a big timesaver; going to test the rotation also to create some ambient alternatives ;-)

I have a bunch of these ambients I'm adding or fixing bugged pathfinding for, I just need to upload them all in one package so they load with randomness without becoming repetitive.

I could dig back through this forum to see if there is an answer but the light blue areas signify areas not covering the objects? This screen of swamp_a (I removed the reflective plane with IWTE) is latest editing I haven't tested yet, I'm going to place it on a custom battle map and check out the pathfinding today.

edit: a third step I use is remake a wpf.tga after editing with ITWE and then do a another edit in paintshop to smooth out any "traps" where units might get stuck, then save and create the final wpf file.

[wilddog]

I could dig back through this forum to see if there is an answer but the light blue areas signify areas not covering the objects? This screen of swamp_a (I removed the reflective plane with IWTE) is latest editing I haven't tested yet, I'm going to place it on a custom battle map and check out the pathfinding today.

Hi Wolfslayer. The square boxes show something that is non blank in the pathfinding meaning there is some sort of blockage there. The full green ones are those that are completely enclosed by another pathfinding block. All the others have a colour which implies a distance and facing. The tool can't differentiate where the actual blocking line should run so it goes through a routine which assigns some values (this is much coarser than the original values by CA and probably could be refined. In general it assumes that most of the segment is blocked and doesn't really handle the case when most of it is unblocked. This should mean the units should be less likely to walk into a wall but are more likely to show more disruptions when moving at an angle towards a wall as the path is more coarse.

Hope that explains it.

[wolfslayer]

Hope that explains it.

Yes it does, the "amend pathfinding" in ITWE works quite well. Looking at some vanilla settlements where units sometimes get stuck moving on and off walls I can now see it's directly related to the placement of doors and the pathfinding where the doors are placed. There definitely is some sloppiness in the vanilla settlements, they could all use a going over and some tweaking to eliminate the bugs.

One can view world, pathfinding and doors together if you select change door first, then view pathfinding, then view world, then alter the door placement with its door/world view.

One more question..do you plan in the future to have undocking for the 2d view? It's almost functional now, just the window snaps back when you move it ;-)

[wilddog]

One more question..do you plan in the future to have undocking for the 2d view? It's almost functional now, just the window snaps back when you move it ;-)

The 2D window like all the right hand windows have been undockable since I introduced them. They all snap back when they are positioned close to the initial window though. If you're having problems with it I'm guessing the issue is you can't get the window far enough away or to the right size without it wanting to snap back into place.

On a widescreen or dual screen set up there shouldn't be any issue (Both Mak and I use two wide screen 1920*1080 monitors).

I'll see if I can remove the redocking option as that would probably resolve your issue.

[wolfslayer]

Thanks for explaning that, I had never used undocking and should tried more before posting, undocking works fine ;-)
Tonight I ran into an issue tonight with the vanilla wooden fort se_fort_a, as I was trying to make them a little more roomy. I can't remove any structure without the game crashing when the world model first loads.
I get no errors when saving or reloading the model, and also left the first complex alone. Any ideas what could be causing that, I've done the same with numerous other settlements with no problem. Even removing one small package litter causes a ctd, or any structure.

[makanyane]

Tonight I ran into an issue tonight with the vanilla wooden fort se_fort_a, as I was trying to make them a little more roomy. I can't remove any structure without the game crashing when the world model first loads.
I get no errors when saving or reloading the model, and also left the first complex alone. Any ideas what could be causing that, I've done the same with numerous other settlements with no problem. Even removing one small package litter causes a ctd, or any structure.

if you look at the command box as it loads that one it says

Reading complex 26 from binary .world file.
Reading complex 27 from binary .world file.
Reading complex 28 from binary .world file.
Reading complex 29 from binary .world file.
Reading rest of .world file...
96 Estimated effects header value...
99 Actual six float Header
96 Estimated effects header value...
completed reading .world file. Now doing some internal checks.. please wait
96 Estimated effects header value...
completed *.world file internal checks
Read collision header...
Read collision table1...
Read collision table2...
Read collision table3...
Read collisonvolume central tables...
Read collision last table...
Reading animations
Read header...
completed reading world file

the bolded bit is very bad news

IWTE is probably writing it back with the 96 Estimated value instead of the 99 value (eg the estimated value is wrong....)

this is going to sound very daft but next time you try it as a temporary measure could you try adding a 'Road Marker' using the 'Gameobjects' tab.... then delete a structure and see if resulting .world loads.

wilddog will probably try and find the underlying reason later - but it looks like that must have a combination of things we hadn't yet worked out a six float header value for
(adding a road marker should put it back into one of the known combinations - hopefully...)

[Devils_Advocate]

Short question: Two bridges, one a distance behind the other as part of the only way to the plaza, should work in matter of pathfinding?

[makanyane]

Short question: Two bridges, one a distance behind the other as part of the only way to the plaza, should work in matter of pathfinding?

probably......

[wilddog]

IWTE is probably writing it back with the 96 Estimated value instead of the 99 value (eg the estimated value is wrong....)

Should be fixed in version IWTE_6_2_3 which has been uploaded today.

[makanyane]

I don't think this is actually tool related.... but has anyone else noticed problems with the lighting on complicated (canopies and fences) bits of techtree models that work OK if loaded as settlement structure... but flash from correct lighting to totally shadowed (on lit side) when zooming out, and from properly shadowed to odd texture on reverse side of an object that is now picking up part of adjacent lit side when zooming in on shadowed side....

...seems purely techtree related and isn't to do with any recent IWTE changes.... but am stumped as to reason and wondering if anyone else developing new techtrees has met the problem?



EDIT: Makanyane is a complete and utter idiot

after entirely re-designing the ms3d - then re-designing it again to split into smaller structures to experiment with the complex table1 block relationship... rotating things - un-rotating things.... adding collisions and effects/deleting collisions and effects... trying various versions of IWTE and almost getting wilddog to re-design bits of IWTE it turns out to be...


wait for it:

Spoiler Alert, click show to read: 

I'd misnamed the texture in the techtree version so it had ambient_stone.texture as the normal and as the texture.

Wierd glitchy on/off shadows are apparently what happens when you load the plain texture in the 'normal' slot....

[wilddog]

I was sure I mentioned normal textures somewhere along the line

[wolfslayer]

"IWTE is probably writing it back with the 96 Estimated value instead of the 99 value (eg the estimated value is wrong....)
this is going to sound very daft but next time you try it as a temporary measure could you try adding a 'Road Marker' using the 'Gameobjects' tab.... then delete a structure and see if resulting .world loads."
Thank you Makanyane, I will see if I am capable of that this weekend ;-)

[Devils_Advocate]

No worries Mak, we all are idiots...


PS: two bridges (chronologically) along the plaza path do work!

[wolfslayer]

Thanks fot the wooden fort fix, works great ;-) If you get a chance could you check some of the structures in me_huge_city, the ones with the large minurets, I think some are c 15 s 0, 17 3, and 20 0, to see if there is a fix so they can exported/imported, I wanted to lower them for the pseudo Byzantine cities I've been modifying.