Jump to content
The Dark Mod Forums

Dragofer

Development Role
  • Content Count

    1491
  • Joined

  • Last visited

  • Days Won

    102

Everything posted by Dragofer

  1. Hm, I've been clicking all over the place in DR but it never gave me the ability to move the camera with my arrow keys. In fact, it doesn't work in DR 2.5 or 2.7 either, so it seems this may have coincided with recent DR versions, rather than being caused by them. Edit: well, wiping my AppData/Roaming/DarkRadiant folder has solved it. Here are the former contents of that folder no_arrow_keys.zip - the arrow keys broke sometime either in 2.11 or 2.12.
  2. That sounds like something that'd be helpful more generally, even without lighting preview enabled. Large maps can easily have ten thousand brushes or more, more or less mandating the use of layers for good performance. By the way, wasn't there a possibility to use arrow keys for moving the camera? I remember being able to both scroll the mouse wheel and holding down an arrow key for quickly getting between various sections of my maps, but the arrow keys don't do anything for me anymore in one of the recent versions.
  3. 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 c
  4. 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
  5. 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.
  6. 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!
  7. 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
  8. 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.
  9. 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.
  10. 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
  11. 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. Looks like you might be kept quite busy with this FM There are even secrets that follow on from other secrets.
  12. @Gerberox @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.
  13. @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.
  14. 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)
  15. @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.
  16. 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.
  17. 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. 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
  18. Try disabling his visual stim or setting his AI_USE spawnarg to -
  19. 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. 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
  20. 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_useB
  21. 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. Will have to see when I get a chance. But there's definitely something fishy with intel GPUs, map loading times are re
  22. 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
  23. 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 mak
  24. 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 vis
  25. 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. 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. 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 te
×
×
  • Create New...