Leaderboard

We had an internal discussion about this issue and we find that grayman very clearly stated that he did not wish for his pending FMs to be released, see quotes posted by stgatilov above. It would have been very easy for him to ask any other teammember to finish up his mission in case the cancer (which he was always talking openly about) took over. But he didn't ask anyone!! His words and actions leave no room for interpretation: He did not want his FMs to be release when he is gone! So, the team decided to honor his will. We will not be releasing his unfinished work in any way. Of course, Grayson, being his legitimate heir, may do with the missions as he deems right.

Was thinking aboput this, using the Rope Arrow to make a new Tight rope arrow. Can only be fired into a specific item (like in Shadow of Tomb Raiders rope coiled around a log) Fire into that and it makes a tight rope the player can use to cross a void. It would have to have a balancing mechanic not too intense, but still a bit of a challenge. It has to be a special use item, otherwise players could use it to get to places they shouldn't. There's a few ways you could do it. Easiest is a script to spawn in a narrow invisible walkway where the rope is and have the rope horizontal. A better would be to have a springy rope the player walks on, and has to balance on. The reason is on my Venice map I'm still working on, the player will have to do a fair bit of high level crossing of canals, n a tight rope would be the perfect way to do it, so I don't have to use Assassin Creed 2 gantry type arrangement. Thoughts?

I find this a wise decision, although I think it does not exclude a mission in his honor, as grayman has also done with Sir Taffsalots sword, another member who died some time ago. Mission that by the way, I played yesterday.

I present you my sincere condolences for your father's passing, and I wish you all a lot of courage through this very sad moments. If it can help, I suggest you the reading of the book "The Light Beyond" by Dr Raymond Moody, the researcher that coined the term "Near-Death Experience" by studying thousands of testimonies on this subject: https://www.amazon.com/Light-Beyond-Raymond-Moody/dp/0553278134 The people I advice to read this book usually say they found it very helpful, I hope it will help you and your family like it did help me.

If we want something that's easy to use for mappers and encourages them to actually use the feature, please consider my idea to create an actual Git plugin for Darkradiant, and let me know what you think about it since I'm quite curious myself. Unlike my idea for realtime editing it's actually not something that radical to implement. I'd basically go for a set of menu entries and toolbar buttons that automate the appropriate Git commands required to work with a map, a customized GUI for Git if you will. Obviously the OS needs to have Git installed else DR would issue unrecognized commands to the system... on Linux this is a given, not sure about Windows users. It operates on the idea that the current FM directory is a Git repository, while being able to turn it into one upon use if not. The only features and commands it's really going to need are: Clone: Runs "git clone". Only needed if your FM isn't already a repository; This asks you for a Git URL and turns the FM directory into that repo. Pull: Runs "git pull". The repository thus map file are updated from the network, map is automatically reloaded when ready. This may erase local edits or throw an error if the remote map is newer: I understand the commands needed to merge against local changes are "git stash; git pull; git stash pop" (source 1, source 2). If changes were made to the same brushes or entities there will be a conflict: We'll need a prompt that lets you pick which version to keep, ideally with realtime previews later on so you can see how items change in the viewport (local versus remote versions) then have the option to make your choice per group. Same for other text data such as defs or script files, there should be a diff previewer that makes it easy to pick which def / function / paragraph to keep in cases of conflict. Push: Runs "git push". Uploads new commits to the remote repository. This should be pretty straightforward, the plugin only needs to support an additional menu asking for the username and password of the Git repository if they aren't set up in the config. Commit: Runs "git commit -m Message". Records saved changes you made to the map, a window lets you write a commit message describing those changes. The menu should also list every file in the FM directory so you can add or remove map assets as you work with textures / sounds / scripts / etc... if that's too complicated it can automatically add all new files and delete ones that were removed, but only in subdirectories that hold valid map content (eg: "myfm/def"). Log: Runs "git log". Generates a simple commit list in which you may browse through all commits... no need to even account for origins and branches, a linear list of commits from the current branch should suffice for our purpose, long as they're listed in a readable format like short log + author + date. Double-clicking on a commit should prompt you to revert the repository / map to it locally in case you need to go back to an older version. That should pretty much be it! Support for more Git options like branches could be added later but beyond this anything else can be optional. Needless to say mappers who want more features can use Git commands and other GUI Git tools on the FM repository separately: This is just to make it easy to do simple actions directly from DR... it also comes with perks that can be added later such as realtime previews of differences between commits, or a timer to automatically pull every X minutes so the mapper can be notified when there's a remote update and can click a button to reload the map with the new changes. The nice part is we can start with simple basics then expand with more features as needed.

I am a newcomer in this community, but I just wanted to pay my respects. Grayman is largely responsible for my own forthcomming venture into creating mission for TDM and I am a big admirer of his work.

I believe there are cvars for that. Also, static data is now stored in a separate VBO again: 5598

@greebo apologies, we have derailed the thread somewhat. One thing that comes to mind - I was never quite sure what happens in DR when I switch the underlying branch that contains the .map file. I eventually got in the habit of closing DR before merging and then reopening it, because sometimes after merging I would have local changes in my branch still. It might have been a VS Code thing as well. Anyways - if it just detects changes and reloads the map that's fine - if not maybe something around that?

While it's very interesting to have the predictable discussion about which is the only true way to use git correctly, my original intention before opening this thread was of course more directed towards getting some input about DarkRadiant and maybe what basic functions need to be added to make the VCS benefits more easily accessible to mappers, and/or to make collaborating with other members on the same map file a smoother experience. Obviously, even with the current state of DR development it's possible to use a VCS to make mapping work more secure or more collaborative, but what functionality would make life easier?

Hmm... I don't think it is best practice of Git to be honest. Maybe best practice of GitHub. I see two reasons for protecting main branch: External contributions from people who has no access and whom nobody even knows. Enforcing code review on all changes. Frankly speaking, I think none of these points apply to our context. External contributions are maybe possible after the map is released, but not while it is in development. Code review only makes sense for scripts and decls, but I think nobody will bother about it. No, it does not. GitHub exposes its repositories via SVN protocol, which allows you to use SVN client (until someone decides to use some "fancy" feature like submodule or LFS, of course). A colleague of mine used TortoiseSVN in one very small project with git repo. He did not notice any problems, even though nobody even knew about it. Unless people are going to really make many branches, using SVN client might be an option. Of course locking support is not required: you can always implement it outside of VCS. Just say "I'm going to work on these assets, don't change them please". That's implicit locking. Even with SVN, you can still forget about locking, make your changes, and then find out that they are in conflict with something. Don't think pull requests are needed here. Even with SVN, you can simply update the file, see conflict, and click "resolve with mine", and thus happily overwrite it.

I hoped for something simple, but it indeed looks complicated. As expected Why do you suggest using pull requests? Reviewing map changes is futile in many cases. Wouldn't it be easier to work on one branch in one repo and push directly? Or is it a workaround for git's ability to easily lose data? Why do you suggest rebasing? That's an easy way to lose data. Better just merge everything.

is actually possible but not very easy to play half-life alyx without VR you need https://github.com/r57zone/Half-Life-Alyx-novr and some stuff can be rather hard to do.

So sad to hear these bad news I didn't have much contact with him more than via some random scripting questions through the forums, but he always seemed to be a humble man that had worked with a lot of editors and games through the years. I hope he did have a good time in his last days without pain and may he now roam the Builders House, frobbing what he can!

https://imgbox.com/XHCaFkGk wheel of time with d3d11 and bumpmapping SSAO HDR etc. not bad for a game from around 1999 eh

It really is true then, I'm so sad to hear the news. Grayman was always very open to working/advising with big and strange gameplay features I was throwing around. He was skilled in his craft but never placed himself over anyone else, and struck me as a very humble man. Be it the case, I am glad to have worked with him for the time that I did. He was always great to collaborate with and was very direct with any kind of models he needed from me. His presence will most certainly be missed here.

Hi this is Graymans son My father was a poet, a painter, a writer, and a giant nerd. He studied nuclear physics, aerospace engineering, and AI. But all he really wanted to do was play video games. He recently lost a very long war with Cancer. My dad has a little plaque you all sent him hanging on the wall next to handprints from his grandchildren. Whenever my children would call him he'd talk to them about "his boring video game stuff" according to my 8 year old... who never really understood why Grayman didn't like Pokemon as much as he did. I found a file on his computer stating that the last few levels he was working on 95%, 95%, and 50% finished. He also said working with another dev would take up too much time that he wanted to spend with his family instead. To be fair I worked with my father my entire life on random things (including Doom mods back in the day) and he never thought anything was finished. So I'd personally consider the two 95% missions to basically be done. If whoever he sent them to to Beta test wanted to share them with the development team I don't think he'd really mind and you shouldn't feel guilty if you do. I'll leave that up to you guys, but I will not be uploading them and they should not be posted publicly. The final mission will remain unfinished though. I will mention that it was going to be pretty damn good from what I read in his notes. He did ask that two levels that weren't related to the Steele missions do get uploaded to the abandoned level archive. I am in the process of doing that now. Thanks

v 0.82 .. the "I think I finally got PBR working right" update (knock on wood) ambient surfaces with real speculars do more glossy PBRs now capped the distribution term in specular PBR flow to keep it from barfing white specklies everywhere with glossy outputs, and to help control how bright glossy shines are in lighting got rid of the "divide by Pi" parts in PBR flow, because we're not dividing diffuse color by Pi (instead, dividing by " 4 * NdotV * NdotL" which seems to give better results corrected visibility specular PBR term to use NdotL like it should (not sure how I missed this before) renamed BRDF_SPECULAR to PBR_LIGHTING (PBR is what we're doing, BRDF is how we're doing it) added #define PBR_REALISTIC which (when set to 1) will keep the multipliers usually used to tweak outputs (like speculars) to 1.0 so pure PBR outputs are shown without anything tweaking them after-the-fact (the idea of this is to maybe tweak the PBR outputs in the future to "enhance" the lighting to be more immersive / game-like, but still have a way to quickly switch to pure PBR. PBR is supposed to be a realistic lighting model, so mucking with it after-the-fact can alter the realism). added #define PBR_FAKESPEC_IS_REALSPEC to flip between fake specs acting like real spec lights of diffuse boost in PBR (in PBR, they do better acting like real specular lights, because PBR does direct rimlighting and rimshining w/o having to resort to extra functions. But, when you turn the fake specs into diffuse boosts, a lot of what PBR does disappears w/o much diffuse boost to show for it..unless you muck with the outputs post-PBR.. which defeats the purpose of PBR.. to have algorithms do it all w/o having to mess with too many extra variables). finally understood the whole "conservation of energy" thing, and added ks/kd ratios to balance diffuse vs specular. It's basically taking the specular PBR fresnel term and using it to determine how much light is reflected (specular) vs refracted (diffuse) based on your viewing angle, surface, etc. fake spec maps are used in PBR as speculars, but for roughness maps I went with grayscale diffuse textures. This lets them have full 0 to 1 range instead of the curved range that fake specs do. Basically, I read Epic Game's white paper on how they put PBR into UE4, and they made decisions to just keep using Lambertian Diffuse like they had been doing, and just focus on keeping it simple and where the algorithms they chose do all the work.. as opposed to shader devs or artists having to micro-manage tons of variables to tweak everything. This radically changed my thinking about PBR, and I realized it can be as simple or as complex as folks want it to be. So, I ignored a various diffuse lighting models and just kept what we had, but modified with energy conservation (kd). I realized Torrence-Cook is the main PBR model most folks use, but they swap out various sub-algorithms in it. Once I wrapped my head around that, it made more sense. I switched to using the most common algorithms tuts used, and just kept it simple to get it working. I then figured out the whole "conservation of energy" thing, b/c the ks/kd thing was confusing me for a while. (LearnOpenGL's tutorial was confusing, b/c they kept swapping back-n-forth between code and math.. and I do better when I see just a cohesive chunk of code showing how things are done). Anyways... I got it going. The goal (in my mind was) Get the damn thing working properly If it's working right, we shouldn't have to use any post-PBR multipliers to tweak speculars and brightness and other junk. The PBR algorithms should handle all of that, so we don't waste time mucking around with that. (I kept the multipliers in the code, but they're all set to 1.0 for PBR paths.. so we see a pure PBR output experience.) I had to make a few hackish decisions to get things to look decent, like clamping the distribution term (it was barfing white specks all over the place). Also, not dividing by Pi... The Pi division was confusing the heck out of me...then I came across some forum post (can't remember where) that the person said in the Lambertian Lighting Model, you divide diffuse color by pi. But, it's just assumed that light colors in the game engine piped out to shaders are already divided by pi, so nobody divides diffuse color by pi in shaders. Um.. okay? *head-scratching* But, the PBR code I was looking at (eg: Urdo3D, LearnOpenGL) were dividing the specular PBR output by Pi (learn open gl had one of the spec sub-terms also divide by Pi). I realized they were doing this, b/c it would balance out diffuse color dividing by Pi. But, we don't divide TDM diffuse by Pi. It's a bad assumption to make w/o knowing for sure. All I did was look at the results from the shaders.. if I divided diffuse color by Pi, it got really dark. So, I removed the divide by pi from the specular PBR output, too. Instead, I switched it over to a " / 4 * NdotV * NdotL" that I noticed other folks doing. This worked well to tone the final spec output without having to do Pi. (this is the big PITA about all of this.. it's like herding cats. Everyone's doing their own version of it that works for them, but they don't explain why they do certain things. No code comments or what-not in the code, and white-paper-like-discussions that hit my level of incompetence pretty fast. So, trying to mix-n-match code or using one project's code into ours can lead to funky results w/o knowing why.) Anyways... Issues: Chunky texture seams some surfaces have an ugly, chunky texture situation going on, and not sure why. When I switch PBR off, it resolves itself. So, it's something with the PBR pipeline. Something is acting like a cap or limiter or something to create the stark seams between parts. I tested various terms in the PBR, and these chunkies still occurred. Maybe it's my crappy HD 4600 doing something funky? I don't know. Only certain textures do it. If anyone can verify whether they're also having the issue, I'll be able to know if it's a code issue or gfx driver issue. Dark Spot under Player Ground specular was looking nice... before I got kD (diffuse refractive ratio) built into diffuse. Now there's a dark spot under the player. I know it's the kD value, b/c when I remove that from diffuse lighting equation, the dark spot goes away and ground speculars look better. Not sure what's up with this. I'll have to experiment, or try other formulas or something. I don't know. Speculars get Bright up near walls in Ambient PBR helps ambient specs look better, but they exacerbate the brightness of speculars as you get closer to walls more-so than non-PBR spec. Ambient specular was always a balancing act trying to make it look good both indoors and outdoors, b/c it's controlled mainly by the light color the level designer uses for the room/area. So, if they want brighter specs outside, they use a brighter light color. Darker inside, use a darker color. For PBR, I use the distribution clamp value to try to control how bright the shine is. I set it lower for ambient specs than direct specs. But, we still get cases like this, where looking up a wall in a dark area (Alberic's Curse, the inner church) has an out-of-place shine. The PBR has rim light & rim shine baked into its algorithms, so it does this super-brighting on its own. This would be a situation where spec & roughness maps would control it I guess, so maybe my PBR pipeline isn't using them well enough. Not sure. Screenshot Compares Here's some before & afters with non-PBR vs. PBR. It doesn't make a dramatic difference in scene-wide lighting. It mostly enhances things you're looking closely at by making the lighting act more realistically. PBR does it's own rim lighting and rim shine for direct lighting. (not so much for ambient lighting, so kept that as it's own light in ambient). So, in direct lighting, when PBR is on, the rim light & rim shine turn off to let PBR handle it all. Surfaces with real speculars treat PBR more like glossiness while fake specs do more rough / hazy specular. PBR makes light form around objects more realistically. The metal objects use real speculars, so they do more of a glossy shine instead of hazy/rough shine. The player lantern shines off the metals, reflecting light back. The falloff of the light adds more body/depth to the pipes & boiler. The window light also highlights the boiler more... PBR is handling all the direct rim light / rim shine here. So, no fiddling with variables to try to "get it right". The PBR algorithms have the smarts built into them. PBR enhances the lighting along the camera view. The metal lamp post pops out, because it's using specular as more of a gloss. But, the overall lighting tone has changed. The lighting on the posts to the left follows the falloff of the light source better, so instead of both posts being evenly lit, one is a bit brighter than the other. Mission 2, the weeping statue ... PBR helps the light follow the countours better. The stairs stand-out here, b/c PBR works best on things with more contours. It adds better light falloff and specular shine. The flip back-n-forth is my non-PBR shader vs PBR shader. Since my non-PBR pipe adds fake specs to diffuse brightness, it punches up colors. Since my PBR pipeline is set to do fake specs like real spec lights intead of adding them to diffuse brightness, colors seem to have toned down a bit while lighting has punched up a bit. I can post screenshots, but one of the things that makes PBR nice is how it looks when you move. The light just contours around things better. There are spots where you look straight up and go "why is that wood building super shiny?" But, that's b/c I'm doing the best I can with what I have right now. glprogs.stages.interaction.082.zip

I just wanted to share the sad news that grayman, long time developer and the author of the William Steele series, passed away recently after a battle with cancer. He was a pleasure to work with and did more for this mod than most people will ever realize. I am glad that his missions will live on.

How to use git Get: git clone --depth 1 --shallow-submodules "[url]" Set: git add --all; git commit --message="[summary]"; git push Or even better, use gitu.