Jump to content
The Dark Mod Forums

Spooks

Member
  • Content Count

    545
  • Joined

  • Last visited

  • Days Won

    35

Spooks last won the day on March 29

Spooks had the most liked content!

Community Reputation

637 Legendary

2 Followers

About Spooks

  • Rank
    Advanced Member

Contact Methods

  • Website URL
    http://oddlyunadventurous.tumblr.com

Profile Information

  • Gender
    Male
  • Location
    Bulgaria
  • Interests
    VIDEO GAMES MAYBE

Recent Profile Visitors

168 profile views
  1. https://rebeccashieh.com/o-theo Rebecca Shieh, visdev at Netflix, previous work at Pixar, Cartoon Network. Her personal project, O Theo, may be of some inspiration to you. Many art pieces within link.
  2. I can say yes to both of those, my Northdale Act 2 quicksaves load fine.
  3. Sorry for responding late, I only saw this late last night! The problem persists in the hotfix beta. I had a confusing, long and fruitless second bout of testing. My materials are a mess and I have multiple entries with the word "sandstone" in them. So okay, here's a correction. I do not have a custom "overwritte" material defined in my fm/materials folder. Instead I have a custom texture with the same name as the core texture and I assume that it is sufficient to overwrite how the material looks in-game. I assume that it's sufficient because I still remember testing the texture in-game prior to updating to 2.07 and it showing without a problem, but I don't know if I used an intermediary material and/or renaming my texture. Here is the biggest difference, my texture is a .tga and the default is a .dds (and as such, in a different folder). Converting the .tga to a .dds and placing it in the /dds/... folder makes it load fine ingame. Still, reloadImages will overwrite the default .dds to the custom FM .tga one, so what gives? Imo it's still inconsistent behavior. This makes it a non-issue for me since I plan on converting the appropriate diffuse maps into dds files when releasing anyways, but it still feels very weird and I can't shake the feeling that this is NOT how the behavior used to be prior to 2.07.
  4. Got a crash to desktop using the hotfix. I alerted some enemies and noclipped through a wall (brush). Very shortly after I popped out of the wall and into another area/visleaf the game crashed. I can't compare it to regular 2.07 because I updated my installation. However, it is reproducible, which I honestly did not expect. I have a crashdump for you here, it's from the first time I experienced the crash. It's rather large and it's available here. Hope it helps.
  5. I've never been great at paintovers, I lean on the cartooning side when it comes to art. Oh well. I'm trying to figure out some sort of look for this little environment I've greyboxed. I need to lower the scale or come up with another enviro idea but I kinda dig this one tbh, I'm not too picky.
  6. Hey I've got a question pertaining to something I've only noticed with 2.07, not sure if it's always been like this but I think it has. Usually, you can easily overwrite materials in your FM. For an example, let's say the mod has a textures/cobblestone material, you can make your own image maps and in your own myfm/materials/my_mats.mtr file you can define textures/cobblestone with an updated specular/diffuse, what have you. I have done this before without a problem. On 2.07 however I've noticed that when loading the FM, the material will still look like the default one. In my real case, to leave the example aside, I've updated a material's diffuse map and it visibly stays the default. Only when I type ReloadDecls in the console do all the surfaces in the game update to the custom diffuse map for the material. Does any dev know of something in 2.07 that might've caused this? Should I file a report? Like I said, I'm not sure but I'm fairly certain ReloadDecls was not needed in previous versions of TDM.
  7. Hey, here's a very old question: is there a way to circumvent the 64 character limit on filepaths in Blender? I searched around and the only thread on the internet I could find was a Blenderforums one from like 2011, with Orbweaver in it. .ASE is human readable but .LWO isn't, so I can't fix the offending, long texture path post-export. I installed Blender 2.8 beta, but it's still the same there.
  8. In the bug report I have indicated that, on the last beta versus the one in which I encountered it, the disparity is now present with both singlepass 0 and 1, so yes, you're correct. I don't entirely get what change is encompassed by the term "orientation" - and for that matter I don't wish to be dogmatic when reforming the engine's shadowing logic - but whether surfaces behind a one-sided shadowcasting surface get shadowed or not shouldn't imho get controlled through something so permutable as a user-accessible cvar. If anything, the noselfshadow keyword inside common/shadow2 should be used for this.
  9. I played very little with the stencil shadows, not encountering anything gamebreaking. I saw a case where an oblique view caused some func_static stencil shadows cast on the ground to disappear from view, but it's not reproducible. I can report that the clamps to the interaction shader have eliminated the bad behavior with the patches! That crate does, indeed, still look bad, so that's turned out to be its own issue. 4980 has not been touched I see, but on the flipside I can't think of an FM where the bug presents itself, so that could be moved to 2.08.
  10. By no means do I think it's somehow a problem in the crate. Or rather, if you think the 2.05 shader is the problem, the crate's not the only thing affected. I've noticed black splotches and over-brightened specularity on cylinder patches in my map that were not there during the previous beta. Here is a cropped picture, with magnification: The light is coming from behind, from the window, and that four-sided, cylindrical patch exhibits the bug on a face that's facing somewhat away from the light, yet is getting inordinately strong specular (and clipping to black), compared to simple interaction shader or enhanced on beta 6. Honestly, I think there's something wrong with the 2.05 shader in and of itself, because I've encountered similar stuff in 2.06, like the stair models I talked about earlier in the thread. I don't remember it being this bad though. If needs be I can make a test map, but not today, maybe on Sunday.
  11. I've not had a chance to test since my last post, which was a workweek ago. When I said I "fixed it" I meant the remark from VanishedOne. I assumed the problem might have been fixed in beta 7 but as it has not I have indeed gone ahead and tracked it. Reopen http://bugs.thedarkmod.com/view.php?id=4955. The bug is back on beta 7. I cross referenced both in my WIPs and in the view position in William Steele.
  12. The wall modules won't seal the level. Why shadowcaulk over caulk then? Honestly, I don't remember why I do it now! I just remember there was a bad drawback with caulk that I discovered and it turned me to shadowcaulk, which did a better job. At any rate, one benefit is that you can freely turn off the shadow casting on any wall module in a concave room (conditionally through LOD or not), because if there is any light, it will be casting light on the wall modules, the modules themselves won't cast shadows inwards, to the room. The exception is the trim, but if it's minimal or the light is cast not too dramatically, the player won't notice. As regards to the material issue, don't worry guys i fixed it Should I track this one?
  13. OK, I can confirm that the single pass shadow map mode now works with the alphaTested materials that I use in my WIP (we were discussing how it didn't look correctly wrt to the vines on one of the tombstones in The Warrens, but I haven't gone in to check). Regarding singlepass though, I was fortunate to turn it on and check, because I found a bad interaction with shadowcaulk by chance. r_shadows 1 (or r_shadows 2 with singlepass mode 0): r_shadows 2 with singlepass 1: How the scene's set up in DR: I really don't think this is related to the noFog change. Before you rush to fixing shadowpass though, while shadowpass 0 will fix shadowcaulk, it will not fix shadow/shadow2. Here's the problem: with shadow stencils, the front faces, facing the light, don't cast shadows? I don't know if that's the right way to explain it. With shadow volumes, shadowpass on or off, they do. Here's pictures to better visualize it: Brush textured with common/shadow2 with r_shadows 1: Same brush with r_shadows 2: edit: I suppose a better way to phrase it is that with r_shadows 2, the the faces of the brush cast shadow in the gap created by the brush's volume itself, which should not happen.
  14. I'll also point out that while greyboxing is standard, it is also, by another name, conventional. Here is a good inspiration post for anyone looking for pointers on how best to complete your FM. It's from an animator I respect, but use your noggin and let the power of metaphor deliver the point: http://felixcolgrave.com/post/179932218595/do-you-have-any-tips-for-a-scatterbrained TL;DR: Do what works!
×
×
  • Create New...