Scags
commented
4 years ago I've got a nice sketch down so far, but it completely changes how forwards are done internally. Essentially, there won't be forwards. I'm adopting and adapting what Boss Fight Fortress does. External implementation will be almost the same, but internally, instead of forwards, I will manually go through an list of function ptrs. Pseudocode below:
public void Freedays_Init()
{
// New method for creating last requests
g_FreedaySelf = new LastRequest("Freeday for Yourself");
// Only fires when it is *this* last request index
g_FreedaySelf.AddHook(OnLRPicked, FreedaySelf_OnLRPicked);
g_FreedaySelf.AddHook(OnRoundStartPlayer2, Freeday_OnRoundStartPlayer);
g_FreedaySelf.AddHook(OnLRDenied, Freeday_OnLRDenied);
g_FreedayOther = new LastRequest("Freeday for Others");
g_FreedayOther.AddHook(OnLRPicked, FreedayOther_OnLRPicked);
g_FreedayOther.AddHook(OnRoundStartPlayer2, Freeday_OnRoundStartPlayer);
g_FreedayOther.AddHook(OnLRDenied, Freeday_OnLRDenied);
g_FreedayAll = new LastRequest("Freeday for All");
g_FreedayAll.AddHook(OnRoundStart2, FreedayAll_OnRoundStart);
// Global hooking, same as before
JB_Hook(OnTakeDamage, Freeday_OnTakeDamage);
JB_Hook(OnCheckLivingPlayers, Freeday_OnCheckLivingPlayers);
JB_Hook(OnLRPicked, Freeday_OnLRPicked);
JB_Hook(OnRoundStart2, Freeday_OnRoundStart);
JB_Hook(OnPlayerSpawned, Freeday_OnPlayerSpawned);
JB_Hook(OnPlayerDeath, Freeday_OnPlayerDeath);
}Each last request handle will either be a KV or a StringMap, I haven't quite decided yet. KV feels nice because it'll need to cache the structure anyways for config support.
The main struggle is probably going to be managing all the function pointers. TF2JR might not have forwards anymore (minus the bcompat legacy forwards), so I'll be running through a list of them and checking if they're a valid func.
It'll probably fire the global (JB_Hook) functions first, then the ones that pertain to the certain last request that's happening (or involved).
Did I mention that this will absolutely destroy backwards compatibility?
MrPanica
Stropyt
Alright, it's time I picked this back up. There's a lot of things that I want to rework and redo. For one, I want to redo how last requests are made.
I'm thinking that the core plugin TF2Jail_Redux can be the engine to build last requests/sub-plugins with. That way, coders won't have to worry about mucking through code to add an LR.
I want the main plugin to be the engine that handles the game mode and its execution. Subplugins (mainly LRs) would be able to pick and choose what to do and when.
Secondly, config support for LRs. I'll make it optional; pull some method how to do that later.
Redo plugin registration (No more plugin handle storage!!!!).UNfortunately, going to have to store plugin handles if I want to call functions manually for last requests. Shucks.Have a proper subplugin system (libmodule).This isn't as important as I thought it'd be, there won't be plugin registration anymore since Last Requests are almost mini plugins. It's almost the same process as before but at a much smaller and easier scale.