Posted: Tue Jun 10, 2014 10:28 am Post subject: [ACS] Get string input
Today Doom grows and flourishes, all thanks to ZDaemon! When the majority of games are conducted with mainstream machanics we all love, we also see many new interesting experiments with gameplay which contribute to Doom thrive and diversity, enriching it with new approaches and ideas!
Therefore, I would also propose implementing a functionality to enable scripts read users string input. This will give mapmakers much more ability to make things interact with the player. It could lead to some plot-oriented gameplay where players can be involved in decision making, like in text adventures, or could be given an ability to control certain scripts or thinkers. For example, a player, standing in a special sector near a control panel, could enter commands to control various behaviours in the map. And so on, the list of possibilities is limited only by your imagination..
String input is something that would work where the good old switches just don't cut it. The amount and diversity of information that could be input, and also the ease and clarity is far superior than of switches.
So, to be more specific I would propose the following variants of mechanics implementation:
1) Each time a player inputs something in the console, that is not yet reserved, the string goes to a special ACS script where the mapmaker can process it as he wants, also checking various conditions.
2) When an invitation to type something comes up, the player can enter his string either in console, or say (the T button say). Just the very same mechanics as with voting "yes/no" we have today.
I think that this functionality is not hard to implement at all, it looks very basic. It also could lead to the creation of a std ACS library to work with strings..
What do you think?
UPDATE: just thought that strings might get interned by the system and generating them dynamically could make quite a task. But I think that if instead of strings we could get arrays of ints, for the chars, that would still suffice!
I agree something like this would be nice to have, but not in the way you describe it since ACS does not work like that. Reserving a script for string input does not help the modder in any way, and would just create conflict with already existing maps which happen to use that certain script number.
A more intuitive approach would be to have the server store string variables for each player which can be obtained using GetCVarString through ACS (of course this implies that GetCVarString needs to be implemented). Contrarily to what you say, I don't think everything the player types in (console or chat) needs to be recorded because that is unnecessary and would create confusion. Instead, a special console command could be used which forwards the input string to the server (and storing it in the player's own variable there).
1. Player0 types in the console:
send My name is Robb
2. The "send" console command sends the message to the server, which stores the string "My name is Robb" in the variable named "player0".
3. The modder can use the following in ACS to print Player0's last sent message on the screen:
This is a very reasonable solution for this request, apart from having a separate variable for each player on the server which looks a bit messy...but there are no console arrays now are there?
Extend GetPlayerInfo with PLAYERINFO_STRINGINPUT definition which points to the stored strings the way they were described earlier. This method would be a bit more flexible, since you can refer to players using their playernumber, instead of getting server variables directly. To be honest IDK about developer side, but since GetPlayerInfo returns only integer values, returning strings as well might cause problems (function overloading needed??)
Before I reply to this specific request, keep in mind the following: if you (mapper/modder) guys need extensions to ACS, your best bet is to go to the zdoom forum and ask the zdoom people to implement them; if they decide to do so, then we could try doing the same. I'm really not hot at all about forking ACS (and implementing our own ACC, etc). The most "forking" of ACS I could see is the definition of a few constants; things like adding new functions or extending / modifying existing ones are a no-no.
Going now to the specifics of this request: a general implementation of "GetCVarString" is quite more complicated in a client/server setting as opposed to SP; think about how one would implement that: do we want all client cvars sent to the server all the time? (no way: too much traffic), Do we want the server to query the client about each cvar as needed? (what would the script on the server do whlie it's waiting for a reply?). We could go for a restricted version of GetCVarString (eg., one that works only for the playerN cvars), but that's a hack. The GetPlayerInfo extension sounds more reasonable (since only a new constant is added to ACS, we don't need to provide a new ACC). We would also need some sort of client command to specify such strings. Would that be OK by you guys?
Hm, as for the general implementation of GetCVarString: maybe send the string cvars to the server once upon the player connects, and send only again if a cvar changes. This assures that the server will always have information about the cvar, so ACS doesn't have to wait. No need to keep them in sync, the client detects if the value has changed (by storing previous value as well, and making comparison), and sends new info to server if needed (there can be occasions where the info on the server is outdated but maybe only for several miliseconds until client sends new value).
I would also prefer the GetPlayerInfo variant, but keep that in mind that in this case, GetPlayerInfo would need to return a string (the value of the queried variable). And GetPlayerInfo is defined to return integer values, and there is no function overloading in ACS to allow different return types for one function.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum