[ON HOLD] Bumi: Real-Time Day/Night & Weather

[Reinchard2]

Hey Nash, what mod do you use with Bumi in that video where you show dynamic sound dampening? Camera movement is very realistic in that one.

[Nash]

Reinchard, it's a stand-alone game I'm working on. :D

[Reinchard2]

God damn! I hope I will be able to download this somewhere...

[lightman68]

This looks intensely amazing. I'd think of day and night as constantly callilng ACS to change colors of the sky n stuff, but this takes it to several more levels. Very noice.

[Nash]

This project is currently on hold because I don't have a working, stable version of the latest GZDoom post-scripting and the changes upstream are too crazy right now so I'm going to wait for activity to die down before I attempt to build my own binaries for testing again.

I wouldn't be surprised if anything in Bumi started breaking in post-scripting GZDoom so I need a stable binary to start cleaning things up but as I said, too much activity is going on upstream right now and it's just making me confused, so I'm going to sit on this one for a while...

[Gez]

As long as it works in 1.9/2.1, the post-scripting issue can be postponed.

[ramon.dexter]

Hi Nash, I tried sending you PM, but you do not reply. So I'm asking here:

Can you share your compass code, that could be seen on some of the screens? The one looking like in Fallout 3...

Thank you.

[Nash]

Hi Nash, I tried sending you PM, but you do not reply. So I'm asking here:

Can you share your compass code, that could be seen on some of the screens? The one looking like in Fallout 3...

Thank you.

Later. This code is incomplete and not ready yet, the biggest issue being is that it currently relies on a fixed set of TIDs to mark things on the compass... I totally hate that. I'm hoping in future there would be a way around this that doesn't involve overwriting actor/monster TIDs just to get the markers to show up on the compass.

///////////////////////////////////////////////////////////////////////////////////////////

Ideas for next update:

- Utilize MoreIDs so that you no longer have to replace existing sector tags and mark them with a custom user_envsector variable. Would also eliminate a potentially CPU-expensive loop because I would no longer have to iterate through sector tag ranges - instead, I'd just predetermine a single, unique and reserved tag and with MoreIDs, you just add that as an additional tag without overwriting current sector tags.
- Use an intermediate camera object instead of the player directly for precipitation particles and the sun glare
- Extensive testing to make sure the entire thing actually even still works with the new ZScript system

[kodi]

I'm hoping in future there would be a way around this that doesn't involve overwriting actor/monster TIDs just to get the markers to show up on the compass.

Asking more for educational purposes than anything else since I'm working with reasonably similar stuff that really needs improvement - would it be too performance intensive to have the monsters execute an acs script that logs it's coordinates by using 0 for an argument in the getactor[..] calls every frame?

My current(and untouched in years) system is pretty, uh, abysmal.

[Nash]

I can't imagine it to be performance-friendly at all for every monster to have a delayed/looping ACS script attached to them... especially with massive monster counts?

I did ponder upon the idea of "registering" actors into a list/index and just maintain and update that list (the registration script would only be called once on spawn, and a deregistration script would be called once upon death/removal) but that would still require assigning actors with 0 TID a temporary/unique TID because otherwise there's just no way to interact with an instance of an actor uniquely... the whole point was to not even use TIDs anymore...

[kodi]

I can't imagine it to be performance-friendly at all for every monster to have a delayed/looping ACS script attached to them... especially with massive monster counts?

I know too little to have any real concept of what actions are expensive enough to matter I imagined that since the getactor[..] functions would have to be used and looped one way or another, the method of activating them would matter less in comparison. Perhaps player-centered A_RadiusGives where the item executes the script, which would keep every monster on the map from calling the script at least? Then again, the RadiusGive itself might be performance-intensive.

[Nash]

DoomScript (well, its 1999 iteration at least) sort of promised low-level access to actors/thinkers so I'm just wishfully thinking that at some point in the future, a lot of our current problems can be solved in a proper, robust way...

[saegiru]

Any progress on this? It is nothing short of amazing... and I would love to take a look at it and implement it into some maps! Please tell me you are still working on it and something is coming soon

[Gorec]

ples this is first mod on my list to download

[Nash]

Implemented screen-space lens' flare's!!!