Dragofer
-
Posts
2631 -
Joined
-
Last visited
-
Days Won
157
Posts posted by Dragofer
-
-
Thanks, I can confirm that:
- DR 2.12pre3 no longer makes my PC hang after shutting down DR, and DR now remembers my filters from the previous session
- redownloading and replacing my DR 2.11 portable install allows it to start again
-
1
-
On 4/14/2021 at 9:32 PM, Frost_Salamander said:
Does is 'hurt' to just leave them as worldspawn somehow?
For me the main problem with leaving decorative brushes & patches as worldspawn is that wherever a brush meets another brush, dmap will try to optimise them in all kinds of ways. With increasing complexity you risk getting artefacts such as missing faces, glittery lines because of many very thin triangles and weird shadow projections, which typically all get resolved by converting into func_static.
Furthermore, dmap will also generate unnecessarily intricate pathfinding areas around such brushwork - it would be better just to surround the whole thing in simple monsterclip brushes.
As Springheel says, it's also great to be able to just enable the "All entities" filter to strip away the decorations if you ever get a problem with sealing, pathing, visportals etc
-
2
-
-
I think it'd be good to post some early samples in here, too, as we can probably collectively provide some useful feedback.
Thanks to all involved for making this happen!
-
1
-
-
On DR 2.12pre2, whenever I close down DR my PC hangs a short while. DR also no longer remembers my changes to things such as what filters are enabled/disabled from the previous session.
Can't try DR 2.11 or earlier versions because they abort startup during the splash screen at "Modules initialised". My 2.11 log is as follows:darkradiant.log
-
4 hours ago, STRUNK said:
I'm trying to get the textures on patches right, but I can't get it to work.
Here's a part of @Obsttorte's video where he does what I can't get to work: https://youtu.be/GfBh6Lhox7o?t=3407
My texture stays streched and bend although I think I do exacly what is done in the video ...It looks like you're trying to copy-paste a texture (2D project) from a brush surface onto a patch. Just copy the texture from the brush surface with MMB, then paste onto the patch with ctrl + MMB - this will project the texture onto the patch. If the brush surface is not in the same plane as the patch you'll get a stretched texture.
-
1
-
-
- Popular Post
- Popular Post
1 minute ago, nbohr1more said:What about a giant Chinese style ship?
I actually tried to make a giant European warship (i.e. HMS Victory) but those things get so huge. The time taken to make a ship increases exponentially with its size.
The next iteration of this map will likely go in a more metallic & industrial (& huge) direction, representing the upper limts of technology in TDM's setting. One of the next ships may be an ironclad.
-
6
-
- Popular Post
- Popular Post
Just for fun I recently updated my "Ships of TDM" map with both new ships and ones that weren't included before. It's quite the view now, and most of them have fleshed out interiors:
Back row from the right: Airship (Dram), Invernesse (Dragofer), Ship Wreck in 2 halves (Dram), Galleon (Dram + Springheel), Airship (Jesps, Pandora's Box), Galleon (PinkDot, core asset and found in many FMs), Barque (Dragofer)
Front row from the left: Indiaman (Dragofer, Perilous Refuge), Carack (Dragofer, One Step Too Far), Paddle Boat (Dragofer), Steam Schooner (Dragofer, Down by the Riverside, Away 1: Air Pocket), Caravel (Dragofer, in Dragofer's Stuff), Sloop (Dragofer), Brig (Dragofer, in Dragofer's Stuff), Yacht (Dragofer, in Dragofer's Stuff), Knarr (Dragofer), Boat1 & Boat2 (core assets).
No shortage of ships of all types if anyone ever needs one.
And a a barque interior shot taking advantage of DR's new ability to show lighting previews for all types of lights:
-
18
-
3
-
3 hours ago, AluminumHaste said:
I noticed that the download links on missions page and in game were for the over 500MB version of the map, I've updated the links to the proper v1.2 instead.
Damn, I forgot to rename the .pk4 to have the same name as the one on the mirrors. If I'm not mistaken, looks like we'll have plenty of players with double entries in their FM list with a need to manually remove the old .pk4. Thanks for updating those links.
3 hours ago, AluminumHaste said:I HAVE to explore every nook and cranny, and get every secret and loot or my head hurts.
Looks like you might be kept quite busy with this FM
There are even secrets that follow on from other secrets.
-
SpoilerSpoiler
There is no need for a warning to find another way around the kitchen area. We learned in dark mod, doors without handles don't work. The message is rather confusing because the player might waste his time to find secret switches.
I didn't understand why there is a red light source from the hidden chest.
Before I placed the warning I had reports of players swimming all around the hull trying to find a way into what they believed was an extra room between the galley and the hold, so both ways are problematic. The main reason that door's not openable is because I didn't want AIs to walk around there because of potential pathfinding problems - should probably just find a technical solution that makes it possible for AIs to go in there without getting stuck.
On 3/29/2021 at 2:27 AM, Gerberox said:I didn't understand why there is a red light source from the hidden chest.
Just a small spooky unnatural light to complement the other creepy stuff that for some reason is in that chest.
@Zerg Rush It's intentional that when you switch off lamps that the moonlight coming in from windows becomes noticeable, but it looks like the moonlight levels are a bit high - each window in fact has multiple different lights in order to illuminate the surroundings in various ways, so might be that they stack up to become too bright in some cases.
-
1
-
-
@Darkness_Falls
What you can do is to texture void-facing surfaces with textures/common/caulk and enable the filter for caulk. This lets you choose what rooms you want to peer into from the void.-
1
-
-
2 hours ago, Gerberox said:
A 10 cm object on a rope prevents me to reach the deck of the another ship.
Not good.
That object actually has the purpose to stop rats from climbing onto the ship via the mooring ropes. Seems it also works against thieves. (there's nothing to find on that ship anyway)
-
1
-
-
@datiswous The weird thing is that worldspawn should always be entity 0, I can only guess how you got entity 19 to be worldspawn as well. I would try to delete&recreate entity 19 or convert it to func_static - the aim is to have only a single worldspawn entity in your map: entity 0.
-
3
-
-
The glass-encased oil lamps I made for my missions, and which are now also core assets, are all frobable because they're assumed to have switches for toggling the fuel supply. I left the old exposed oil lamps as they are in order to not break established conventions.
-
1
-
-
3 hours ago, duzenko said:
I just noticed that the pk4 is poorly compressed
At install TDM has to recompress the entire file supposedly having a compressed .ogg or a video.
This is intentional, we found that using the "Fastest" compression setting in .7zip shortens map loading time by 15-25s while only adding 17 MB to the .pk4 size compared to "Ultra", and I didn't notice anything unusual happening at install.
After bringing it down from 550 MB and considering how long this map takes to load I think it's well within reason to have a 170 MB instead of a 153 MB zip that loads significantly faster.
3 hours ago, duzenko said:Also, svn fails to load the map due to assert failed in the remote camera script
Is that with the newest SVN assets and source? There was a problem with redefinition of the camera script since some FMs use a custom version without inclusion guards, but I can now load into the map and inspect the security camera without problems.
-
1
-
-
6 hours ago, Bienie said:
Quick question, is there an easy way to make an AI invisible to other AI? I want a specific AI to not garner any attention if the player knocks him out. Kind of like the AI_see spawnarg on lights but for bodies. I tried changing his team to 14 (rats) since AI don't react to dead rats but it seems a body is a body in their eyes...
Try disabling his visual stim or setting his AI_USE spawnarg to -
-
1
-
-
1 hour ago, nbohr1more said:
Is this true if you copy the glprogs directory from tdm_src to your SVN darkmod directory?
Copying the glprogs folder from darkmod_src to my 2.09 release build made no difference, still splotchy. But on darkmod_svn (assets) there's no problem.
1 hour ago, nbohr1more said:@Dragofer can I get a test map? I have never seen this artifact in 2.09 or SVN and I always have normalmap compression enabled.
Sure, as OGDA said it's his paintings demo map. I've already reuploaded my own version because the original version had a small mistake in the folder structure (there's one top level of folders too many) that prevented it from being possible to treat like an FM: https://drive.google.com/file/d/1G4WJY9G5T6hyIn9pM2KINOHD503b9sxS/view?usp=sharing
@OGDA I don't think there's any need for action from your side, to me it looks like it's a problem with a 2.09 change to how TDM handles normalmaps, which seems to break on Intel GPUs.
-
7 hours ago, stgatilov said:
Well done.
Although I have a feeling that DXT1 and RGTC are different compression formats.I think RGTC is also called BC5U.
UDPATE: I guess it is either BC5 or ATI2N_XY...
Damn this stupid nomenclature!BC5/ATI2 (3Dc) unfortunately doesn't seem to work regardless of whether I generate mipmaps. The normalmap is missing ingame (flat appearance) and the console writes "Failed to get bindless texture handle:".
If I set r_useBindlessTextures 0 the texture becomes dark except for where a light source lights it up (no ambient light illumination). I've seen that before when the normalmap can't be loaded.
These are the DDS export options in GIMP:
The appearance with r_useBindlessTextures 1 is as in the previous message, and this below is what it looks like when I set r_useBindlessTextures 0:
Btw, I found that increasing anisotropy filtering in graphics settings makes the artefacts less severe (as can be seen on the ceiling in this shot).
-
17 hours ago, stgatilov said:
To answer this question, you have to take some offline tool (most likely Compressonator) and convert this normal map to DDS. Then ensure this DDS is loaded in game (I'm not sure whether engine already loads DDS automatically or not) and check how it looks.
Converting that normal map to .dds with DXT1 and mipmaps with GIMP has resolved the issue:
To confirm that the engine does in fact load .dds normalmaps, I also converted, renamed and assigned some very noticeable curtain normalmaps to this wood floor and saw no difference compared to the original .tga curtain normalmaps. The paintings are untouched and still have the splotchiness.
Also, I noticed that current SVN (ca. rev 9216) doesn't have this issue.
18 hours ago, stgatilov said:How does it look on a different machine (e.g. with NVIDIA GPU) ?
Will have to see when I get a chance. But there's definitely something fishy with intel GPUs, map loading times are really long in 2.09 with this GPU and they're shortened to one quarter by disabling that normal map compression cvar.
-
I've noticed that some textures with normalmaps now have a blotchy appearance in 2.09 if viewed from a sharp angle:
The problem disappears if I either:
- comment out the normalmap in the material definition
- set image_useNormalCompression 0
- revert to TDM 2.08
It affects for example textures/darkmod/wood/boards/polished_01, but not textures/darkmod/stone/brick/blocks_large_sandstone.
This is on a PC with Intel UHD 630, Intel i5-9400F. Got a console log here: 209_splotchy.txt
-
2 hours ago, stgatilov said:
Players have expectations. When they shoot water arrow at torch, they expect it to get extinguished. When they see security camera, they will quickly memorize that it can be only destroyed with fire arrow, and they will expect such behavior. Customizing such things will only confuse players.
Yes, this expectation is an important point and something I wrote about in my previous post.
If a dev determines that the security camera shall only be used in a single way (a mechanical apparatus) then hardcoding a lot of these behaviours is entirely adequate, and that's basically how it was until now. But mappers are collectively very creative and can easily use the code in many valid ways that the dev did not foresee, i.e. making a nearly broken model that the player can finish off with a blunt tool if he's escaping a prison cell, some kind of organic/undead sentry creature or even make it invisible and use it for triggering events if the mapper's not comfortable with scripting. These kinds of things are only possible if the options are made available.
The downside is that we might get inconsistent behaviour between FMs for identical-looking models, but in fact we already have important entities that can be customised down to the most minute detail, i.e. AIs with any type of helmet can be made immune to KO and have their FOV decreased. But mappers seem to only rarely change such properties because the default values are entirely good as they are. I think this here is mostly an exercise in establishing a default behaviour that most mappers and players agree with.
Also need to consider that at some point the job of the dev ends (to make available a powerful tool) and the job of the mapper begins (to make good use of the tool). Things like unmistakeably informing players about nonstandard mechanics in the FM are part of the mapper's job.
-
2
-
-
2 hours ago, Obsttorte said:
Why? If uncertain mappers can tell the player at the start of the mission how the cameras will behave. The main point is that their basic behaviour is consistent. How much damage they take or whether their are sensitive to water doesn't belong to that imho. It could different generations of the same camera. Maybe the manufacturer only cared about improving the way the cameras work, not how they look. (I know, in real life it is vice versa, but TDM is a fictive scenario, so ...
)
I don’t agree with that, imo how a camera/AI behaves is pretty much on the same level of importance as how to disable it. We should establish conventions for how players can expect to interact with the world, i.e. AIs with open helmets can be KOed while those with closed helmets are immune. Technically a mapper could declare that his FM’s City Watch has obtained more durable steel so that all helmets render immune to KOs and hope everybody gets the message, but I think the most likely result is that most players would be frustrated after learning this the hard way (especially if there’s no visual difference to other FMs) and finding themselves limited if KOing is their preferred playstyle.
This could even be a reason to move some spawnargs out of the entityDef and only list them in the wiki article, preceded by advice that any changes should be advertised clearly in the mission and ideally be accompanied by a changed model. This would be to avoid that we get a mosaic of unpredictable behaviours across FMs for cameras that appear to be identical.
2 hours ago, Obsttorte said:Also sneaking them by can be pretty easy if the camera is sweeping. When they look away you sneak below them, when the look the other way you continue on.
2 hours ago, Obsttorte said:This is were the issues usually starts. Considering the fact that most mappers usually don't care much about what tools and what amount of them they hand to the player, it is pretty likely that the players starting equipment will be sufficient to deal with most of the cameras, if he can utilize half of it to take them out. This will render them useless.
Balancing the paths and tools is up to the mapper. A lone AI or security camera in an open dark area is easy as pie to get past, but multiple interlocking view cones in a well-lit area requires a strategy. The more different & balanced tools we give mappers and thereby players, the more diverse the strategies that can be devised and the more interesting it should become, in other words it’s more interesting to give 2 fire arrows + 2 flashbombs than 3 fire arrows.
-
2
-
-
4 hours ago, greebo said:
The tricky thing will be how the simple mode is going to deal with materials that use more than the basic options - are they just hidden and will they get dropped when a stage is edited in simple mode?
I'm thinking the advanced options would still be in action with their current values, just that the controls are not visible to the user.
4 hours ago, greebo said:A general consideration: One of my requirements was that any material can be opened and altered without losing anything, except for maybe formatting or redundancy - not sure if this is something worthwile pursuing?
This sounds like a good idea to me, wouldn't want to alter or break special materials that the mapper is inspecting for guidance in creating his own version. But this is a question of necessary time investment to implement vs. number of special materials that need special attention.
4 hours ago, greebo said:I have to read up on the latest development on frob stages. Haven't there been discussions of getting rid of that frob stage and have it handled by the engine automatically? If a frob stage is necessary, then a button to create it would of course be very useful, agreed.
It's one of the things planned for 2.10, but until then frob stages will be necessary and not all mappers may upgrade immediately i.e. because of technical issues, so there might still be some value in being able to quickly add frob stages. There will also no doubt be many material frob stages floating about in custom texture packs long after 2.10 is out.
-
3 hours ago, Obsttorte said:
Correct. So it might be the best to not add something like that as default behaviour. If mappers want their cameras to be disable-able via flashbombs or water arrows they can add that themselves. Both tools utilize stims. Or the possibility get added but turned off by default, so that mappers can enable them via a spawnarg. Although I would prefer the first approach.
On the other hand, security cameras are basically like AIs that are non-KOable, non-killable (without loud and expensive arrows) and never leave their area. Also, I can imagine that security cameras will see a lot of use simply in restricting the player's mobility around the mission, as we saw in the bank in Thief 2, not only to guard the most important locations.
I could therefore imagine them becoming cumbersome to deal with if the only available methods were fire arrows or the power switch (possibly guarded by keys and codes). It is also the mapper's responsibility to balance them well, but I think it'd make the mapper's life easier if there were some more methods available - but not as abundant and effective as water arrows. Flashbombs could have more uses, anyway - they're currently no good for anything else than escaping or fighting undead.
Having this already enabled is preferrable since only a subset of mappers is able to use S/R and scripting effectively, and such behaviour should be fairly consistent across most of TDM's FMs for cameras of the same genus.
-
I'm leaning towards making flashbombs, but not water arrows, a means of temporarily disabling a security camera. They're less abundant and more valuable, so this should justify being able to get past a stationary camera, which might after all be guarding a very sensitive location. Breaching that location once might render the camera irrelevant for the rest of the mission, so it should be an exceptional act to disable it and not something as common as dousing a flame.
DarkRadiant 2.12.0 pre-release test
in DarkRadiant Feedback and Development
Posted
Thanks for adding these highly necessary changes to the lighting preview. I've already used this to make this image for the "So what are you working on?" thread, stating that it's a new DR feature:
The main problem that's holding me back from using this feature more regularly is the performance. I was getting 2500ms per frame for this view, with the rest of the map hidden, on an Intel i5-9400F with Intel UHD 630 that rarely goes under 40 FPS in TDM FMs - even though the lights cast no shadows. Showing this view ingame (from the void with lights enabled) would be very demanding too, of course.