Adventures in modding

While I'll agree that the last case in particular is blatant copy-paste that's been missed, the first one "Lazy typer" increases the legibility of any code using it, which is an improvement in itself. Which would you rather be reading, if(tokens.length() >= MAP_NAME && hasCommand(player, "loadmap")) or if(tokens.length() >= MAP_NAME && getSecurity().checkAccess_Command(player, "loadmap")) ?

That said, I think it's good to have a topic where you can go through code that you feel doesn't make sense and ask questions about what's going on there - often times there's "a reason", but whether that's a good one or not is always up for discussion ;) Always good to have a dialogue going.

 

No not really, this is just no reason to waste more lines of code by creating a security and boolean variable beforehand. Nothing very complicated in there.

Nothing wrong with a while loop here, it literally does the same thing a for loop could've done. While loops can be especially useful when you don't know how many times it needs to iterate, but not in this case. Still though, nothing wrong here.

The weird thing here is that mapname and map_name are being declared twice. I'll admit though, that I sometimes do the same thing here because sometimes it is easier to copy and paste the code I just wrote than to move shit around.

 

Silly mak; the weird thing is that the two sections are exact duplicates and the second will never be run, the commands are the same :)

 

haha i completely missed that part, i just assumed that there was something slightly different

 

The while loop one is either taken directly from vanilla or a mod that copies it directly.

Actually makes sense from a seclev point of view (as if you want to have 1000 extra seclevs), but I'll be honest and say I missed this :)

 

fwiw this one (though there are some that break the rule) is actually just a strange convention. Methods that returns something is in lowerCamelCase. Stuff that doesn't is UpperCamelCase. Server-only stuff gets server_ appended and then (usually) is UpperCamelCase. Its madness, but there's a pattern to it; you can quiz MM on the logic.

Otherwise, yeah you're generally right. The core of the engine code is pretty much set in stone, or at least set in spaghetti. The recent slew of rendering bugs is testament to that. Furai fixed the windows server not downloading API-hosted mods recently, which resulted in the windows server crashing :) Fixing that meant everything "works as expected" but it's like playing whack-a-bug.

The scripts themselves also languish over time though - noone wants to touch the builder code any more, for example.

Not a lot changed in the "core" of the engine for TR - but a lot of stuff was exposed. The map system in TR totally replaces all the tiles in KAG and their behaviours. TCPR support was tightened up a little to allow communicating with the TR backend (longer lines supported, random disconnects fixed, works on windows). Some weird bugs with adding/removing shapes from objects was fixed. Being able to change the map-edge behaviour was fixed. Shaders were exposed to scripts + received an "extra texture" input. The rendering system was partly forked to allow rendering to a lower-resolution framebuffer.

 

On notation choices - offtopic but worth talking about since it's something new programmers often get hung up on. Like most things, it's a totally religious argument and there's no "right answer".

If there is a right answer though, I don't think that it's the system used in crimson ;)

Spoiler: my thoughts on code formatting and notation

I'm currently of a fan of underscore_lowercase for methods and variables, _underscore_prefix for "dont use directly" or "read only" variables (private if you want but these can exist in structs too) and UpperCamelCase for types. UNDERSCORE_CAPS for macros.

I'm slowly coming around to the idea of underscore_lowercase for everything except macros though; screw that shift key. It gives a little less info away, but fits in well with standard cpp stuff and is harder to make typing mistakes with.

Never got into the typename_t pattern tbh, gives me too much win32 hungarian notation PTSD.

The main thing with any of it is being consistent. If you want your LPCSImpossibleToRead type names go for it. If you ReallyLoveJavaStyleNotation then hey, noone's stopping you. Just make sure that you dont jump schizophrenically between multiple styles - the crimson "rules" feel that way to anyone who doesn't know them, which is a sign they aren't great ones to follow.

Same goes for indentation - it "doesn't really matter" as long as you have a pattern, and that pattern is easy enough to understand.