Obsttorte

@Tels: don't know where you're living, but in Dresden there is for example a videothek called Phase IV where the have a lot of old movies (especially Sci-Fi and horror) I guess something like that exists in every bigger city

you may slightly increase the size of the hole EDIT: another point is that there is an animation running when the player mantles up somewhere. So he is not just going elevator-straight ahead like it was in the original Thief games. This can cause the by you mentioned problems if yyour hole or whatever is to close to a wall or another "solid" think because the player then sticks his head into it

for count, data in enumerate(x[1]): 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 normals += '''\t\t\t\t*MESH_VERTEXNORMAL {0}\t{1: 10.4f}\t{2: 10.4f}\t{3: 10.4f}\n'''. format(data[0], x[0][data[0]][5],x[0][data[0]][6], x[0][data[0]][7]) normals += '''\t\t\t\t*MESH_VERTEXNORMAL {0}\t{1: 10.4f}\t{2: 10.4f}\t{3: 10.4f}\n'''. format(data[1], x[0][data[1]][5],x[0][data[1]][6], x[0][data[1]][7]) normals += '''\t\t\t\t*MESH_VERTEXNORMAL {0}\t{1: 10.4f}\t{2: 10.4f}\t{3: 10.4f}\n'''. format(data[2], x[0][data[2]][5],x[0][data[2]][6], x[0][data[2]][7]) Man, I hate python (no datatypes). This piece of code catched my attention (specially the part commented by greebo). I have only a rough idea what is meant by point normal, but I think it is something that depends on the face normals of all neighbouring faces. If so, than the point normal on a cylinder face won't look into the same direction as the face normal. And if these normals are used for shadowing, then this may cause some problems, especially if grid size on triangulation is reduced as the object seems relatively small. (You may check that by recreating the same object the same way but with a finer grid - increased subdivide treshhold as MD told me)

Is the code freely accessible?

Let's see if I understand you correct. If you want to carry a body you first have to 'frob' him and then must 'use' him. You can set the bindings in the options menu. (Beneath polish and english is there another language you're speaking ) I experienced many polish people to speak a bit german and there are a lot of germans in the forum. So if you are a bit common with the language (or another one) it may be a good idea to post in several languages to increase the chance of beeing understood.

I don't see any use of getting damaged everytime I accidently get to close to a torch or a fireplace. I just played DX 1 again where it is that the player get damaged when getting to close to burning barrels and I find it very annoying as their purpose is just decoration.

I didn't have any problems with the ASE exporter either, although I didn't used it very much by now. But I have had similar problems with func_statics: It sometimes happens that if I turn some Brush- and Patchwork into a func_static and use it multiple times beneath each other some of the tris on some of them where not drawn. If I instead turn them into two seperate func_statics and build up the same scenery as before, it works correctly. So maybe this isn't a problem with the ASE exporter but something else went wrong when turning several patches and brushes into one entity Division by zero?! How are these normals computed? If you rotate the entity by 90 degrees and export it then, does it look exactly the same?

that's what I've meant yep, on In the North I searched over an hour for until I realized, that I was in the church, not in the chapel So I misunderstood that, too, what was really annoying at this point but nothing I would blame on the mapper (grayman in this case) This FM here is similar The main problem IMO is that you have a lot of hidden items(keys) you need and therefore lot of room to misunderstand the various number of hints (It also seems to me that shadowhide himself isn't an english native, not sure. So he has to write his hints clearly enough but not too clear in a foreign language and the players have to understand the hints written in a for them foreign language )

very nice post on moddb nbohr Good luck everybody, I hope we'll all be able to produce something great

It's been a while I was playing this mission, but I'm pretty sure there are hints to almost any key or whatever else you had to find (to be fair) they're still there, refusing to die (and still a lot of people liking them, although I wouldn't count myself to them)

That's good thinking. In addition, as I've mentioned somewhat earlier, 100 hours doesn't sound as long as 3 months (what could be the same if the mapper has only a limited amount of time per day/week). This may be a better style in the purpose of attracting new mappers. Yeah, enter ... let us see your magic.

This makes sense if the number of participants is sufficient high. But we could stick to this and say: make it like this if there are for example 3 participants in each category at deadline, and if not rank them against each other. Referring to this Thread it looks like: WIP: Sotha, Fieldmedic Fresh: Thor (maybe), Sir Taffsalot, stumpy, Obsttorte not sure if it makes much sense to rank them seperately I still think that the idea with posting the build time in terms of 25 or even 50 hours is a useful starting point in comparing work (not just WIP and fresh, also three months can mean something completely different in dependence on the mapper) If you think that the working time should not be taken into account, then there is also no need to differenciate between WIP and fresh and we may stick to the Build time in terms of months think or even not mentioning when the building began Personally I would prefer hours or nothing, because the month think doesn't say much Sorry if I repeat myself, but IMO we should decide this before starting the contest (or nbohr1more just decides and post it on moddb )

true, but it was meant more in terms of 25 hours or so (Build time: 25/50/75/100/...hours) excited ... can't wait ... wanna start mapping

It's a difference if you've spent 100 or 200 hours of work, but not if you've spent 110 or 120 hours. So extremely roughly isn't a problem IMO. It's just more precisely then months I guess.

And I always thought this is a statement from people lacking of size. Regarding the build time: One could agree that this is stated in hours (roughly, of course) This may also attract new mappers for the future as "build time: 6 months" may sound a bit distracting for somebody, who have plenty of time for mapping (and may think that the mapper who posted this also has)

I think this build time idea is good, as it's mentioned anyways in most FM posts I guess

I think what Sir TS meant was, that beneath some other facts one fact that counts towards the enjoyment of a mission is its size. So if a voter comes to the conclusion, that the same map in a smaller size would have granted him less enjoyment, and there where pre-existing work on that mission, than this should be taken into account when voting. On the other hand, if the voter comes to the conclusion that the size of the mission (or the amount of readables or anything else size-specific) does have nothing to do with it's "fun-factor", than no, it shouldn't matter than that there was pre-made work. It's up to the voters to differentiate what points because of mass and what because of class

word as far as I got it none of the possible contestants are against pre-made work, so ...

than let all loot in that room target a target_setrelation entity that sets the team_relation to hostile (-1) is this clear now, I'm not quite sure if your last post was a question or a statement

if you want to change the team state independently from wether the player was seen at his theft, than this will work if you only want it to be changed when the AI sees the player stealing the item you may take a look at the example map i've posted in Sir Taffsalot's mapping Thread if you only want the AI that sees the player stealing the item become alerted and that it than alerts other ones, so the player has the possibility to for example kill the alerted ai before it can alert anyone else so he stays out of trouble (uff - long sentence), you may ask and I try to work my magic

I think the particles and lights will make up much more performance problems than the patches but if you really used as much that they cause problems than you may want to convert them to func_static and set "noshadows" "1" "solid" "0" Bikerdude knows much about performance optimization, so you may ask him for some tips

drink your milk

so far it seems that Mr. T and myself are the only ones who would participate with a not yet started map as only two contestants may be a bit boring, we may make a decision at starting day, when we know how many people do take part at all I can understand Sir Taffsalot's points, and would add that the same starting line also make comparision easier and avoid bad feelings maybe some of the others can decide themselves to start something new for the contest, even though they have something else lying around maybe we'll decide this on 16th

just wonder what happens if one opens an empty thread with a poll

that's why there are descriptions one the entities if you are unsure