Dragofer

From my perspective it should only remove savegames - at the moment I can't think of any more files with significant weight that can be safely removed. Maybe previous devs had a reason to delete more files, but tbh it doesn't really seem thought through. The purpose of this button seems to be to reset the FM folder to the state as if a player had just downloaded the .pk4, ignoring the possibility that it could be a WIP FM. Tbh if it only removes savegames the feature could just as well be removed, since I don't think their file size matters anymore - the GUI would be a little bit cleaner. I don't think we've had problems with bloated savegames for a long time.

I'd say so, but speaking against this are: cabalistic's concerns that this cvar setting causes a performance loss. Aluminumhaste says he hasn't seen such a loss so far. some vague reports of graphical glitches with this cvar setting

The immediate question is, is there anything special to consider when trying to recover files that have been deleted by a program instead of by the user himself?

This seems to be the effect of the "Cleanup" button in the mission list, which Neonsstyles said on Discord he used. Judging by the text it sounds like it should mostly just delete savegames that accumulated while playing, but in fact it deletes almost all files that are outside of .pk4's. This thing is a landmine for a mapper, and now someone has stepped into it without making a backup. Reproduction is easy: 1) Go to your darkmod/fms/stlucia folder and extract the .pk4 (so you get darkmod/fms/stlucia/maps etc.). 2) Open TDM, go to the missions list, click on Mission 2: St. Lucia and click on "Cleanup" and then "Delete". 3) Go to your darkmod/fms/stlucia folder again, now almost all the extracted files outside of the .pk4 have been deleted.

It's easiest to move over stairs when their steps are blocky in shape, so for more detailed modelled steps you could encase each step in a brush textured with a textures/common/nodrawsolid_stone, _wood or _carpet texture. I wasn't aware most staircase models need this, however. Regarding maximum step height, the value I remembered is 14, while 12 is easier to work with on a 4-unit grid.

LOD entities are basically just func_statics with pre-applied LOD spawnargs unique to that model - so the LOD attributes can already be applied to func_statics. The LOD entities are just needed to store these spawnargs. What could work is to introduce a new type of file, .lod, which would assign default LOD properties to models. This way any (func_static) entities with these models would automatically exhibit LOD behaviour. LOD entities would become redundant. Yes, this sounds very good. Some more brainstorming to refine the concept: - would be good if deprecated entities (mostly light sources) were excluded. Without seeing the entity tree view or folder path, you have no way of knowing that an entity has been deprecated. - it'd be helpful if entity descriptions were shown in the model browser when an entity is highlighted. Maybe they can take the place of the material or model stats, if they're available. - the old search method (type in a string, then press arrow keys to jump from result to result) might need some refinement to stop it from expanding so many nodes in the process. There will be more and larger expandable nodes if entities are added.

@kingsalrecently noted that the frob outline made the secret switches in his Volta 1 more visible than intended. I don't know the coordinates for them, but there's an AI (IIRC with a scroll on his belt) who patrols to all the switches. One of them was in the big library. Well, maybe kingsal can get the actual coordinates?

It's important to distinguish between 2 different things being discussed in this thread: 1) What geegee mentioned in the recent posts: the new frob outline makes it easier to find items that are hidden behind other items. It's mainly a concept problem: the outline should use a depth test, but cabalistic says it's either too expensive or too work-intensive to implement that. The alternative would be to implement a depth test for frobbing, but imo that would break a TON of missions since you're probably not always going to have a line of sight when trying to frob something in i.e. a frobable chest. 2) Visual glitches like what MirceaKitsune recently posted on Discord: As far as I can remember, most mentions of such visual glitches in this thread were only vague and without reproduction steps.

The question is, would it be possible to store these LOD distances within the model file? Currently the entityDefs store this information and are therefore a necessity. It should not be necessary for mappers to tweak the LOD distances themselves when they use core assets. Yes, the trees aren't designed to be combined, so they'd need to be kept separate anyway. Personally I'm somewhat wary of merging models and entities into a single giant browser since for me their purpose is overall quite distinct (map decoration vs. implementing functionality) and searches could return many results that aren't relevant to what one wants to do, but I could imagine it happening if done well. There are quite a few entities that fit into the "map decoration" category, so it'd be good if those were visible together with the other decorative items. For me the biggest gain would be if there were better integration between models and entities, so models in the model browser would link to entities that use such models. It would mean the mapper can decide whether he wants to create a model as a LOD entity, a moveable item, a func_static etc. Maybe it wouldn't be necessary to merge the 2 different browsers to achieve such linking.

Entities can only be created if (A) the entityDef contains a model or (B) you have a primitive selected which will be used as the model by the entity. Otherwise (C) change the classname of an existing entity, i.e. a func_static model. So there are these methods: Open the Model Browser, use it to create the desired model as a func_static. Then use the "classname" spawnarg in the Entity Inspector to open the Entity Browser and select the func_rotate entity. Draw a brush/patch, open the Entity Browser and select the func_rotate entity. The brush/patch will become a func_rotate. Open the Entity Browser, select an entity which inherits from func_rotate and has a model. Yes, this is a concern. I believe earlier proposals for an integrated asset browser were intended as a kind of clipboard where mappers could include their favourite assets (models, entities, skins, materials) for faster access. Basically the mapper would already know the purpose of each item. The problem is more that using LOD requires an entity from the Entity Browser, while mappers mainly use the Model Browser for decorating and are therefore prone to creating single LOD stages as func_statics. For me it's currently an interface and accessibility issue with how LOD models are organised and added to the map. As per HMarts' suggestion, it'd be nice if models could contain LOD stages within themselves, but considering the need to individually finetune LOD distances for each stage of each model to minimise the obviousness of LOD popping, I don't really see a way around having an entityDef for LOD entities. It'd reduce clutter in the Model Browser, but many LOD stages are already quarantined in the models/darkmod/misc/lod folder.

Currently the components that make up a LOD-enabled model are usually stored in various different places. Taking the aphrodite statue as an example: - The most detailed model stage is found in darkmod/decorative/statues. - All the other stages are found in darkmod/misc/lod, probably so that the decorative statues folder is less cluttered. - The LOD entity that makes use of all these stages is in a different menu altogether, Create Entity > LOD/decorative/statues. I've seen that a lot of the times, even though a LOD entity is available for a particular model, mappers just use the most detailed stage in a simple func_static, missing out completely on the LOD optimisation. I suppose this is because mappers mainly use the Model Chooser instead of the Entity Chooser for decorating the map and don't realise how the LOD system works/forget to check every time whether a LOD entity exists for any of the models they create. Some possible ways to address this: - Let the Model Chooser check whether there's a LOD entity that makes use of a model the mapper is about to create. If yes, it could create that entity instead of a func_static. - Wellingtoncrab suggested an overhaul by combining the Entity Chooser and Model Chooser into an integrated asset chooser which could show flags for certain models, i.e. LOD. This would also make it easier at a glance to see what's available.

If anything, going against the notion of climate change would be the money maker. Industry has a vested interest and practically infinite means to influence politicians and public opinion that nothing ought to be done, and writers like Lüning have a personal interest in "exposing" climate change (or vaccines, for that matter) since it has significant potential to become a bestseller book. On the other side you have the interest of media to publish click-bait articles, i.e. I was quite disappointed to read in the fine print that National Geographic's April 2020 article "See how your city's climate might change by 2070" was based on a worst case scenario. This is a general problem of relying on second hand sources like newspaper articles for learning about complex issues. This is an important reason to be scientifically literate and read the research articles yourself in the context of other research and with an eye for flaws. Scientists have formal training in this and comprehensive knowledge of their field. So when the majority of climate scientists agree that climate change is man-made and a major problem for humanity's future, this carries much more weight for me than what commentators in a newspaper or a fringe website have to say. Granted, scientists have a conflict of interest when they receive funding for their research which, at least in medical research with ties to industry, is associated with lower methodological quality and higher odds of the conclusion being favourable towards the sponsor. The question is, do politicians actually have an interest in climate change being a major problem? Policy that would adequately address it would be highly unpopular both with the donor class and the general public, since - very understandably - most people don't want to give up a significant part of their living standard. Failing to implement such policy, on the other hand, causes politicians to lose their credibility in the view of climate-conscious voters when they consistently and spectacularly miss their own climate goals. That seems to be the dynamic at least in Germany, where the only party that more than half-heartedly campaigns on addressing climate change historically had little say in running the country or financing German climate research. What I think is valid criticism is the validity of climate models to predict what will happen in the future, since the climate is incredibly complex. However, for that reason, I think the statements "climate change will be a catastrophe" and "climate change is just hysteria" are equally uncertain. What we do know for certain is that atmospheric CO2 is rising rapidly, acts as a greenhouse gas and the resulting temperature increase has a highly plausible causal relationship with many of the climate developments we're witnessing.

That might be the best way to get the exact features we want, once we've agreed on them. This looks to be the documentation for making own plugins for these forums: https://invisioncommunity.com/developers Maybe it's something you or someone else can work with?

@OrbWeaver Maybe you'd care to elaborate on what your standard of evidence is? We have abundant documentation of a decades long rise in frequency and severity of all kinds of extreme weather events, rising temperatures, sea levels, greenhouse gases etc. etc., as well as broad scientific consensus on the causal relationships between many of these phenomena.

@SeriousToni No, you're the first person who actually said they'd offer a contribution towards these. Will have to consider whether these plugins do what we want (ignore topics and complete ignoring of users). The 3rd plugin seems to combine both of these features and more at half the price of the other 2 plugins, but one of the reviewers said they had to stop using it because in certain threads it would hide everyone's posts regardless of whether they're ignored. The other 2 plugins seem to have fewer features that we might want, such as completely removing ignored posts instead of asking whether you want to show them anyway. Maybe there are still more plugins on that marketplace.

Just to emphasise the new prefabs by Wellingtoncrab: This pack has of course been added to the core assets for 2.10 and will be available with the next dev build. Note that players on pre-2.10 builds won't have these assets, so it might be a good idea to keep the above pack in your FM archive. Otherwise you can make your FM 2.10-dependent by adding this line to your darkmod.txt: Required TDM Version: 2.10 P.S.: now wardrobe1 is next

Could be that the script event expects 0.50 instead of 50, it's not immediately clear from the code. IIRC the AI spawnargs work with 50.

@geegee It's been a thing already in the original Thief games that your sword and your bow slightly brighten your lightgem, while your blackjack doesn't. This is especially pronounced when equipping a fire arrow, since it glows in the dark. Something worth considering if AIs seem to see you too easily is the intensity of your ambient light (for that location). My personal preference is a relatively dim colour setting of 0.06 0.06 0.07. Note that if you have a large location containing many bright lights, the ambient light intensity is dynamically increased to match. You can disable this dynamic via a spawnarg on your info_location entity.

@Wellingtoncrab Sure, I'm always open to creative reuse of good furniture textures. And all assets that get included into core should be vetted and made consistent with existing conventions. Then it's possible that not just patches, but also brushes were affected by the bug. Each triangle in the model becomes a standalone surface with 3 unique verts, which can easily double the total vert count for a model. If you've still got the original brushwork I could use that to open a bugtracker ticket. It looks like Greebo's doing a models-focused update for DR 2.14, so it'd be a good time. Btw, it'd be nice if the hutch had a few prefabs. Maybe 1 could be what you showed in the screenshot, another 1 with some plates on display and so on. (Yeah, I should probably have made more than 1 prefab for desk3 so we don't have the curious situation where every noble now has a model ship in his desk vitrine).

I've seen froblock entities, usually forming chest bodies. Maybe that's what was meant in the other thread with entities that block frobbing through them?

I'm not aware of instances of target_setfrobable acting as an invisible wall. For example, what I did in Down by the Riverside to stop the player from carrying bodies on his shoulder into the next phase was to place a large target_setfrobable brush (textured with clip) in the room that fires the moment the teleportation is triggered, making everything in the room unfrobable. The brush didn't prevent entry to the room. They can only control frobbing by being triggered when the player is in a position where he should/shouldn't be able to frob the items, by making all items within their volume frobable or not.

Monsterclip is a special case since it only has any effect if on a worldspawn brush. The other clips simply offer collision regardless of whether they're on brushes/patches/models. Some entities such as setfrobable make those nonsolid so that they instead act as a way of detecting which entities are within a space. I wouldn't see a need to use a different texture for these entities since you can have as many as you want in your map without inadvertently affecting other things. I do agree it's annoying that clip entities are treated the same way as ubiquitous worldspawn monsterclip by DR filters.

You can use setAcuity("type", number) in a script, where types can be "aud", "vis" or "tact". So like $ai1.setAcuity("aud", 50); The risky thing about doing something after a conversation is that the conversation can get interrupted and the thing never happens, i.e. the AIs stay blind and deaf. So you'd need to put the script events on a timer that begins with the conversation. But if there is/will be an official fix, then adding your own scripted method on top might be too much of a good thing.

Great work, nice to see the cabinet1 series continued! I've done the preparation for assimilating them into the core assets by renaming them etc. and have the following remarks: - If you don't mind, I've used Blender to extend the wave-shape of the hutch's drawers to the surfaces immediately above and below. - It looks like you've exported these with a slightly older version of DR? This is because the models suffer from the excess vertices bug that was patched in one of the more recent DR versions, which can affect shading. I've fixed that in Blender. - The small table seems a little high compared to other tables, which could result in clipping with AIs sitting at them. To be sure I've lowered the tabletop from 39 to 37 units. - In skins, it's good to get into a habit of putting model paths and material names into quotation marks. This ensures you never get problems with unusual symbols or unintentional keywords. I'll share my local version once it's all done. By the way, make sure to check the desk prefabs, since you can find a complete and decorated version of desk3 with all moving parts there.

Btw, an interesting thing I found out when I answered my own question before posting it: you can use an * in skin definitions. This makes it really easy to swap all the materials of any model with only a single line: skin invisible { * "textures/common/nodraw" } Where * is the material to be replaced ( = any material ) with textures/common/nodraw. Or something like textures/darkmod/decals/* if you want to get rid of all decals on a model for performance reasons.