View source for Rejected Script Feature Requests

This page is a history of [[Script Feature Requests]] that have been rejected. Each entry has a small explanation of why it was rejected.


* iTrainz Chat to work with the #trainz IRC chat room. -PerRock
:''The iTrainz network cannot connect out to the public internet for security reasons. This means that it's not possible for scripts to connect to an IRC network. It's possible that someone could write a native bridge program that signs on to both the IRC channel and also on to iTrainz, and passes data between them, however that's not something that Auran will be spending time on. Our current focus is to improve the in-game chat UI. There's no reason that a third party could not write a bridge program once we release the [[iTrainz]] APIs.'' -chris

* Ability to issue an XML-RPC Call (SOAP) for sending/getting information from a server ~Jenolan
:''As above, we're not allowing access to the public internet for security reasons. This policy won't change in the near future. Again, it should be possible to write a native bridge once we release the APIs.'' -chris

* MD5 of the serial number available for gaming support to stop Warez kiddies ~Jenolan
: ''I don't believe there's any need for this. Use the iTrainz username- it's in Auran's interests to make sure that this name is validated, it allows you to associate the request with a particular user, and it removes any need for a system to validate cd key hashes (which is a security risk in itself).'' -chris

* Menu control, ability to have menus that run other assets (Activities) or chain to another menu asset, also ability to chain to a menu from an Activity ~Jenolan
: ''As discussed, this is an Auran-driven request which I'm hoping will make it onto the TS2009 schedule. It doesn't need to be repeated here.'' - chris
: The need is still there, and activity/menu chaining so long as we get it :)

* Ability to control pitch modifying sound introduced in TC (was via a config.txt entry) but in some form of a script command for more realistic and complex application. Something that would not necessarly be limited to train speed but instead multiple sound files pitched at a script controlled level by the creator. -SV
: ''Too performance-heavy. This is something that would need to be updated per frame and as such is not a candidate for script control.'' -chris

* Ability to change the users screen resolution ~Jenolan
: ''This is something that the user controls; giving the script control would have minimal benefit and could lead to a very poor user experience. It's also a lot of work.'' -chris

* Conditional includes:
 if (Trainz.GetVersion() >= 2.5)
 {
   // compile this only if actually included
   include("trs2006.gs")
 }
 else
 {
   // compile this only if actually included
   include("trs2004.gs")
 }
:This came up when getting handles on a vehicle bogies.  This can only be done by undocumented methods in 2004 but 2006 has GetBogeyList(). Since the script involved was for both versions I had to use undocumented methods in 2006 also. -Andi06
: ''This is a good idea, however it is impractical for us to implement at the current time.'' -chris


* When I made some considerations about a better signalling system, one major problem was that there is no real support for a fundamental component of real world signalling: track circuits. However, while triggers do have similar properties, it is not acceptable for a layout designer to cover the rails with triggers, especially as the radius is not visually exposed. It is probably going too far, but a new editor tool allowing the subdivision of the track into sections, which then operate similar to triggers, would be a plus. Alternatively, allowing triggers to work like axle counters (i.e. radius 0 and reporting the direction as well) would solve this. - [[User:Klausm|Klausm]]
:''Triggers are not intended for signalling support, so you'll probably find that any signalling system based around them will be inadequate. Please review the [[TrackSearch]] documentation and let me know if there's any functionality missing that you require.'' -chris
: ''Marked as rejected due to lack of updates.'' -chris
:: sorry, I have other duties. TrackSearch is nice, but has two major drawbacks: first, you need to poll continuously/periodically for all sections to be monitored instead of being notified by a message; second, when hitting junctions, you only see one path, depending on the position of the junction, which would require even more TrackSearches to be done. Btw., the Track object could take over the functionality BUT their existence is intrinsic and not user editable (except by adding junctions). - [[User:Klausm|Klausm]]
::: ''Signals do not need to poll; they have a single entrypoint which is called from native code, and they should perform a full update when this call is made. In TS2009, the native code does not poll this function, so you only have to worry about your instantaneous performance cost, not an ongoing cost.'' ~chris
:::: My ''personal'' interest is to manage the signalling logic ''outside'' of the signals, as in my humble opinion ''fully'' prototypical signalling cannot be implemented otherwise. It needs a global view and a global controller instead of the local view of each signal. I don't know whether such functionality is in the interest of Auran and/or the community, as such I respect the decision for the requested features not being made available. - [[User:Klausm|Klausm]]
::::: The major problem in going to a fully ''proto'' signalling system isn't centralised or localised control - this is just programming style. IMHO Localised control can give the appearance of centralised control to the driver with careful coding, while maintaining the benefits of seamless automatic configuration. The most important step towards going fully ''proto'' would be deliberately not clearing a controlled signal until the track beyond (right up to the next signal) has permits granted for the approaching train. From the signalling perspective, it's not that difficult. Inspect the track, check it all has permits granted, make sure all the junction levers are locked. Unfortunately this would require major surgery on the AI, and a rethink of how a human drives a train too, as neither would be able to get past a junction if the signalling system did this... -James
::::: ''To continue on from James' comments, TS2009 custom signalling requires the use of Signal scripts. You may implement a library which coordinates state between signals if you choose, however there is no mechansim for doing away with Signals completely.'' ~chris

* Need to be able to do an MD5 for various purposes, eg String.MD5( "TEXT" ) not just for password (ours) over iTrainz but also as a log check. ~Jenolan
: ''You can implement this yourself in script. I don't feel that there is sufficient reuse potential to warrant us doing an implementation.'' -chris


*Ability to add/remove or hide/show scenery items ~Jenolan
: ''This sounds like it's possible already. What did you want changed here exactly? ~chris''
: ''Marked as rejected due to lack of updates.'' -chris


* Add messages about keyboard keys pressed. This will allow to use hotkeys not only for cab scripts, but also for junctions, signalling, various session rules etc. -Mike
: ''We will not be simply passing through all keyboard information because this breaks localisation support. Specific key input requirements may be requested, but we will not be providing a generalised solution to this at the current time.'' ~chris


* Ability to remap keys via script. As far as i know, the mapping of keys cannot be done right now. One can only listen to messages coming from keys that are already mapped by TRS (like throttle up or throttle down) wich greatly limits our choices (unless there is some other way i dont know of). So the ability to remap keys via script.
:''See above response.'' ~chris