Jump to content
The Dark Mod Forums

Geep

Member
  • Posts

    476
  • Joined

  • Last visited

  • Days Won

    23

Everything posted by Geep

  1. To improve performance, I'm pondering the use of func_portals to manually open/close some of the outdoor-area visportals, controlled using scripting of a state machine. I'm at little concerned, though... It appears that you can only use func_portal to toggle open/close its visportal, not to set it explicitly. That is, while a mover has function calls "openPortal" and "closePortal", func_portal does not (I think). Furthermore, I didn't see anyway to detect the open/close state of the associated visportal. I'm concerned that if a trigger toggle gets "out of sync" (code thinks portal is in opposite state from what portal really is), then it will all go to hell. I imagine, instead of func_portal, I could use dummy movers that are either transparent or tiny or buried in the ground. Then I would have openPortal() and closePortal() available. I assume, once you have a mover or func_portal on a visportal, the engine doesn't itself decide to open or close it, so you can rely on the state in the scripting code being persistent. But maybe that's not a valid assumption. Thoughts? EDIT: I started down this road, but then thought about it further. The potential for problems is high and benefits uncertain and modest. So forgetaboutit.
  2. One thing I wasn't able to figure out for the wiki post was the use case for the painting models with the "_tearable" suffix. By default, these are empty frames with little scraps of stuff at edges and corners. But if you change the skin to real art, you just see the art unmodified (as if this was a painting model without the _tearable suffix). Maybe at one time it would look torn, but doesn't now in 2.09? Or maybe this model is something to use with the "replace" spawnarg for lootables? If so, I'd like to know of an example of anyone doing that. EDIT: Figured it out, will update the wiki soon EDIT2: Done, now with considerable more content.
  3. I just added a new "Framed Art" page to the wiki, giving an intro to the TDM framed painting system. https://wiki.thedarkmod.com/index.php?title=Framed_Art I thought the basics need to be on the wiki first, before maybe talking about how to customize with new art a la Away0.
  4. That sounds beyond what I can help with. Good luck
  5. I tried converting the tga to b&w with lens blur and adjustments to brightness/contrast. Probably too bright, so it became like a sheet of glass in an experimental FM. But then it immediately became obvious that the "flickering" was just plain old z-fighting. I'm seeing some evidence that the tavern_bar01 model (even if not custom scaled) incorporated instances of this stain decal in the same plane as the wood bar top surface. Maybe at one time this was ok to do, but not now? So if you wanted to use specular as intended here, only correcting the model (e.g., in blender), to put space between the wood surface and stain, would do it. Sorry, no can do myself. (Or give up on specular & return to leaving out the .tga file)
  6. Hmm, when I said above, "I'm guessing that when the DDS is created it munges the surface normals, and they remain munged when converted backto TGA", I was confused. That doesn't apply to a specular map, only to a normal/bump map (which is not used in this shader).
  7. Since the existing (flickering) cure is worse than the (dmap warning) disease, I'm reverting back to life without a stain01b_s.tga, for now.
  8. BTW, the post between SeriousToni and @Springheel was from 2013, not 2008. Here: As I said above, the dropbox links are no longer good. But there is a reference to FM "Chalice of Kings", so maybe better (non-infringing, non-flickering) versions of these 2 variant files (diffuse & specular) could be had from there? EDIT: No custom textures in TD2:Chalice of Kings.
  9. Maybe @SeriousToni's work was to create a variant stain pattern (with the same filename) to avoid copyright infringement? Dunno.
  10. In the "be careful what you wish for" category, I added that file to my FM's /textures/decals/, and now I've got the flickering on my bar top (of a tavern_bar01 model). Sigh I'm guessing that when the DDS is created it munges the surface normals, and they remain munged when converted backto TGA. Although I guess there's also a 3 color issue, which is why MakeIntensity had to be used.
  11. Missing Texture Uncompressed Specular File "stain01b_s.tga" This concerns 2.08, 2.09, and 2.10 dev, and relates to @nbohr1more's May 7, 2020 post in this thread. The "stain01bwet" shader is defined in tdm_textures_base01.pk4/tdm_decals_dirt.mtr as: textures/darkmod/decals/dirt/stain01bwet { DECAL_MACRO translucent twosided noimpact qer_editorimage textures/decals/stain01b { blend gl_dst_color,gl_zero map textures/decals/stain01b.tga } { blend specularmap map makeIntensity(textures/decals/stain01b_s.tga) } } Unfortunately, the file stain01b_s.tga is not included in any of these releases, only stain01b_s.dds, which makeIntensity(...) does not look for (nor should it). So a console complaint. Perhaps someone assumed that the .tga was unneeded, given the .dds, and so it was purged from the distribution. If anyone could provide me with the missing file, I think I can work around the problem for my FM. (The original source, from @SeriousToni in 2008, no longer has a valid link.) And of course a more permanent fix within 2.10 would be great.
  12. I've always had to do tweaking of that spawnarg by trial and error. And you can only expect the beginning and end locations of the hatch to be good, with the movement in-between continuing to be funky. As to OrbWeaver's point, for non-func-statics like individual brushes, I think it's better to not to use the free-hand rotate tool, but instead DR "rotate and scale" of the Z axis with a known numeric value, like 45, 30, 60 degrees.
  13. Stolen Heart Release Candidate 2 is now available, now with much less disk space, and a bit more to wonder about, like this door here...
  14. NEVERMIND! MY BAD! Turns out I had renamed 2.10's tdm_sound_ambient_decl01.pk4 to .zip to look inside, and forgot to restore the name.
  15. A lot of the warnings look like this... WARNING:Couldn't load sound 'solitude_loop_z.wav' using default [map entity: atdm_location_settings_1] [decl: solitude_loop_z in <implicit file>] [sound: solitude_loop_z.wav] Could it be that the code is for some reason assuming a .wav extension (and so not finding the sound file), where it previously assumed a .ogg extension?
  16. I might add that this was a fresh full install of 9588, not an incremental upgrade.
  17. During console "map", I get a list of TDM sound files, like "animal_flies_loop01.wav" with "WARNING: Couldn't load..." messages. Those sounds do indeed appear to be not playing (I only checked a few). This was a build that worked under 2.09, but had this problem when copied to my 2.10 environment. Deleting the .cm, .proc, .aas* files under 2.10 and redoing the dmap there did not fix it. Are you seeing this too?
  18. @Dragofer Perhaps that advanced example is a bit hard to grasp, a little too abstract in presentation. Maybe it needs an illustration with 2 buttons, "Jump East" and "Jump West", and two rabbits (func_static model instances) that "jump" in unison. And the salient Entity Views of each button and the target_callscriptfunction.
  19. Is there a good reason that old compilation files (.cm, .proc, .aas*) are not automatically deleted first thing by dmap?
  20. I agree that the default should be either the existing highlight or the new highlight with r_frobIgnoreDepth 0. I was thinking beyond that, if the player can override the default in favor of r_frobIgnoreDepth 1. Then the mapper might want to selectively override the override with frobstop.
  21. @stgatilov, when I knocked out my smuggler and highlighted him, I did see pulsating on certain metal or shiny parts like teeth, buttons, belt buckle. And nearby bushes made of patches. When I switched to shadow maps, all that pulsating went away! So sounds very much like what you were seeing.
  22. About the visual artifacts. Yes, this is with stencil shadows. Will try the experiments you suggest in a while. BTW, I mentioned limitations to my graphics hardware, that could be related. Details below. About the ease of discovery, I was looking into if any existing geometry or texture could block frobbing of things behind it, without itself being frobbed. Evidently not. If something new were to be created, my thinking now is that, rather than "frob shield" texture or class, better would be a special spawnarg (say, frobstop 1) that could be applied to any non-frobbable object. In the code, it would initially act as if the object *were* frobbed, except it wouldn't highlight or do any frob actions. Maybe it could be applied to worldspawn too, but then would affect all worldspawn. Not quite making this a "feature request" in the bug tracker yet. Depends on what others think.
  23. I'm more concerned with the situation where containers are not involved. Either the frob is happening through a wall where you don't want it to, or it's happening through a moveable where you don't want it to. I agree that adding more geometry isn't great as a solution, but setting up triggering to unhide an object in such cases seems like no fun either. I'd rather have some spawnarg I could set on anything, say, "frobshield 1", that would render it impervious to frobbing of anything behind it that you can't see. Even if the 2.10 player had frob highlighting with depth turned on.
  24. The thing about "froblock", which I guess should be parsed as "frob lock" rather than "frob block", is that, in addition to having a lock, it is ordinarily frobable/highlightable. So it's not exactly what's needed either.
×
×
  • Create New...