Okay, in light of kompressor's resurfacing (again), I'm making this topic (probably again) to request some minor features be made default. Not 'bring back terrain' or anything like that. Things that are sort of needed, able to be implemented assumedly in a relatively short time. Mostly relating to modding, not to gameplay.
If words hurt your brain, best proceed with caution.
Clientcmd for pushing the events dialog
Something like commandToClient(%client,'pushEventsDlg',%classname) would be ideal. (Actually, something like %client.pushEventsDlg(%classname) would be even more ideal, but it'd just be doing the first one.)
Being able to supply an arbitrary class name would allow for some extra functionality - drawing the input event list from this class name should be a fairly minor effort, and would allow such fun features as modding in minigame eventing, or eventing direct to vehicles or bots instead of clogging up the fxDTSbrick input list with things relating to other functions.
I've nearly gotten such a thing to work by basically rewriting all of the functions that generate the event lists, but it makes the GUI somewhat erratic and if not everyone had it, it wouldn't be much use. It'd just be splitting the community.
Support for ghosting object positions to clients
I don't mean the server constantly telling clients where something is - we can do that. But obviously the engine is aware of where an object is, the script engine simply isn't made aware of this, for players at any rate. This is to prevent aimbots which ruin deathmatch servers to some extent. What I'd like to see is an engine function that allows the server to tell a client it's safe to make scripts aware of this object's position, so that clientside compass mods (okay, yeah, I work on one of these, ulterior motives and whatnot) can track these objects. Specifically and only if the server allows it. That's what I'm asking for. Ideally, this would also call a script callback on the client when an object is made trackable or untrackable, so that we don't have to search for objects we can now track constantly.
%client.setObjectPositionsEnabled(%obj,%bool)
Default API to register required client mods
This is sort of a complex one. If you're familiar with the big old screamfest over the DRPG client breaking the CityRPG client, I'm asking for something that will allow us to circumvent this problem via a default API that will send certain versions to the server in the connect request. These would then be parsed immediately into values on the client object.
To explain exactly what I mean:
You would register a code for your mod, and its version, in the clientside part. registerClientModule("RTB",4)
When you connect to a server, this, and all other versions are jammed into a string. Would it be a problem if this bloated the request? Restrict the code to four characters, I suppose. Anyway, the server gets these in your GameConnection::onConnectRequest, in one argument - tab-delimited, like 'RTB 4\tDRPG 1.3\tCRP 0.2'.
These are immediately and by default parsed into values on the client. %client.version_RTB = 4, %client.version_DRPG = 1.3, %client.version_CRP = 0.2.
Then, a callback is called - GameConnnection::preConnect, for instance. The announcement that the client has joined still hasn't gone out on the server, so deleting the client at this stage would circumvent the message, allowing for assumedly safe and silent rejection if the client lacks something they need to play. It's down to the mod creator to issue a helpful message, obviously.
The reason I ask for this to be default is that such a system's usefulness is limited (in fact, near to nothing) if not everyone has it. Same for the clientCmd for pushing the events dialog.
API for registering brick values to be saved
Much like the persistence API but for bricks, values to be saved into BLS save files. Default systems to save and load bricks serverside directly would also be quite handy. The general idea is that you simply registerBrickValue("nodeName","") to register the value %brick.nodeName with a default value of "". If the value on the brick is not the default value, it sends this value to the client when saving events and other serverside brick data, and it would appear in the BLS as +-CnodeName hello_world among the other fields (+-VEHICLE).
This would allow us to save world-specific data in the file with the world itself, tidying things for makers of mods of this nature immensely. When I wanted to store a health value for bricks, I ended up circumventing the entire saving system and simply using MainBrickGroup.save() and exec() followed by a loop to manually call the planting functions on all bricks that were created, because it was too tedious to write a proper system to save this based on brick positions and reapply it on loading. This would tie in well, I think, with the 'build everything' theme that's coming along.
Fix for guiBitmapCtrl::getPixelColor(%x,%y)
This has been broken for as long as I've known about its existence. Using a guiBitmapCtrl placed on the main menu at 800,0 with an image of a solid color, it seems to return a result for 1,1 that changes as the image changes. Using 800,1 it returns the same color every time, but not the color that is in the bitmap. I have no idea what it's actually doing, but it's certainly not what anyone would expect. Loading heightmaps would be a lot easier if we could just load bitmap versions into a control and look at the pixels, so I guess this calls for a fix? Or at least a clarification of how it's supposed to act - no documentation seems to exist for this method.
Anyone else got anything to add? I'm insecure and every time I go to write this I freak the forget out and forget what I even want. Stupid brain.
