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. - 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). - 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. - 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

• Be able to interact with the outside world: ability to create a basic Socket or some form of a StreamReader/Writer to write to files or send messages via the network. -Roman

Script is intended for control of the gameplay environment, not interaction outside the gameplay environment. ~chris

• Make a way to determine if a vehicle is removed from the map (for example, using portals). Now external link returns non-zero value, but any function called results in an error. ~tram

You can already listen for the "Train", "Cleanup" on the train. ~chris

• Make a function to determinate, if a MapObject is closer to the camera, than specified distance. ~tram

Script is intended for gameplay control, not rendering control. ~chris

• How about adding to the trigger events. A new message sent when a train starts moving within the trigger would be especially usefull for animating doors and other objects which need to change if there is a change from stopped to moving. Another variation of working doors is if the trigger could monitor the trains bell. In real railroad operations a train tipically signals that it is about to move by turning on the bell and tooting the horn. So the train in a trigger sending the trigger 'bell on' or 'bell off' could be usefule because it would give the user some control over the animation. ~bigdave7533

You can achieve this kind of thing by sniffing vehicles/trains which are within your trigger. ~chris

• Pass ALL keystroke information to the cab/cabin script. Currently only a subset of the keys usable are passed to the script methods meaning the cab script cannot react to all the users control requests and the range of controls is not extensible. -eldavo

Please provide more information on what you want here. Which keys are you missing out on that you actually need? -chris

At this time Trainz does not passes via Cabin.UserPressKey(string) large number of keyboard shortcuts defined in file Settings/keyboard.txt. This makes difficult to override default cabin implementation and defining custom functions to keys. -Mike

As above, please provide specifics. We will not be simply passing through all keyboard information because this breaks localisation support. We may be able to help with specific requests. ~chris

Marked as rejected due to lack of updates. ~chris

train_cabin_brake_release, train_cabin_brake_lap, train_cabin_indbrake_toggle, train_cabin_dyn_toggle, etc. combinations are not passed through UserPressKey. I request to pass all strings defined in keyboard.txt file through cabin script. Also, it would be nice to have messages about pressed keys with minor string like UserPressKey parameter. ~Mike

We have added KIND Controlset for this purpose. ~chris

• genesteal : methods applied to current train, may be class world.gs:

- Train.GetNextSignal() : return next Signal same direction, distance and signal state. - Train.GetNextExSignal() : the same for extended states - Train.GetNextTrackside () : return next trackside same direction, distance, speedlimit if exists. - Train.GetNextJunction () : return next junction, distance and direction.

This kind of thing can be implemented using GSTrackSearch. ~chris

• Ability for an asset to be able to change and save it's local soup (ie stringtable) ~Jenolan

Script is intended for gameplay control, not content creation. Assets are deliberately immutable. ~chris

• Turntables: Write access to the "angle" tag array in script. Now that TrackSearch will allow me to find out what is attached to a Turntable it would be nice to extend my turntable kit to disallow non existent connections. ~Andi

Assets are deliberately immutable. The idea of disabling some stopping angles is a good one, but this is not the right approach. ~chris

• Minimap Support, don't care personally but some will. -Andi

Not sure what this refers to. ~chris

• At the moment we are using F8 as out deadman switch. Would like two key bindings 'User1' 'User2' that sends a message the same style as F8 does (with User1 & User2 as the minor) so that we can do the deadman and a hud control. ~Jenolan

KIND Controlset is intended for this. ~chris

• Need to be able to detect if the user has turn off logging ie -nolog as people forget that they have done it and we log diagnostics if there is a problem. ~Jenolan

Script is intended for gameplay control, not game configuration. ~chris