Scripting: Write; WriteLn without the line

[DorkeyDear]

It would be useful to have a function with similar behavior as WriteLn, that is write to the server console, however without the extra newline at the end. A function called simply Write sounds almost appropiate (WriteLn without the Ln), however the name is not very suggestive on what it actually does (but then again neither does WriteLn). Any further name suggestions?

Use case: When an action on a Soldat server script is expected to take a considerable amount of time, it is beneficial to write to the server console showing when the task has started and completed. This allows for those who happen to be viewing the server to see if the script is currently busy on that task, or may possibly completely froze then (if it takes much longer than expected).

Code: [Select]

WriteLn(' [*] Performing long task...');
LongTask();
WriteLn(' [*] Long task done.');Using only WriteLn. Right before the long task, a line is written to the server console stating the long task about to be performed. After the task has been accomplished, then yet another line is written to the server console stating the long task has just been completed. This is sufficient, however it requires two lines. If multiple long tasks are to be ran, the console could be spammed by these start and stop messages. If the long tasks are consecutive, it could be possible to merge the end of a long task wit the start of the next long task messages. This may cause for further uglyness, however.

Code: [Select]

Write(' [*] Performing long task... ');
LongTask();
WriteLn('done.');Allowing for Write. Right before the long task, text is written to the server console stating the long task is about to be performed. After the task has been accomplished, on the same line, simply 'done' is written out in the server console on the same line (followed by a newline). This literally would require half the amount of lines as the initial approach and making it cleaner looking. This would require one less line for the other initial approach (when merging start and finish messages), and make it significantly cleaner looking.

Example console output with many consecutive long tasks, initial approach:

[*] Performing long task (1)...
[*] Long task done (1).
[*] Performing long task (2)...
[*] Long task done (2).
[*] Performing long task (3)...
[*] Long task done (2).

Example console output with many consecutive long tasks, other initial approach:

[*] Performing long task (1)...
[*] Long task done (1). Performing long task (2)...
[*] Long task done (2). Performing long task (3)...
[*] Long task done (2).

Example console output with many consecutive long tasks, allowing the Write function:

[*] Performing long task (1)... done.
[*] Performing long task (2)... done.
[*] Performing long task (3)... done.

[SyavX]

Example console output with many consecutive long tasks, allowing the Write function:

[*] Performing long task (1)... done.
[*] Performing long task (2)... done.
[*] Performing long task (3)... done.

But if there was some text written to the console while one of your tasks performing you'll get:

Code: [Select]

[*] Performing long task (1)...
[*] <Some text here> done.
[*] Performing long task (2)... done.

[CurryWurst]

In general I approve this proposal, but as discussed on #soldat.devs threading might be an issue, so scripters need to be careful when dealing with console output from different sources (threads within a single script score instance, dynamic libraries). As temporary solution one could write a dynamic library which runs on both, Windows and Linux (and perhaps Mac OS X, since Shoozza seems to endeavour to make the dedicated server compatible to Apple's operating system), containing the functionality requested above.

[DorkeyDear]

@SyavX: Some care must be taken when to actually use this function. If the 'long task' writes to the server console, the use-case provided probably isn't wise. Keep in mind this was only one example, and there are probably others which exist.

A point was brought up on IRC. Messages written to the server console are also sent to people connected via admin port (ARSSE). What would the expected behavior in these situations be? Maybe only send the data to the admin port connections after a newline has been outputted? What if some data is received during this period? Should it spew it to the sever console right away? If this requires significant changes, is it worth all the effort involved for something so simple? Maybe there should be a way to write to the server console, while bypassing all other 'outlets'.

A different point was brought up on IRC. As always, when threads are used, much care must be taken. This pretty much applies to everything though, hehe. I could be possible to use Write, and then another Write or WriteLn to interfere with the flow of what is currently in the console from a different thread.

I was informed the whole scripting system is running on a different thread. One may think that in the middle of writing to the server console using Write, an admin port message such as REFRESHX could be received. This may cause for further complications, however I'm not fully aware on how these work exactly, and am not going to pretend to.

Maybe some sort of locking mechanism already exists when using WriteLn, thus why issures regarding REFRESHX (and other 'normal' messages as well) are tended not to be seen when using that (it doesn't accept any external data during this time maybe). Maybe functions to lock and unlock the server console in this manner would be good, however in my opinion, if so, should require safemode to be disabled.

[Shoozza]

to summarize:
1) Sending to Admin Clients wont work (ARSSE expects \n afaik)
2) Showing in console wont work (new lines like player joined could break the output)

Maybe 1) could be fixed if we redo the admin protocol but that will not happen soon.
as for 2) I'm not sure if that is even fixable because you just cannot buffer stuff (people could think the server is hanging... etc).

[Fryer]

I guess the problem could be fixed quite easily by just waiting for the script to run WriteLn, and then writing the line to the console. The buffer for each script should of course be kept separately (if this is easily done somehow (I've not looked into the scriptcore much, so I don't know)).

[Shoozza]

I guess the problem could be fixed quite easily by just waiting for the script to run WriteLn, and then writing the line to the console. The buffer for each script should of course be kept separately (if this is easily done somehow (I've not looked into the scriptcore much, so I don't know)).

I don't think there is a reason for implementing it in this way. The main issue is that it should output the line and then the success failuer message so people see that the event is in progress.
Your idea could be implemented in this way via scripting:

var
  Buffer: string;

function OnEvent(...);
begin
  Result := True;

  if ConditionOneApplies then
    Buffer := 'MessagePart1 ';

  if ConditionTwoApplies then
   if ConditionSuccess then
      Writeln(Buffer + 'Success')
    else
      Writeln(Buffer + 'Failure');
end;

The other idea would be to output stuff with writeln but remember the position of the last write in a script and append the new text. This wouldn't work with the current admin protocol and
not sure if delphi/Lazarus has functions to write at position xy in the console (aka stuff that conio.h can do on windows with c++) but if it does there are still problems with too long lines.

IMHO it's not a good idea and will increase code smell.