Ed's Running To-Do/WishList

[Ed the Bat]

A brief preface: I'm way overdue on this. It has been a strange few years for me (not to mention the obvious world-rending events that have impacted all of us), and the long and short of it is that I've had too many things go unfinished or unaddressed for this project. I'm mad at myself about it, but I've already expressed that more than enough in other places, so I won't keep beating that dead horse, and all of you have been nothing but supportive and encouraging about what I have managed to accomplish, and you have my thanks always.

But, bottom line: There are items that still require my attention, and in some cases may also require me to seek assistance from others with a better grasp of the specific issues. So, my aim is to create a running list here of the items I can remember/think of (to be updated as more are identified or checked off as completed), with any pertinent details that might be useful for resolving them. This way, it will not only help track the items in spite of my horrible memory, but it will make them easily visible to the team here, as well as open the floor for advice/discussion/questions/etc. So, in no particular order...

1. Clean up/properly import Marisa's Pseudo HUD Messages and credit her in comments/credits -- COMPLETE
   A while ago, ACS-based HUD messages were broken. This has since been fixed, but in the meanwhile, I had decided to try switching over to something ZScript-driven, based on Marisa Kirisame's work. Last I checked, I had it working, and I have no intention to revert to ACS, even though that bug is fixed now. The problem is that I did a sloppy job of splicing in just the parts of her code that I felt I'd need, and I soon came to regret it -- I should have done a more wholesale import (making edits only if they happen to be necessary) and included all proper credits. This would be a non-functional change, but I feel it's important to correctly honor her work if I'm using it.
   Update 3/6/25: In light of Marisa's reputation (be it deserved or not; I am not equipped to judge the events), it was decided a while ago that, sadly, it would be prudent to distance this project from her, so I am hoping to find a replacement mechanism for the code I originally borrowed.
   Update 3/15/25: I have implemented a new system, developed by Agent_Ash
   https://github.com/jekyllgrim/ZScript-H ... /tree/main
   
   
2. Credit all my sources if possible -- COMPLETE
   On the topic of proper attribution... over the course of the project, I've brought in a number of new assets, primarily models borrowed from Half-Life mods. Unfortunately, I didn't keep good track of where I pulled them, and on top of that, there seems to be a big problem in the HL modding community of not listing credits or sources for assets. Still, I think the least I could do would be to mention where I pulled everything from, so I may have to go back through my library of mods and sniff out everything that I can.
   Update 4/2/25: Upon review, it looks like every new model I brought in comes from either Half-Life itself, or from what is collectively known as the UHD Model Pack, which in turn seems largely derived from the PlayStation 2 port. Attribution should not be very complicated.
   
   
3. Fix timing of HUD Messages -- COMPLETE
   I had implemented a mechanism to have the HUD messages match the length of their soundbytes, but it seems that something is off. I will need to investigate what went wrong and adjust it so they match again.
   Update 3/7/25: I believe I have this in working order, now. Will continue to tweak it if I find any further issues.
   Update 3/10/25: This continues to elude me. Nothing seems to match the timings I feed into my functions, so I clearly have something going wrong here.
   Update 3/15/25: I now have a formula that produces satisfactory results for every message in the game.
   
   
4. Fix Barney's Follow AI -- COMPLETE
   Over the years, I made several attempts to improve the methods Barney uses to follow the player. While I doubt it would ever be a perfect mimic of Half-Life, I had hoped for a way to make any Barney a potential follower, toggled by the Use key. Unfortunately, everything I've tried had some problems or another. When the time comes that I'm able to look into this again, I'll most likely need to ask if anyone has advice on a way around my shortcomings.
   Update 4/26/25: Now functional, even including voice lines for hiring, dismissing, or abandoning Barney.
   
   
5. Scientist behavior: Voices and Reacting to Danger
   Currently, the scientists don't react properly to danger (i.e. running around in a panic). My hope was to emulate Half-Life, where they would be calm under normal circumstances, but become panicked when spotting a monster, or manually told to panic by map scripts. I'll need to look into triggering them correctly.
   Scientists' voices also seem to be too loud from even considerable distances away. I don't think the player should hear them conversing from clear across the room/in the next room.
   
   
6. Brightmaps for Med/Armor Stations
   When I replaced the Med/Armor Stations with models, I no longer had use for the textures that went with the Linedef-based ones. However, this also meant I lost out on the brightmaps that said textures had. I know absolutely nothing about producing brightmaps, but if they can be made for these models, I want to include them.
   
   
7. Floating Platforms
   I have never been able to pick apart and understand the code used for the moving platforms in Xen, meaning I don't really know where to begin with fixing them. It's been years, but last we checked, they do not work for co-op. Personally, I find those sections to be unbelievably difficult, so I would not be opposed to re-doing them to make them easier. More platforms to jump between would be a great improvement, in my mind.
   Update 4/10/25: I have come to learn of this project by FishyClockwork, which may prove to be a viable solution, but it looks like it would be a rather involved effort for me to learn it and replace the existing system.
   https://forum.zdoom.org/viewtopic.php?t=75352
   
   
8. Map-Specific: P1M1: Elevator floor pattern - COMPLETE
   When the player rides the elevator, he can see that the floor pattern is offset differently after teleporting to the other end of the ride. A minor thing, but I hope it's not too tricky to fix. I'll look at all other teleport tricks throughout the campaign to see if they need attention, too.
   Update 4/3/25: Fixed by shifting the last part of the map over by 32 units to make sure it aligns to the 64x64 grid that Doom demands.
   
   
9. Map-Specific: P1M1: Water tanks -- COMPLETE
   The water tanks in the intro section have looked wrong for a very long time. The wall of the glass tank seems to glow. I don't know enough about linedefs to spot the cause, but I want to look into this again someday.
   Update 5/30/21: Seems to be working correctly now. If the issue resurfaces, I will study what specific change/setting may have caused it. If not, then nothing to worry about anymore.
   
   
10. Map-Specific: P1M5: Exploding wall -- COMPLETE
    After Dr. Zimmerman has spoken to the player, the wall upstairs should blow open. For some reason, it doesn't seem to now. Must investigate...
    Update 3/6/25: Seems to work. My memory is bad, so maybe I was simply forgetting to hit the button that triggers this event?
    
    
11. Map-Specific: P1M6: Animate the MTM-8 Robotic Loader
    The Loader blocking the door near the start of the map is meant to move after the player has found a way around, to open up a quick return route. I would like to make it actually walk itself to the new position instead of simply teleporting, just in case another player in co-op is staring at it when it should happen. I'll need to find the best way to make it walk there, ensure the animations are included, and also make sure there isn't a way for it to trap a player (maybe make it no-clip until it's finished moving...?)
    
    
12. Map-Specific: P1M7: Make nerve gas painless
    When the player is being harmed by nerve gas, there's possibility that they will receive feedback the same as if they were being shot or otherwise injured. I think it would be better if they got a different, more subtle indication that they were losing health.
    
    
13. Merging in Rex's map updates
    As it is possible that Rex and I have worked off of different map versions, any updates Rex contributes may need to be carefully merged in with anything I have done. Should be doable; just needs some extra attention so that nothing is overlooked.
    
    
14. Sgt. Harrison -- COMPLETE
    I am incredibly frustrated by this. I cannot seem to get Harrison to walk around his room the way he is supposed to during his scripted scene. Everything I try seems to make it worse. Will absolutely need help making this work correctly...
    Update 3/10/25: After hours of tweaking and trying many little desperate changes, it finally mostly works now. I swear, getting an actor to walk a straight line in this engine is like herding cats!
    
    
15. Player Setup Menu -- COMPLETE
    I had modified the Player Setup menu to accommodate the multiplayer skins I implemented. It looks like GZDoom has redone how that menu is handled, so mine doesn't work anymore, and I can't really understand the new menu system enough to replicate what I'd done before.
    Update 3/10/25: Re-implemented a stripped-down version of the old menu.
    
    
16. Map-Specific: P1M5: Slippery headcrabs
    The cavern in P1M5 has a conveyor belt effect applied to a small downhill stream. Headcrabs are particularly vulnerable to this effect, with their small mass, and if they should perform a leap, they can slide clear across the cavern like they're on ice. I'm considering removing the effect from the stream. It doesn't make much sense to me, anyway, for a person to be pushed along by barely ankle-deep water.
    
    
17. Map-Specific: P1M3 and P1M5: Climbing into tight spaces
    After learning the security override code in P1M5, a wall will be blown open so the player can crawl through a hole into a cavern. Later, when backtracking through P1M3, the player will find a duct in the back of a warehouse to escape through. In both instances, these tight spaces are very difficult for the player to fit into. I feel like they weren't as much of a problem in the past. Maybe the engine's collision has changed enough with time that it's a problem now. Either way, I'd like to look into making these spots easier to fit into, but I think I will need help from an experienced mapper...
    
    
18. New attack for Vortigaunts
    Rachael has provided a good proof-of-concept for a lightning attack that seems much more faithful to the Vortigaunt's attack in Half-Life. While I may still let them keep their current energy ball attack as a long-range option, I would like to consider giving them lightning for close-range combat.

Again, I will update as anything happens to be added/removed. Hopefully this long-overdue first step might help motivate me to actually get something done.

[Rex Claussen]

Welcome back, Ed!

[*]Brightmaps for Med/Armor Stations[/B]
I know absolutely nothing about producing brightmaps, but if they can be made for these models, I want to include them.

Nigel is your guy. He did all the brightmaps for both the games, and I believe he knows how to do it for models.

[*] Floating Platforms[/B]
I have never been able to pick apart and understand the code used for the moving platforms in Xen, meaning I don't really know where to begin with fixing them. It's been years, but last we checked, they do not work for co-op. Personally, I find those sections to be unbelievably difficult, so I would not be opposed to re-doing them to make them easier. More platforms to jump between would be a great improvement, in my mind.

This bit of GZDooM trickery involves complex code that I was never able to decipher. Therefore, "re-doing" them would be far beyond my abilities. I can certainly add platforms to make the jumping less frustrating.

[*]Map-Specific: P1M1: Elevator floor pattern[/B]
When the player rides the elevator, he can see that the floor pattern is offset differently after teleporting to the other end of the ride. A minor thing, but I hope it's not too tricky to fix. I'll look at all other teleport tricks throughout the campaign to see if they need attention, too.

At the time, the method I used yielded the most believable results. If you can find a better way to do it, go for it.

[*]Map-Specific: P1M1: Water tanks[/B]
The water tanks in the intro section have looked wrong for a very long time. The wall of the glass tank seems to glow. I don't know enough about linedefs to spot the cause, but I want to look into this again someday.

I'm not sure which glass tanks you're referring to. These ones?

[*]Map-Ppecific: P1M6: Animate the MTM-8 Robotic Loader[/B]
The Loader blocking the door near the start of the map is meant to move after the player has found a way around, to open up a quick return route. I would like to make it actually walk itself to the new position instead of simply teleporting, just in case another player in co-op is staring at it when it should happen. I'll need to find the best way to make it walk there, ensure the animations are included, and also make sure there isn't a way for it to trap a player (maybe make it no-clip until it's finished moving...?)

If you can animate the robotic loader we can use that feature throughout the game. Also, I recall that there was another map (perhaps in Paranoiac) where the robotic loader moves. I'll see if I can identify the map.

Hopefully this long-overdue first step might help motivate me to actually get something done.

Best wishes, friend.

[Ed the Bat]

Welcome back, Ed!

Thank you, sir! Sorry for the long absence, but I promise I never forgot about this project.

I'm not sure which glass tanks you're referring to. These ones?

Yes, those are the ones. From my end, they have always looked wrong (I had a screenshot of it for many years but, embarrassingly, cannot find it now...). But, I believe I recall that they did not look wrong for everyone, even when they did for me. I've also just checked for the first time in a little while, and I no longer see the issue. It's possible a newer version of the renderer (not to mention the switch to Vulkan) has spackled over whatever my problem was? I think I'm also on an essentially blank INI file, since transitioning the mod to an iPK3. Regardless, it looks okay now, and if I should ever happen to make it 'break' again, I'll analyze specifically what I did and go from there.

If you can animate the robotic loader we can use that feature throughout the game.

I can definitely animate it. The tricky part for me will be getting it to gracefully walk a set path without accidentally trapping or interrupting other players. I know it can be done, but I haven't really done something like this before, so I'll need to study up a little bit.

I've also just gone ahead and added a new item to the list that will primarily relate to you and I, Rex. Simply put, if you have any new map edits to make for the existing maps (not ones you're handling on your own such as Paranoia), in the event that the two of us have worked off of different versions of these maps, I will need to give special consideration to that when it comes time to combine our works into a final map. Certainly not impossible, but something that I'll need to bear in mind when the time comes. To that end, Rex, if you would happen to be able to provide a comprehensive list of your edits, that will be hugely appreciated. If that would be difficult, I won't begrudge you -- goodness knows I myself have done a poor job of tracking my specific changes. Anyhow, we can cross this bridge when we get to it.

Best wishes, friend.

Thank you again!

[Rex Claussen]

I've also just gone ahead and added a new item to the list that will primarily relate to you and I, Rex. Simply put, if you have any new map edits to make for the existing maps (not ones you're handling on your own such as Paranoia), in the event that the two of us have worked off of different versions of these maps, I will need to give special consideration to that when it comes time to combine our works into a final map. Certainly not impossible, but something that I'll need to bear in mind when the time comes. To that end, Rex, if you would happen to be able to provide a comprehensive list of your edits, that will be hugely appreciated. If that would be difficult, I won't begrudge you -- goodness knows I myself have done a poor job of tracking my specific changes. Anyhow, we can cross this bridge when we get to it

I haven't reworked any of the maps from Paranoid or Paranoiac, so we won't have any problems at present. I was considering rebalancing the maps to avoid lond-distance hitscan enemies, but I haven't done anything about it yet.

The only other global change I can think of is to include the "Earth" background music (or new equivalent music) for the Paranoid maps.

The biggest impediment I see is my complete lack of proficiency in UDMF mapping. I continue to map in DooM-in-Hexen format, but if it's necessary I will learn UDMF to be consistent with the project overall.

[Ed the Bat]

Not to worry -- I have made it a point to keep the maps in Hexen format specifically to avoid forcing you into a tight spot. I am no expert when it comes to maps and mapping, but to my knowledge, there is no huge benefit to UDMF for our purposes, so I'll refrain from rocking that boat at this time.

[Enjay]

Welcome back, Ed!

Seconded.

Brightmaps for Med/Armor Stations
I know absolutely nothing about producing brightmaps, but if they can be made for these models, I want to include them.

Nigel is your guy. He did all the brightmaps for both the games, and I believe he knows how to do it for models.

Brightmaps for models are basically the same as for textures or sprites: most of the graphic is black except for the bits that you want to be bright; the brighter the pixel on the graphic, the brighter that part of the texture/sprite/skin will appear in game. You make your brightmap graphic based on the model skin and use GLDEFS to tell GZDoom which skin graphic to apply the brightmap to. A good starting move is often to take the original texture/sprite/skin and turn up the brightness and contrast of the image in a graphics program of some sort.

A simple example is in order...

LightCube.pk3

(103.69 KiB) Downloaded 289 times

Just load it up with Doom2 as the IWAD and start a game.

[Side information, although many people make greyscale brightmaps, there is nothing to stop you using colours and sometimes these work out better than greyscale. Greyscale sometimes leaves unwanted bright "overspill" onto adjoining pixels and this is less obvious when the overspill is a logically coloured light. So these days I tend to make the brightmaps in colours that are representative of the colours that the various lights are meant to be.]

[Ed the Bat]

Thank you very much for the advice, Enjay! I will be sure to begin with this whenever I find the time/energy to try making the missing brightmaps.

[Rex Claussen]

It's not as if you don't already have enough to do, but I remembered one more thing to address. In this thread we discussed the need for replacement graphics for the stock DooM weapons for the Deimos Syndrome episode. We'll also need to insert the code from GZDooM and modify DECORATE. If we use models for the weapons in the HUD and/or as pickups we'll need to update the GLDEFS too.

[Ed the Bat]

Thanks for the reminder. I can certainly add that to the list.

[Rex Claussen]

Something else to consider, Ed: Currently, scientists and Barneys are either sprites that can be damaged/destroyed or models that can't. Specifically, the sitting scientists and standing-guard Barneys cannot be damaged. Because you've replaced all NPC sprites with models, it might be a good idea to allow the sitting-scientist and standing-guard Barney variants of the NPCs to take damage too. This will make the game more realistic. (I presume the sprite-to-model replacements can take damage.)

[Ed the Bat]

Yes, I've done this already. Thanks for thinking of it.

[Rex Claussen]

Yes, I've done this already. Thanks for thinking of it.

Very cool. I just need to check each map to make sure the player can't kill an NPC essential for making progress. If I remember correctly, the Barney at Map01 and the Barney at Map02 are the only "unprotected" and "essential" NPCs - Barney at Map02 gets killed when the resonance cascade begins, Barney at Map01 is scripted to disappear (I believe).

Sgt. Harrington in Map05 (IIRC) is behind a bulletproof glass and is protected.

The only other NPC that we need to protect is Dr. Zimmerman in Map08 (IIRC). This might be a challenge, as the player enters the jail cell where Dr. Z is being held, and the player could kill Dr. Z. [Unless we decide that this will be an exception to making NPCs susceptible to damage.]

Btw, Dr. Z does make another appearance in Map25 (in the Paranoia redux, but I made sure to put him behind bulletproof glass.

Sgt. Harrington makes an appearance in Map26, but is protected behind bulletproof glass.

[Ed the Bat]

As it stands, there's no legitimate way to kill the essential Barney, since the player will have no weapons at this point. We can make him invulnerable and/or ensure an invisible wall is behind him, just to prevent cheaters from breaking sequence. I could do the same for Sgt. Harrington, just in case.

Dr. Zimmerman is already invulnerable -- I don't have any model animations for him to feel pain or to die, anyway. I personally think it would be best to keep him invulnerable.

[Rex Claussen]

As it stands, there's no legitimate way to kill the essential Barney, since the player will have no weapons at this point. We can make him invulnerable and/or ensure an invisible wall is behind him, just to prevent cheaters from breaking sequence. I could do the same for Sgt. Harrington, just in case.

Yes, Barney at Map01 is safe, as is Barney at Map02. I am not worried about Sgt. Harrington, because of the bulletproof glass. Even if he is killed, the script that begins when the player enters the armory will continue. If someone wants to cheat and enter that area, they're deliberately risking breaking the game progression. This ought to be universally true throughout the game.

Dr. Zimmerman is already invulnerable -- I don't have any model animations for him to feel pain or to die, anyway. I personally think it would be best to keep him invulnerable.

Yes, the original Dr. Z was invulnerable, as it was a static model. I didn't know if you had changed anything, which is why I asked. As you suggested, the simplest option might be to keep him invulnerable. One other option is to have a force field in his jail cell that protects him from attack, but this seems like overkill.