A quick question for the main developers: how does one make use of the supplementary ("extra") character in the call_[something]_tool methods in simwerkz.cc? There is a short routine for extracting the main character to a char tool field in call_convoi_tool and call_depot_tool, but this is not replicated for the "extra" character. Is there some code somewhere that I can copy? Thank you.
maybe implement your 'experimental' stuff in a case 'X': of the main switch there. Then extract your secondary character and switch again (so two nested switch's).
sscanf( p, "%c,%hi,%hi,%hi,%hi,%c", &tool, &pos.x, &pos.y, &z, &convoi_id , &exptool);
The trunk code should ignore the exptool.
Dwachs,
thank you for your reply. Would this be instead of or as well as the current "extra" character?
what extra character do you refer to?
The second argument in the call_convoi_tool method.
Quote from: jamespetts on March 16, 2010, 12:36:46 PM
thank you for your reply. Would this be instead of or as well as the current "extra" character?
.. then I would say: in addition to this extra parameter.
And please say, which letter you will use for the experimental's features, such that this letters can be commented as 'reserved' in standard trunk.
Quote from: Dwachs on March 16, 2010, 03:12:56 PM
.. then I would say: in addition to this extra parameter.
And please say, which letter you will use for the experimental's features, such that this letters can be commented as 'reserved' in standard trunk.
I'm slightly confused - do you want me to use a reserved list of letters for Experimental, or use a special extra parameter as discussed above?
List of reserved letters for new features.
Or do you speak about just modifying the standard behavior of the tools to fit your needs? Then an extra parameter would do this.
I think a simutrans-standard server should be able to ignore experimental commands actively: The server should notice when an experimental command arrives (hence the reserved letter .. a command with a reserved letter is from experimental and will be ignored).
Maybe this should be handled upon joining of clients: such that a standard server will reject experimental clients and viceversa.
Given that Standard servers will never be compatible with Experimental clients, rejecting on joining seems much more sensible. But that brings me back to my original question, which wasn't about differentiating Experimental on a server at all - how do I make use of the existing feature to use a second character in those tools?
It seems I misunderstood you. The extra parameter contains a schedule (convoi tool) or a window magic number (line tool).
See eg. fpl->sscanf_schedule( p ); and the corresponding sprintf.
You can use the extra parameter as you like. It is only interpreted under certain circumstances, as you can see in simwerkz.cc.
I have managed to get it working as an additional character, which is useful for re-using code where there are multiple related tools. One other question: do the letters have to be unique across all tools, or just unique for the particular type of tool?
Dwachs,
I have been looking at this to-day and I think that I see how it works. However, a further question: where is the cbuffer_t object containing the schedule transmitted accross the network?
cbuffer_t is defined in utils/cbuffer* ...
And it is transferred as a string, since its size is known.