[[ 2.10 ] New Frob Shader]

2 hours ago, duzenko said:

Am I correct that if that cvar is in the 'right' state by default then the issue is fixed?

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

[Dark Mod Just Deleted my entire FMS\Venice folder and eveything in it]

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?

[Dark Mod Just Deleted my entire FMS\Venice folder and eveything in it]

1 hour ago, duzenko said:

Unless you can reproduce the deletion there's nothing much to fix

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.

[The Case of the Unscalable Stairs]

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.

[Making it easier to use LOD models]

1 hour ago, peter_spy said:

So instead of having a separate "LOD entity", it would be better to have these attributes either moved to func_static class already,

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.

 

10 hours ago, OrbWeaver said:

That would be an option too, and I think it could be achieved with the existing interface. We already show available skins as children of model nodes, so we could show entities using the model as children too.

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.

[[ 2.10 ] New Frob Shader]

@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?

[[ 2.10 ] New Frob Shader]

On 9/5/2021 at 9:15 PM, duzenko said:

Is there a simple way to reproduce the whatever bug some people think the frob highlight has?

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.

[Making it easier to use LOD models]

On 9/5/2021 at 3:50 PM, HMart said:

Afaik there's nothing preventing you from being able to tweak each LOD distances individually using the method I suggested, at import time you set a reasonable default distance for each LOD, then after that you just expose entity spawnargs to the mission makers like always. 

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.

18 hours ago, OrbWeaver said:

Presumably the two different trees would need two different root notes, at which point the distinction between models and entities is effectively re-introduced within the single dialog.

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.

[Making it easier to use LOD models]

1 hour ago, stgatilov said:

There is also more general case: when you choose entityDef different from func_static, but want to also select model for this entity. For instance, when you add func_rotate entity with some model. What is the typical workflow for it? Add model, then change its classname, or add entityDef, then select model?

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:

1. 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.
2. Draw a brush/patch, open the Entity Browser and select the func_rotate entity. The brush/patch will become a func_rotate.
3. Open the Entity Browser, select an entity which inherits from func_rotate and has a model.

 

1 hour ago, stgatilov said:

I think Entity Browser allows to choose entityDef to spawn, while Model Browser allows to choose model to add as func_static entity. I'd expect that merging browsers can lead to confusion in future, because conceptually they do very different things.

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.

 

1 hour ago, stgatilov said:

I think @Dragofer is talking about existing LOD models/entityDefs, while @HMart is talking about adding new LOD entityDefs.

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.

[Making it easier to use LOD models]

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.

[All Tomorrows and Man after Man: What is your prediction for the future of mankind?]

6 hours ago, Carnage said:

I understand it, climate change is a big money maker

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.

[How does the "ignore user" function work?]

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?

[All Tomorrows and Man after Man: What is your prediction for the future of mankind?]

@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.

[How does the "ignore user" function work?]

@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.

[This Thread is for the Cabinet1 Fans ONLY [Version 2.0 Update]]

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

[Newbie DarkRadiant Questions]

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.

[Newbie DarkRadiant Questions]

@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.

[This Thread is for the Cabinet1 Fans ONLY [Version 2.0 Update]]

@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.

7 hours ago, Wellingtoncrab said:

-I actually am using the latest release of DR - Since these were thrown together with brushes, while I tried to caulk everything which was not visible I imagine there is some sloppy work/excess faces in there that could just account for the excess vertices?

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).

[Clip Textures on Entities - Functional? Best Choice for Frob Control?]

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?

[Clip Textures on Entities - Functional? Best Choice for Frob Control?]

31 minutes ago, Geep said:

If target_set_frobable was expanded from its traditional use within chests and drawers, to be used as invisible walls to only block frobbing, then none of these sound ideal.

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.

[Clip Textures on Entities - Functional? Best Choice for Frob Control?]

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.

[FMs that use scripted dialogues / sequences?]

2 hours ago, SeriousToni said:

As far as I know the quick save conversation bug is now solved in2. 09. However as you said, one problem still might be the player alerting the NPCs accidentally.

I think in Thief they gave them a low level of visual and audio accuracy until the conversation finished.

Does anyone know if this is possible in TDM too? I know that you can set those levels for each NPC, however they're permanently, so even after the convo they'd be deaf and blind. Is this changeable somehow after the convo finishes /with a times trigger / script?

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.

[This Thread is for the Cabinet1 Fans ONLY [Version 2.0 Update]]

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.

2 hours ago, geegee said:

Oh yes!  The prefab with openable doors works perfectly with the desk3_complete.  Thanks!

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.

[Newbie DarkRadiant Questions]

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.

[Newbie DarkRadiant Questions]

It's also worth making sure you're on the latest version of DR, since it's been getting easier to use it to find where definitions are stored. For example, entities in the Create Entity list now show in which .def file they've been defined. Definitely worth unpacking your .pk4's, too.

If you find more things that you'd like to become easier to find, such as that the Skin Chooser should show which .skin the skin is stored in, or that right-clicking something should show its definition in a new window, you can always post that on the DR bugtracker.