Obsttorte

We hope so, too. Glad we could help.

My assumption would be that you've build a lot of things out of brushes and patches including small details without converting them into func_static or exporting especially critical ones as models using the latter instead. This can lead to a very high amount of intersections splitting up those brushes and patches that does indeed has the potential to grow exponential. As all of this needs to be stored temporary you probably hit a certain limit within the source code the dmap algorithm doesn't want you to exceed. So my advice would be that you go through your map and start converting detailed geometry into func_static and see what happens if you try to dmap after that.

This is more or less how it works here in germany, with the only difference that the tax rate is applied to the whole income (minus things were no taxes get applied one, like health care payments). But basically you need to earn a certain amount of money per year to have to pay taxes (8400 € or so, not sure) and the tax rate increases with income, but in a way so that earning more money always means that more mones is kept, even with the higher tax rate, similar to your example. We call this progressive taxation, and I think it is a rather fair concept. Another approach that came to my mind is as follows. If you have a basic income, you ensure that nobody has to work in order to survive. So the amount of money they earn in addition serves the purpose of increasing the live standard as mentioned above but is not crucial. This way people could be sharing jobs. I mean, the main intent for this discussion was the idea that in the near future the employment rates may sink due to advanced technologies (although I am pretty sure people have thought so in the past either, think industrial revolution). Nevertheless, if a smaller percentage of employees is needed in a certain area, you could instead still employ all people educated in that area but at a lower work time or less days per year. As said, with the ubi you don't neccessarely have to work 40-50 hours per week to ensure some minimum standards. Distribution of employees among companies could be made by a governmental directorate, based on anonymous evaluation of those companies by their current employees. The better the rating, the better the employees are that they get (better in terms of their marks). This way companies have to be good employers in order to get the best educated employees instead of just having the most money available to pay them. Obviously this is only a concept and something like this can not be established within a short amount of time. However, I consider the question in what direction we want our society to develope to as far more important as the question on whether any concept is compatible with our current economical system. So they basically do what every other animal on this world does. And as you said, most people, not all. Although I am not sure whether this is really true or may only be how your friend experienced it from his or her personal point of view. We have been tought to evaluate a human life by the amount of work that human can perform. I am not sure whether this is something we should be eager to keep. After I made my university degree I was unemployed for a year before finally getting a job. I've spend a fair amount of the time with TDM and how many of the underlying systems work. For an outsider, however, it probably would have appeared as I would have been playing a game, more or less wasting my time and beeing lazy. I don't know whether my perspective is right or the one of the imaginated outsider, or whether it is something in between. But I am also not sure whether it is up to others to tell me on how to live my life and whether they have the right to judge upon its worth. Because in the end, it is my life.

You can raise this argument against a high educational standard, too. If most of the people are highly educated, who will empty our bins? So in return it would just be legit to argument that a certain percentage of the society should be kept "dumb" to ensure we have enough of them doing the unpleasant jobs. Or you could think about a way to make those unpleasent jobs more attractive by providing a reasonable compensation (not neccessarely money). To me, the idea of having a basic income is aiming at two points: Ensuring that each person has a guarenteed minimum life standard, independent from income. The latter only serves the purpose of raising that standard. This would highly reduce the amount of pressure and fears that encompany especially the part of the society that belongs to the lower casts. Providing a fundament that would allow to finally uncouple work from living standard. Your living standard and happyness you can achieve shouldn't be only bound to your job, as the latter only includes what you get paid for, not what you actually contribute to the society.Money is a fictive good after all, it doesn't need to be produced. It has the value everyone believes it to have.

@Biene: There is a 'use entity origin as export origin' setting in the objects exporter which you should activate. This only works if you only have one entity selected for exporting, but provides the highest control over where the origin will end up. In regards to the performance boost note that each brushs and patchs surface contained in one func_static will split up each other which does not happen when exported as a model. This can lead to high tris counts on detail func_static and therefore impact performance. Turning things into func_static only avoids them to split up and be split up by other nearby geometry. The noflood spawnarg works on all sort of entities. It possibly won't work on ai, but definetely does work for func_static. I would second that. I'm no modeler but imho the uv maps don't rely on origin placement, but is stored on a per vertex base.

That would then increase aas creation time, which is an additional step after dmapping. Mappers would clearly see whether the additional time is taken by the dmap or aas creation step. In addition, one can dmap with the noaas command (dmap noaas mapname) to see whether it makes a difference. I also doubt that aas creation raises exponentially with the amount of aas areas to be created, but you are right that it is probably non-linear (very few algorithm are). I guess hte general advice to keep dmapping times low is to avoid detailed stuff to stay worldspawn. Convert it to func_static and avoid brushes and patches with lots of vertices to intersect with each other if they are worldspawn or belong to the same func_static. Exporting detailed stuff as models and use those instead should also help. Monsterclipping should be done a bit generously, as it is better to have few big areas instead of lots of tiny ones. This should also help in avoiding strange pathfinding behaviour, like ai swirling around.

Did you create small details out of tiny brushes or patches. Lots of intersections can increase dmapping time and even cause crashes. Back in the day when I was working on my first mission I created a girder out of brushes (didn't knew about alpha-testing at that time). A simple 32x32 doom units sized girder caused the dmapping time to increase from around 10 seconds to more then five minutes.

Yeah, flickering gui indicators. Gimme, gimme, gimme

The problem here is that the gui doesn't support any way to merge two strings together. So if you want to combine two strings, like dmw is, you can only go the way of using two window definition, each containing and displaying one of the strings, at least for guis like the mission loading gui. Once you are in game, you can use a script to combine several strings together.

The problem I was refering to isn't neccessary the way they sold the game, although I am no fan of that either. I've bought it as a boundle after all missions were released. The problem I have with this Hitman is that it's simple not a good game. And you stating that "it's not bad" does sound like you've played better games, either.

This is imho more a point of bad level design then an issue with the core mechanics. And yeah, my first mission released has such areas, too. Each and every mechanic can be exploited if misused, especially if a mapper is not paying attention to those things and that fact. The purpose of any game mechanic should be to create an entertaining and preferable challenging experience. Boundling that up in a way that is immersive is the job of the mission author. Note that we are talking about a game here, not a simulator. And note that immersion is not the same as realism. The game should present itself in a way that the player believes it could be true, not in a way that equals to the true world. Flaws in mission design like quoted above obviously break that illusion, so they should be avoided. But as we are no professionals they will occour every now and then.

By the might of the Holy Builder, nooooooooooooooooo.

I would expect the rope arrow to get ripped out of the banner once I attempt to climb it, but I am maybe a bit heavier then you are

Upper right corner, the field with the string search in it that's mission related issue, not a problem with the core game concept so you answered it on your own and if the mission authors are interpreting this in different manners, what is very likely, you'll get unpredictable and ununiform gameplay across the game, perfect. Not to mention that as per your suggestion mappers would have to define those spots where this behaviour should be applied. Sounds tiresome. whether it is neccessary in the current configuration is discussable either (hence it is toggleable), but despite that it doesn't sound like you are making this propose to reduce the hud this is wrong. You visibility in real life, as this is what you are seem to be referring to, doesn't only get affected by the brightness of the area behind you. Normally the major impact comes from the lights that is hitting you, independent of its origin, may it be behind or in front of you. This is what the current implementation is based on, as it is in almost all other stealth games, and it seems to work out pretty well. Besides the fact that sarcasm really won't help you motivating any of the team members to apply any of your suggestions, you didn't get the point. Noone says that simulations can't be entertaining, I for one love playing them. The point is that TDM isn't a simulation. Of course you can go on and create a thiefing simulation that aims to reproduce reality, but that has never been the goal of TDM. Something like this can easely be applied by mappers by placing additional light sources in that area that only interact with the players lightgem. The player can't see it, but it lights him up. I don't see how this is closer to what you were thinking, though, as you are talking of silhuettes and background brightness, so visibility that depends on from which direction the player is looked at, which won't apply here in any way.

Rope arrows deal a small amount of damage, water arrows don't iirc. Adding features like this to already existing arrow types in the core mod is a terrible, terrible idea. It will affect all existing missions. As said you can add all kind of crazy stuff to your own fm, but things that are intented for the core mod really needs to be an enrichment for the gameplay, and I can't see how this is the case here. If you want a cheap arrow that is able to take out guards at the distance but requires you to shoot at the ai's head, use the broadhead arrow. That is what it is for.

The only surface rope arrows stick to is wood, as otherwise the player could shoot them into a carpet hanging at the wall for example and climb up there, which is neither what most players would expect nor very believeable. Of course there would be the more elegant solution of having the rope arrow stick into the same materials as the broadhead does, but only deploy the rope on hitting wood. This would require changes to the scriptobject used by the rope arrow. I guess it was done that way asit was the more straight foward implementation.

I don't think that this is a sufficient reason. I bet there are many players like me who don't care about their stealth score, similar to how they don't care about steam achievements and the like. Having the ai wake up on its own is definetely pretty pointless for the above mentioned reasons, but allowing other ai to wake up unconscious ones can be an enrichment, as demonstrated in several Splinter Cell titles where this was the case. I always find it funny if it is stated that we don't want to encourage the player to kill the ai, if on the other hand we are handing him broadheads, a shortsword, fire arrows and explosive mines. As stumpy has written the main difference between dead and unconscious ai is how they are labeled. No, the main reason imho is that the implementation would be rather difficult and would consume a lot of resources, as well as the fact that it would affect existing fms and would therefore require a lot of testing to get it to a point where it is working in a satisfactory way, without any guarantee that in the end it would actually enrich the gameplay. But as it has been written this has been discussed pretty often already. So I may ask new forum members to think through the following points when having a "new" idea: someone else may had it before, so check the forums on whether this has been discussed alreadyconsider that there might be a reason why it hasn't been implemented already besides the lack of creativity you may expect among the teamcarefully think through what needs to be done to get "your idea" to work, in this case for example: coding, new animations, new barks, error tweaking, ...the chance of something you propose getting added to the mod is proportional to your capabilities of adding it on your ownAnd btw, there is a "Things that could be improved"-thread for ideas like yours, so there is no need to open up a new thread for every thought of yours (yeah, that is a minor thing, but it really bothers me and I felt it needs to be said, although others may disagree, so don't take this personal)

It's been a while since I've last played Thief 4, but I am pretty sure that isn't correct. I remember guards looking inside the cabinets. Maybe you were playing on a low difficulty (I've only played the highest) or this is something that has gotten patched away later on. However, I've played the game two or three times, so although I agree that it has its weeaknesses, it can't be that bad after all It received a lot of criticism, but lots of the things criticised can be found among TDM fms either. I think the main issue with it is that it was designed for a way to big customer size, as for whatever reason everything produced today needs to be AAA. Five years of development and a team of 100+ devs if I am not mistaken made the development surely rather expensive, and the sells simply didn't suffice to render it a financial success. A smaller team, a shorter development cycle and everything aimed at a smaller audience would have probably been the better approach.

The amount of numbers doesn't limit the amount of weapons, as you can cycle through them. However, mappers are free to exchange one weapon with another. If your mission doesn't feature fire arrows for example, you can use its slot for your custom one. Most missions only feature a limited amount of the weapons belonging to the core mod anyways, and most of the times most of the weapons featured are unneccessary to finish the missions, as they often just got added because the mappers thought it would be good for the players to have them, without creating situations were the player really needs them. So as long as most mappers create missions that are designed to be ghostable any discussion about adding new weapons or tools that don't get used anyways seems a bit pointless to me. Just my two cents, though.

Summary: Bikerdude has been banned.

I don't think that the gui interpreter automatically converts file types. So, although I haven't tested it, I would assume the right syntax to be (scrap that, doesn't work) In addition I am not sure whether concatenation is supported, so you probably have to use two windows here. EDIT: After some testing and additional google-search I am quiet sure concatenation isn't supported. So you have to use two windows.

The "correct way to approach this" is to checkout the wiki, that's what it was designed for http://wiki.thedarkmod.com/index.php?title=Loading_Screen_Text http://wiki.thedarkmod.com/index.php?title=Mission_Title_Screen_while_Loading

You don't "use" the matches. You drop them into your hand and move them around so that the glowing end is close enough to the extinguished fire source.

There is no need to make a crafting system part of the core mod. It simple is not neccessary for the basic stealth gameplay. Of course, every mapper who considers this feature an enrichment for their specific fm may add it, and it wouldn't be overhelmingly difficult to implement either. But like lots of other stuff (like open world for example) this is nothing that is good or bad per se. It depends on how it is used.

The damage response will respond to a damage stim received. If nothing happens my assumption would be that weapons do not send any of such stims. I would guess that the collision model is required for the entity beeing able to be damaged. I mean the whole weapon system works with collision. However, when weapons are hitting buttons they normally activate them. So you could bind an invisible but solid func_button to the upper end of the rope that could take care of the rest.