[FEATURE] T6 MP and ZM GSC Additions.

Topic created · 2 Posts · 289 Views
  • Summary of my feature request:

    1 Custom named script support for T6 mp and T6 zm.
    2 Functions inside of the custom scripts can be referenced by other scripts.
    3 The dvar "g_gametype" can point to a script with the same name if it can find it. For multiplayer set_gametype command does the same.
    4 map_restart/map_rotate reparses all scripts for easier modding.
    5 Command that lists the clientfields currently registered on the server, and if exe_client_field_mismatch occurs on the client it prints to the client console the clientfields registered and which clientfields are not registered on the client compared to the server. Also prints to the log for easier access to this data.
    6 A GSC function that would let you override any other script function in a stock script or custom named script with an input function.

    Elaboration on each one:

    1 Custom named scripts would be very useful for modders since it would allow for better organization of code because scripts can be dedicated to a specific part of the mod.
    This would mean no more cramming everything in one script and calling it _clientids.gsc. This also would make it easier to load multiple mods at once since each mod would have a unique name.

    2 This is very important because it would be possible to make util scripts for other scripts to reference even if the script itself doesn't execute any code.

    3 This is a feature that T7 has natively for its dedicated servers. Basically it allows for easily creating custom gametypes without having to override an existing gametype. With this it would be possible to include custom gametypes in rotations for mp and zm.
    This needs to apply to both T6 mp and T6 zm. T6 zm is a bit more tricky because from my tests it would be possible to make a custom gametype and load it, but it would require another feature that I will also suggest to properly debug for all maps.

    4 This is one that would be very appreciated because it is a feature that those familiar with [Redacted] have utilized. Adding this would make GSC modding a little faster.

    5 This would be helpful to me to determine what clientfields are not being registered on the server when a non-standard gametype is loaded. Every map in zm has the gametype "zstandard" on the fast file but its normally not used on any map other than Tranzit and Nuketown.
    If "zstandard" can be loaded and successfully allow clients in without resulting in exe_client_field_mismatch then the map can load any custom gametype. I've checked the .cscs so its likely to be fixable by registering the missing clientfields on the server.
    Other than this one use case if modding/map making/lua modding ever becomes available debugging clientfields will be important since they are used to communicate data between the client and server as well as the client and lua and as such will be required to be used in some cases.
    Therefore being able to debug them would be useful in the future as well as for this situation.
    The kind of debug data I would want to see is something like this:

    //Function ripped from ida, the last 5 inputs are for the clientside registration of the clientfield
    BG_RegisterClientField(pool, pName, version, numBits, fieldType, minFloat, maxFloat, func, bSplitScreenHostOnly, bCallbacksFor0WhenNew); 
    //What the server would print out
    "clientfield_type", "clientfield_name", game_version(int), num_bits, "value_type"
    
    //What the client would print out
    "clientfield_type", "clientfield_name", game_version(int), num_bits, "value_type", minFloat, maxFloat, func, bSplitScreenHostOnly, bCallbacksFor0WhenNew
    
    //At the end print out the total number of clientfields registered on the server and client
    

    T7 has this feature but I don't expect a full debugging implementation with several different types of error messages. Just simply printing out each registered clientfield on the client and server ought to be enough to be able to analyze so the cause of clientfield issues can be resolved.

    6 Currently if you'd like to modify a function in a core script or otherwise you need to recompile the entire script. Despite the decompilers available the scripts generated even after being checked are still prone to have many errors. Additionally it seems to be unecessarily cumbersome to modify a whole script just to change one function in some cases.
    So this is how it would work:

    _clientids.gsc
    init()
    {
    	level.clientid = 0;
    	level thread onplayerconnect();
    }
    
    onplayerconnect()
    {
    	for ( ;; )
    	{
    		level waittill( "connecting", player );
    		player.clientid = level.clientid;
    		level.clientid++;
    	}
    }
    

    In _clientids.gsc we have this function but we want to override it for whatever reason. Lets say we want to modify onplayerconnect(), without recompiling the script, in another script:

    init()
    {
    	ReplaceFunc("_clientids.gsc", ::onplayerconnect, ::new_func);
    }
    
    new_func()
    {
    
    }
    

    Let me know if this is not possible it does seem like a challenge potentially in comparison to the other additions.

    I will offer up $25 for each one; totaling $150.

  • Bug bounty will be looked at after T4's release.

Log in to reply