Obsttorte

what I've meant is that antlers normally start where the brows are (and pointing a bit forward maybe) It's like with proportions. It could be a two meter high monster with ten meter long arms, but that would look "unnatural".

to be more clear: Objective 1, hidden, if any AI of Team Haunted, completion target "CT" Objective 2, visible, triggered target_setobj._state (not sure it's the right name) with name "CT" (see above) set it's spawnargs so it changes the state of obj 2 to failed IMO both objectives must be ongoing , try it out

IMO the most easiest way is to make this objective hidden and remove the NOT put a new objective in the map that is trigger dependent if the player is seen than the hidden objectives completes what then triggers the state of the new obj. to failed That'S what I would do if your approach fails (what I can only guess as your last post is a bit ... unclear)

I think the main problem about those antlers is, that they are starting at the wrong place, they should start from the forehead I'm not sure about it, as I saw the first images it reminds me a bit of the tree monsters from T2 which I liked, but this thing looks like a giant rat maybe you can change the face and make it a bit less hairy also the proportions seem not optimal to me

according to what I've read in this thread I'd like to make two suggestions that may help in this issue: the first one was already metioned by someone else before: DR should only save brushes/patches ... that have been changed so it converts everything into the format it needs on load but also keeps a copy of the normal format used in the map files so it can than merge both things together upon saving a second idea is to let DR save a second file in which it stores on which minimum grid size a brush or patch was modified if it than transformes the planes into normal format it can than round the values to an appropiate digit this is a good example for what I mean. if the brush this plane belongs to was modified on a grid-size not smaller than one, the origin cannot have digits behind the dot, so the code would know it has to round it on a min. grid-size of 8 the code would than for example round it to something like 8*X of course this only works with the origin in this way, but IMO also the normal entrees can only take specific values depending on the minimum grid-size used

Maybe it's for saving space

it also gets not extracted here, but that's causing no problems

ask

it definitely does, I checked it.

maybe someone else who encounter this problem may post here and I think there was an example map on angua to check out btw.: comparison with the version before I've changed anything if the user has only one entity selected there will an additional checkbox been shown who says 'keep origin' if this is checked the origin will stay where it is independent from whether the 'origin at (0,0,0)' checkbox is set (I didn't find out how to uncheck one box when checking the other ) as for the other checkboxes the last choice will be saved if there are more entities or only brushes/patches selected this setting won't show up and the option will be ignored EDIT: I've just checked the example map on angua, very funny. I could reproduce the error. What I've done than is to revert it to worldspawn and than convert it back to func_static. This one than was exported correctly.

fixed the problem, wrong indentation (f%&?ing python) EDIT: just tried it out, keeping the origin works nice will merge it into the other

I understand btw.: I just made a script that should export a single func_static and keeping its origin, but it doesn't occur in the scripts menu, although I've reloaded the scripts and even restarted DR. I wanted to test it before I merge anything strange into the existing scripts. Can you tell me what I have to do to gain access. If it works I would than try to add a checkbox keep origin if only one entity or so EDIT: is this texture switch problem still occouring?

:laugh: yup for the center problem, the export script does also work with just patches/brushes selected and therefore must not get a center, and 'use center of first func_static' may be a bit confusing to most mappers (how should they know which one is the first) if restricting the script (or a coy of it) to only one func_static, using its origin may be something to add, as this can be changed rather easy in DR and is quite useful for movers like your lever when working with several funcs or brushes/patches an offset may be the best choice as a further option: - surround the 'object' with the smallest cube containing it - take the point with the lowest x,y,z-values - add the user-specified offset to this value =new origin or maybe an offset from the center, donno IMO a separate script only taking one func_static into account is the best solution here

nice, thanks To avoid misunderstanding, the problem with the shadows where caused by the vertex normals while the dmap error shown above was caused by deleting the line that exports the face normals. So if you relly want to not export it, you'll have to tell the engine that it should ignore it if they're not there.

I see it, the code processing the patches is the same, so are the changes. For the latter, do you want to have something like an offset functionality or is this just for explanation?

during dmap

the only thing you have to do is to add the chackNAN function and to make the change in the processPatch function as described above the code above shows the complete processPatch function so you could also just copy/paste it ??? ??? donno what you want, sorry

I don't understand this sentence

OK, it seems I've fixed it now. But you may test it. The problems are caused by the nan's. I've changed the code so that if any nan's appear they'll be changed to zero. I did this only in the patch part as the brushes seem to work. # new function, checks for nan's def checkNAN(x): if x[5]!=x[5]: x[5]=0 if x[6]!=x[6]: x[6]=0 if x[7]!=x[7]: x[7]=0 return x def processPatch(patchnode): verts = [] faces = [] shader = patchnode.getShader() # Tels: skip if caulk and no caulk should be exported if shader == 'textures/common/caulk' and int(GlobalRegistry.get('user/scripts/aseExport/exportcaulk')) == 0: return if not shader in shaderlist: shaderlist.append(shader) mesh = patchnode.getTesselatedPatchMesh() for x in mesh.vertices: # here goes the change !!!!!!!!!!! verts.append(checkNAN([x.vertex.x(), x.vertex.y(), x.vertex.z(), x.texcoord.x(), x.texcoord.y() * -1, x.normal.x(), x.normal.y(), x.normal.z()])) # here goes the change !!!!!!!!!!! tris = skinmatrix([x for x in range(len(verts))], mesh.width, mesh.height) for x in tris: x.append(shaderlist.index(shader)) faces.append(x) geomlist.append([verts, faces]) return checkNAN is a new Function expecting a Vector that I've just put before the processPatch function in the latter verts.append([x.vertex.x(), x.vertex.y(), x.vertex.z(), x.texcoord.x(), x.texcoord.y() * -1, x.normal.x(), x.normal.y(), x.normal.z()]) has changed to verts.append(checkNAN([x.vertex.x(), x.vertex.y(), x.vertex.z(), x.texcoord.x(), x.texcoord.y() * -1, x.normal.x(), x.normal.y(), x.normal.z()]))

@Tels: yo, just checked the levers. I get drawing errors on both levers, but only on the patch parts. Will have a look.

can you upload the ase file here, there's something I would like to take a look at

well, it seems at least a bit better than in the first shot, or are the Patches used different are the face normals used for shadowing or only the point normals, maybe somethings wrong with the latter

the first case definitely must have something to do with the way the face normals are computed (that doesn't happen in the script) You have three conditions for the normal. Two are that the normal must be normal to the plane, so orthogonal to two linear independent vectors spanning the plane. The third condition is the direction the normal should point to. And here comes the problem IMO. Setting up this problem leads to an linear equation system with three unknown (the entries of the normal vector). This matrix has something that is called condition, what describes the way rounding errors influencing the solution. For the first two mentioned condition one would only write B*n=0, where B is a Matrix containing the first two lines of the full linear equation matrix and n is the normal vector. The rows in B are the two vectors spanning the plane. The higher the difference in length of those vectors, the worse is the condition and the more will rounding errors be blown up!!! The only two ways to bypass this are: (i) make sure the triangles are close to an equilateral triangle (like in the first picture on the left cylinder) (ii) preconditioning the system one has to solve in the code for computing the face normals (or changing the way it is computed) EDIT: I'm not sure that's true but I think the code only uses single precision floating-point numbers, what increases the problem EDIT2: A possible way for preconditioning is to take the second row and multiply it with l1 / l2, where l1 is the length of the vector in the first row and l2 the one in the second. This should decrease the problems a bit.

Instead of using the first vertex normal one could use the average value of all vertices belonging to the specific face If all faces are triangles you have instead of normals += '''\t\t\t*MESH_FACENORMAL {0}\t{1: 10.4f}\t{2: 10.4f}\t{3: 10.4f}\n''' .format(count, x[0][data[0]][5], x[0][data[0]][6], x[0][data[0]][7]) # greebo: use first vertex normal as face normal something like normal_x= (x[0][data[0]][5]+x[0][data[1]][5]+x[0][data[2]][5])/3 normal_y= (x[0][data[0]][6]+x[0][data[1]][6]+x[0][data[2]][6])/3 normal_z= (x[0][data[0]][7]+x[0][data[1]][7]+x[0][data[2]][7])/3 normals += '''\t\t\t*MESH_FACENORMAL {0}\t{1: 10.4f}\t{2: 10.4f}\t{3: 10.4f}\n'''. format(count,normal_x,normal_y,normal_z) # Obsttorte: use average vertex normals as face normals You may test it ase_export_changed.py.txt Hope that's better.