Some parts of the code are mostly very easy to understand, like the proc code interpreter. Mostly, because it still involves knowing when you should push, pop, or peek on the stack and when to attach vars or just assign them, to avoid memory leaks and premature deletions. It's no coincidence that the first thing I ever did with BYOND's code was implement new list procs.

But just to give you an example of how complex it gets sometimes: Back when BYOND was limited to 2 bytes for just about everything, we had a lot of vars and arguments being defined as u2c. That's the name we use internally for an unsigned short, with u4c being an unsigned long (32 bits). There were already a lot of named types, like DMObjId, that mapped to u2c. But in a staggering number of places, we weren't using those named types when we should have--just u2c. It was very very difficult to tell what should be changed to which types, and as a result I had to go spelunking through pretty much the entire codebase (except, to an extent, the front end) to clean it all up. I changed things to named types where I could--sometimes getting it wrong, which I still see at times to this day--and then had to go through the process of changing things over from DMObjId to DMObjId4, and changing all-purpose "this can be an ID for anything" values from u2c to u4c. Internal ID arrays had to change to 4 bytes, but there was so much code using the 2-byte version that I had ID arrays keep a shadow array of 2-byte values in case it was ever needed (which was only eliminated in a fairly recent version).

Reading and writing vars, lists, initial(), etc. is fun too. We have two routines, AssignTo_v1() (a read into a temporary value that the proc interpreter uses) and AssignFrom_v1() (a write), and until fairly recently I still had a really poor grasp on how these routines actually functioned. I had to dig deep into them to deal with compilation issues that came from Space Station 13 having var names above a certain string ID (manifesting in weird runtime errors). Those routines were practically undocumented.

Zasif wrote:

I don't like your answers lately Lumo, to much I don't feel like and I don't think it's a good idea, the use of just few games not worth it etc etc. Doesn't matter if it's just for one game that needs it and it can benefic that game then it should most definitely be considered and even added at a later point.

Work/reward ratio is always a factor. Always. It has to be. I've focused on features that would impact more games or make the engine more capable at large, or that have been so minor and easy to implement (like a timestamp on compilation for instance) that there's no downside including time investment. Tom was always very, very cautious about feature creep. I have grown increasingly cautious about it myself, because I know new features lead to new bugs.

In this case ask yourself: How many games would really want to offset the entire HUD by a fixed amount at once? Likely just about none. HUDs work best when fixed in place, animation concerns notwithstanding; having them move around, especially every single HUD object in the exact same way, doesn't make broad visual sense. Maybe one game in a million would ever have use for that. The work that would go into adding the vars and the messaging for this feature would be non-trivial, and having all screen objects use this offset would lead to DS doing more work to display screen objects (although the performance loss would likely be unnoticeable).