View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000426 | LDMud 3.5 | Implementation | public | 2005-12-13 21:35 | 2011-02-14 17:11 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | duplicate | ||
| Summary | 0000426: Generic text-reformatting functions for all input and output | ||||
| Description | I suggest adding optional text-reformatting functions to add_message (comm.c) and get_message (comm.c). This goes beyond what you could hack together on the mudlib-side with catch_tell() and input_to()--ALL text sent to and from any interactive would be changeable this way. It would work something like this: add_message, before sending output to an interactive object, would send the text through a reformatting function in master.c. The result would then be sent to the interactive object. If the function called in master.c returns 0, the original text is sent to the interactive object unmodified. One function would be called to transform text for the main interactive user. A DIFFERENT function would be used to transform text for a snooper. The text the user actually sees may be significantly longer or shorter than what is initially sent to them. --- Example code: comm.c --- save_current=current_object; current_object=master_ob; push_object(inter_sp, ip->ob); push_c_string(inter_sp, orig_str); ret=apply_master(mstring_new_string("reformat_output"),2); current_object=save_current; if(ret->type == T_STRING) { source=malloc(mstrsize(ret->u.str)+1); strcpy(source,get_txt(ret->u.str)); } else { source=malloc(strlen(orig_str)+1); strcpy(source,orig_str); } xfree(orig_str); srclen=strlen(source); ------------------ --- Example code: master.c --- string reformat_output(object user, string text); string reformat_snoop_output(object user, string text); string reformat_input(object user, string text, status noecho); string reformat_snoop_input(object user, string text, status noecho); ------------------ GOALS: Once something like this was in place for both inputs AND outputs, many things could be accomplished on mudlibs: 1) All text messages could be sent to and received from users as UTF-8, assuming the user had defined their charset. charset conversion issues would all be handled in one standard place. 2) All "flowed" text could be send without linefeeds, and wrapped to match the width of the target terminal. 3) Special terminal codes could be sent as generic markup which is translated to terminal-specific codes when it is received (and discarded for snoopers if that how the mudlib designer would like it!) 4) Other markup could be sent that resolves text differently depending on the user seeing it. 5) These functions would allow users to implement additional mudlib-side snooping functions if they like. My example sets the current_ob to master_ob so that the functions in master.c can do security checks to ensure the calls are from a valid source. I am very excited about seeing functionality like this. Let me know if I can be of any assistance. My C coding skills are pretty poor--the samples up above are pretty much my limit. | ||||
| Additional Information | Possibly obsoletes bug#0000215 FYI--I'm also working on some text-manipulation functions for multibyte-encoded strings. More on that when they work better. | ||||
| Tags | No tags attached. | ||||
| duplicate of | 0000215 | new | Output hook |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-12-13 21:35 |
|
New Issue | |
| 2009-10-06 03:55 | zesstra | Relationship added | duplicate of 0000215 |
| 2009-10-06 04:07 | zesstra | Project | LDMud => LDMud 3.5 |
| 2011-02-14 17:11 | zesstra | Note Added: 0001983 | |
| 2011-02-14 17:11 | zesstra | Status | new => closed |
| 2011-02-14 17:11 | zesstra | Resolution | open => duplicate |
