IWTE - World editing - (General Discussion)

**alreadyded** · July 02, 2012, 04:12 PM

Yup, that did it. Thank you. I LOVE how all my problems are solved in one click of a button

. Very well made tool.

**wilddog** · July 10, 2012, 03:04 PM

Originally Posted by alreadyded

Yup, that did it. Thank you. I LOVE how all my problems are solved in one click of a button . Very well made tool.

Hi thanks for that alreadyded. I know there are some bugs .. keep coming across a few now we are revising some elements of the tool. Please let me know if you come across any issues..

Note we are progressing well on the revisions but still cross testing to make sure its not picking up more bugs.. Makanyane found some faults (and let me know

) and I found a couple of issue but were somewhat more obscure.

I've also added in the option to make walls non breachable (in AI terms) as Mak was fed up editing it so that's another new feature coming soon.

**Red_Devil** · July 13, 2012, 01:24 PM

Keeping silent, but making some progress. The generic buildings take an awful lot of time to build... Especially texturing, but I'm getting faster

.
This us going to take me eternity to finish, literally.

**wilddog** · July 14, 2012, 09:37 AM

@Red_Devil - yes unfortunately they do take time. I think some of the people have no real comprehension on how long that can.

I've finished some tidying up on the worldpathfinding and worldvegetation files.

Creation and reading the TGA files is much faster now (ie everything is a few tenths of a second even for the creation of 20-30MB files).

I also added (on Mak's request) a feature when resizing the vegetation files to pre-populate any increase in size with the grass entries (that's the vegetation TGA4 files).

**wilddog** · July 16, 2012, 02:47 PM

Hi
Testing seems to be going fine now that some earlier issues have been resolved.

I want to amend the routines for extracting data for milkshape to see if they can be improved. Mostly thinking about properly addressing the objects which overlap structures.
Other than that .. but connected .. there is a bit of a rewrite simplification to do associated with the load and unload to milkshape.

I expect to release a new version in August (work permitting).

**Red_Devil** · July 16, 2012, 03:20 PM

Hum, I've had some issues with milkshape and the texturing: one my building are textured in milkshape, I position them and to do so, I have to rotate them. but the texture goes kind of rogue: it turns darker and in game it keeps this shade problem. I can upload screenies if necessary.

edit: damn it

, i've been searching on the net for days and solved this by clicking on auto-smooth when I didn't itended to... I'll check if it works IG tomorrow

by the way, i suppose any new version of the iwte tool is "save-game" compatible?

**wilddog** · July 17, 2012, 01:44 AM

Originally Posted by Red_Devil

by the way, i suppose any new version of the iwte tool is "save-game" compatible?

yes, there should be no issue on that... part of the checking process added (but now redundant) was to self correct some earlier issues. Now that its been so long since those very early items were issues they aren't relevant anymore.

**Red_Devil** · July 17, 2012, 05:53 AM

I've had a weird error message on the console recently, eventhough I managed to bypass it, i do not understand it: it says "unicodedecodeerror: 'ascii' code can't decode byte 0xe9 in position 69 : ordinal not in range (128)

**wilddog** · July 17, 2012, 11:39 AM

@Red_Devil - that looks like a read issue or something not set right. Without seeing the rest of the error message I can't really resolve. Problem is the code has moved on quite a lot since then anyway. I have come across a few bugs on the way and resolved them but whether that's the one you hit I don't know.

Best is to highlight as much of the preceding info that is displayed in the console window and press return to take a copy and then stick that into a thread here or PM me with it. I may need the model to reproduce correctly but at least that would indicate where the error is.

**Tellos Athenaios** · July 17, 2012, 03:52 PM

Looks like binary data is dumped into a string but treated as though it were ASCII (likely), or alternatively the model contains valid strings in some character encoding that isn't ASCII.

See: http://docs.python.org/howto/unicode...e-unicode-type

**Red_Devil** · July 18, 2012, 12:13 PM

Well, I guess it's a bit complicated to understand. since it's not a problem anymore...

Two questions: I've made my outter ring wall and it's perfect but for two things, I managed to understand the deployment block thingy, the gates have no more secrets to me (perhaps a bit ambitious to say so, but still, no more bugs) and wall animations works fine, ...

BUT

(there had to be this word)

- the animation works fine for the wall. I use a vanilla citadell wall (3 squares) with King kong's mt_small_walls texture, the whole thing changes appearance during animation phases: when the wall crumbles, it takes the vanilla texture and then gets back to mt_small_walls. I guess I can't import KK's minas tirith animations since it's a huge city wall 4 square high...

- the deployment block works fine, but I can't add more than one object per deployment block because of "points are not shared" or something like that. do I have to merge one vertex at least from both objects?

**makanyane** · July 18, 2012, 12:52 PM

excuse short answer am trying to do something else on other screen...

- the animation works fine for the wall. I use a vanilla citadell wall (3 squares) with King kong's mt_small_walls texture, the whole thing changes appearance during animation phases: when the wall crumbles, it takes the vanilla texture and then gets back to mt_small_walls. I guess I can't import KK's minas tirith animations since it's a huge city wall 4 square high...

copied off earlier answer;

Originally Posted by me

http://www.twcenter.net/forums/showthread.php?p=9285933&highlight=anim+texture#post9285933
that was written before the addition of some more IWTE features

basically you need to make a copy of the animation folder with a new folder name - use 'Collision/Anim' and
'edit animation tga paths' on all the mesh's in the new folder - and with your .world file loaded in IWTE you can use 'WorldFiles' 'update animation paths' to redirect the animation to your new folder name/path

- the deployment block works fine, but I can't add more than one object per deployment block because of "points are not shared" or something like that. do I have to merge one vertex at least from both objects?

you do need to make sure they are same height and are close enough together using ctrN or other allignment tools in milkshape to get them alligned might help - you obviously don't want them welded as the verts need to be in different groups.

also make sure you're adding them in order - i.e. the second one is next to the first one and not somewhere further down the wall...

------

on earlier stuff about error message - do beware about continuing after an error - though if it re-loads in IWTE and you've tested in battle I assume it's OK... did sound like some of the binary stuff was either too long or too short so was appearing in an area where the tool expected text, which is generally not a good sign!

**Red_Devil** · July 18, 2012, 01:25 PM

thank you for your time

the wall animation works just fine now, but for one thing: when the animation plays, the sunlight goes right through the building.
will now try the deployment block part.

edit: great! it works! it's a pretty tedious job, but worth the time.

I understood what you told me about the veg fiiles: to take all the trees and grass off, I took the two TGAs, group 3 I painted all in black and group 4 is entirely transparent. but I still get a few trees here and there. is it posible to remove those survivors?

**makanyane** · July 19, 2012, 01:50 AM

Originally Posted by Red_Devil

I understood what you told me about the veg fiiles: to take all the trees and grass off, I took the two TGAs, group 3 I painted all in black and group 4 is entirely transparent. but I still get a few trees here and there. is it posible to remove those survivors?

did you remember the bit I said about the veg files only apply at the same rate as the terrain file (base.tga bit's) merge value?

assuming the trees are coming up around the edges then it's probably the merge through from what would have been on the battlemap if the settlement wasn't there. You should be able to enforce 'no trees' if you make the alpha layer of the terrain base.tga completely white / all terrain merge value 1 / have no transparency at all in that tga (depending on what you're editing it in)

if you do that totally up to the edge you'll get a cliff in the terrain though...

I need to have a look at the texture/anim with light going through thing - am fairly sure my custom ones don't do that

EDIT:

group 4 is entirely transparent

wilddog just pointed out that this might not be correct - it needs to be completely black to get rid of the trees - the transparency isn't picked up from this one...
green = trees, black = no trees - transparency doesn't matter. get rid of the transparency and check the colour...

(sorry)

EDIT2:

but for one thing: when the animation plays, the sunlight goes right through the building.

nope that definitely doesn't happen on mine... and the one thing I thought might duplicate it (not having the .mesh files in same folder) just results in no animation!

are the anims and textures all still in /blockset/ ? and do you have anything it might not like in the revised path names, i.e. a space??

**Red_Devil** · July 19, 2012, 10:17 AM

the tree thing worked perfectly. the transparency is indeed not needed.

will check the animation glitch, but it's not too flagrant.

by the way, impressive job on king's landing!

**wilddog** · July 19, 2012, 02:42 PM

Hi - I just kept to the same TGA format for simplicity (ie always with alpha). kept things simpler for me.
May amend that now I've changed the basic coding to at least check for the format type.

@Tellos Athenaios - I assumed asking for a description of the cause was better than trying to explain the symptom. It's likely that something went wrong in the read processes that was unexpected and I never bothered with putting in too many cross checks as it slowed things down.

It was simply a tool for me and Mak to get on with our mod which we made published as an executable.

**Red_Devil** · July 23, 2012, 04:23 AM

I know what went wrong with the code : the language error came from the fact that as a frenchie i use é, ê, à, ï etc...

it seems the world file doesn't like it or the IWTE do not know those letters.
I believe it comes from this, since when i renamed my files, they worked perfectly.
visual studios is to thank for this, I was configuring a programm and had the same mistake

by the way, what is the purpose of a complex, can't i just make the whole world into one complex with all my structures? is it only to organize my settlement a bit more clearly or?

also, I just released a small preview of the settlement here

**makanyane** · July 23, 2012, 06:38 AM

thanks for the info on the language issue, that explains that one

Originally Posted by Red_Devil

also, I just released a small preview of the settlement here

wow! that harbour is looking great, well done

Originally Posted by Red_Devil

by the way, what is the purpose of a complex, can't i just make the whole world into one complex with all my structures? is it only to organize my settlement a bit more clearly or?

well it's the way the original files work - so we assume it's advisable to make custom settlements in the same way.

as background; in 3d stuff generally bounding spheres and bounding boxes are used to help tell the computer which bits need to be rendered to which level of detail / which collisions need to be checked etc.
I think that is part of the purpose of the split up into different complexes.

there are bounding spheres for most things (each collision, each structure, each complex and one for the whole settlement) - the only things that have a bounding box system as well are the complexes.

Each complex is assigned to one node of an octree structure - see Argantonio's explanation
http://www.twcenter.net/forums/showt...ee#post4273886
for the .world it's and 4x4x4 cube set up - those are the positions you view under 'Structures' 'View Table 1 blocks' - if you compare them to the views of an individual complex in one of the original settlements you'll see CA divided them very precisely.

Each complex in the .world file also has a list of 'effects' from adjacent complexes, which seems to do something to help keep the lighting correct - before wilddog got IWTE to reset those properly we had problems with bits of structure turning pink and animations turning white

I've not tried having a very large settlement using only one complex - it might work, or you might find you've get graphics overload type problems... the trouble is you're only likely to find out when you've got most of it done and collisions and effects in!

The one thing I have definitely had problems with is when I had very mixed up multiple complexes (so there were very large areas of overlap between the bounding boxes for each complex). That gave a minor but very irritating graphics bug where a vertex from one complex would appear to get linked to a different structure (and flash on and off) in game.

Having only one complex is probably safer than having very messy overlapping ones, let us know if you try!

**wilddog** · July 24, 2012, 02:00 PM

Originally Posted by Red_Devil

I know what went wrong with the code : the language error came from the fact that as a frenchie i use é, ê, à, ï etc... it seems the world file doesn't like it or the IWTE do not know those letters.

Thanks Red_Devil at least that confirms the issue in line with Tellos Athenaios explanation. I was assuming it was likely an issue around when a structure is expected to be the 2nd structure but is actually currently the first one. Its tied to deleting objects in the wrong order.... shouldn't of assumed that

Good news is the updates are progressing OK and I think I've addressed the majority of the 'slow' processes as they relate to read/write files. All the TGA read and writes are pretty acceptable as most are now below a second (on my PC) no matter how big you make the terrain. Basic read and writes are reasonably fast also so the NE Fortress now takes around 3.6 seconds to load all 3 files..... given that just over 2 seconds of that is still just some internal checks tied to the world file (which are repeated a couple of times) it should be acceptable but I may improve further as it is still a more complex process for the checks than it needs to be. Mak uses a machine that's 5 or 6 years old so takes about double these figures but is still pretty reasonable. A 3d View with full textures of the fortress now takes just under 4 seconds to load (after reading the files) and around 5 seconds with the terrain.

Unfortunately not sped up the algorithms around the deployment blocks yet and still have some testing to do (3d view needs light direction sorted out).