NimbyScript - Revision history

Admin at 18:05, 12 February 2026

2026-02-12T18:05:28Z

← Older revision		Revision as of 18:05, 12 February 2026
Line 310:		Line 310:
	EqOp <- '==' / '!='		EqOp <- '==' / '!='
	RelExp <- AddExp (CmpOp AddExp)?		RelExp <- AddExp (CmpOp AddExp)?
	CmpOp <- '<' / '>' / '>=' / '<='		CmpOp <- '<=' / '>=' / '<' / '>'
	AddExp <- MulExp (AddOp MulExp)*		AddExp <- MulExp (AddOp MulExp)*
	AddOp <- '+' / '-'		AddOp <- '+' / '-'
	MulExp <- ~~DotExp~~ (MulOp ~~DotExp~~)*		MulExp <- UnaryExp (MulOp UnaryExp)*
	MulOp <- '*' / '/' / '%'		MulOp <- '*' / '/' / '%'
	DotExp <- AtomExp ('.' ~~NAME~~)* MethodArgsExp?		UnaryExp <- UnaryOp? DotExp
			UnaryOp <- '!' / '-'
			DotExp <- AtomExp ('.' ColonFishNAME)* MethodArgsExp?
	MethodArgsExp <- '(' CallArgs? ')'		MethodArgsExp <- '(' CallArgs? ')'
	CallExp <- ~~ColonNAME~~ '(' CallArgs? ')'		CallExp <- ColonFishNAME '(' CallArgs? ')'
	CallArgs <- Exp (',' Exp)*		CallArgs <- Exp (',' Exp)*
	~~UnaryExp <- UnaryOp Exp~~		AtomExp <- AtomPar / CallExp / Constant / ColonNAME
	~~UnaryOp <- '!' / '-'~~
	AtomExp <- AtomPar / CallExp / Constant ~~/ UnaryExp~~ / ColonNAME
	AtomPar <- '(' Exp ')'</pre>		AtomPar <- '(' Exp ')'</pre>
	Expression support is similar to classic C, with some quirks around operator precedence. You might need to use parentheses more often than in other languages to ensure the semantics of your expression, but in practice it does not happen often.		Expression support is similar to classic C, with some quirks around operator precedence. You might need to use parentheses more often than in other languages to ensure the semantics of your expression, but in practice it does not happen often.

Admin at 17:23, 7 February 2026

2026-02-07T17:23:07Z

← Older revision		Revision as of 17:23, 7 February 2026
Line 534:		Line 534:
	<code>event_signal_texture_state</code> script functions must be defined as a method of a <code>struct</code> which <code>extend</code>s the game object <code>Signal</code>. They must have the exact same parameters and return type as in the previous example.		<code>event_signal_texture_state</code> script functions must be defined as a method of a <code>struct</code> which <code>extend</code>s the game object <code>Signal</code>. They must have the exact same parameters and return type as in the previous example.

	<code>event_signal_texture_state</code> requires the player to enable their respective <code>struct</code> as an extension for a given signal in the track editor. From that moment, when the game UI needs to query what is the current signal texture state index, it will call your <code>event_signal_texture_state</code>, with some potential caching to keep the call rate lower. In any case the call rate of this function is potentially very large when the user zooms out the map, so make sure to keep its code as efficient as possible. For this same reason it is given very little access to the APIs. <code>clock_us</code> is the number of sim-microseconds since the current save was created, you can use it with the <code>zdiv</code> and <code>zmod</code> functions to make animations. For path signals, <code>core_state</code> ~~returns~~ the current result of the signal check (including scripts), and it is valued 0 for Pass and 1 for Stop; for all other signals it is always 0.		<code>event_signal_texture_state</code> requires the player to enable their respective <code>struct</code> as an extension for a given signal in the track editor. From that moment, when the game UI needs to query what is the current signal texture state index, it will call your <code>event_signal_texture_state</code>, with some potential caching to keep the call rate lower. In any case the call rate of this function is potentially very large when the user zooms out the map, so make sure to keep its code as efficient as possible. For this same reason it is given very little access to the APIs. <code>clock_us</code> is the number of sim-microseconds since the current save was created, you can use it with the <code>zdiv</code> and <code>zmod</code> functions to make animations. For path signals, <code>core_state</code> is the current result of the signal check (including scripts), and it is valued 0 for Pass and 1 for Stop; for all other signals it is always 0.

	The return value indicates which signal texture state is to be used. If it’s -1 or lower, the default algorithm will be used to select the texture index. If it’s 0 or larger, it will select the texture in the same order as the <code>state</code> lines in the <code>SignalTextures</code>. Larger values than the number of states will be clamped to the last state.		The return value indicates which signal texture state is to be used. If it’s -1 or lower, the default algorithm will be used to select the texture index. If it’s 0 or larger, it will select the texture in the same order as the <code>state</code> lines in the <code>SignalTextures</code>. Larger values than the number of states will be clamped to the last state.

Admin at 17:22, 7 February 2026

2026-02-07T17:22:00Z

← Older revision		Revision as of 17:22, 7 February 2026
Line 529:		Line 529:
	db: &DB,		db: &DB,
	signal: &Signal,		signal: &Signal,
	clock_us: i64		clock_us: i64,
			core_state: i64
	): i64 { ... }</pre>		): i64 { ... }</pre>
	<code>event_signal_texture_state</code> script functions must be defined as a method of a <code>struct</code> which <code>extend</code>s the game object <code>Signal</code>. They must have the exact same parameters and return type as in the previous example.		<code>event_signal_texture_state</code> script functions must be defined as a method of a <code>struct</code> which <code>extend</code>s the game object <code>Signal</code>. They must have the exact same parameters and return type as in the previous example.

	<code>event_signal_texture_state</code> requires the player to enable their respective <code>struct</code> as an extension for a given signal in the track editor. From that moment, when the game UI needs to query what is the current signal texture state index, it will call your <code>event_signal_texture_state</code>, with some potential caching to keep the call rate lower. In any case the call rate of this function is potentially very large when the user zooms out the map, so make sure to keep its code as efficient as possible. For this same reason it is given very little access to the APIs. <code>clock_us</code> is the number of sim-microseconds since the current save was created, you use it with the <code>zdiv</code> and <code>zmod</code> functions to make animations.		<code>event_signal_texture_state</code> requires the player to enable their respective <code>struct</code> as an extension for a given signal in the track editor. From that moment, when the game UI needs to query what is the current signal texture state index, it will call your <code>event_signal_texture_state</code>, with some potential caching to keep the call rate lower. In any case the call rate of this function is potentially very large when the user zooms out the map, so make sure to keep its code as efficient as possible. For this same reason it is given very little access to the APIs. <code>clock_us</code> is the number of sim-microseconds since the current save was created, you can use it with the <code>zdiv</code> and <code>zmod</code> functions to make animations. For path signals, <code>core_state</code> returns the current result of the signal check (including scripts), and it is valued 0 for Pass and 1 for Stop; for all other signals it is always 0.

	The return value indicates which signal texture state is to be used. If it’s -1 or lower, the default algorithm will be used to select the texture index. If it’s 0 or larger, it will select the texture in the same order as the <code>state</code> lines in the <code>SignalTextures</code>. Larger values than the number of states will be clamped to the last state.		The return value indicates which signal texture state is to be used. If it’s -1 or lower, the default algorithm will be used to select the texture index. If it’s 0 or larger, it will select the texture in the same order as the <code>state</code> lines in the <code>SignalTextures</code>. Larger values than the number of states will be clamped to the last state.

Admin at 18:05, 6 February 2026

2026-02-06T18:05:43Z

← Older revision		Revision as of 18:05, 6 February 2026
Line 1,003:		Line 1,003:
	=== Type Line::Stop ===		=== Type Line::Stop ===

	<pre>struct Line::Stop {}</pre>		<pre>struct Line::Stop {
			station_id: ID<Station>,
			}</pre>
	<span id="type-motion"></span>		<span id="type-motion"></span>
	=== Type Motion ===		=== Type Motion ===
Line 1,016:		Line 1,018:
	timed_stop: std::optional<Motion::TimedStop>,		timed_stop: std::optional<Motion::TimedStop>,
	schedule_stop: std::optional<Motion::ScheduleStop>,		schedule_stop: std::optional<Motion::ScheduleStop>,
	station_stop: std::optional<Motion::~~ScheduleStationEvent~~>,		station_stop: std::optional<Motion::StationStop>,
	run_stop: std::optional<Motion::RunStop>,		run_stop: std::optional<Motion::RunStop>,
	schedule_dispatch: std::optional<Motion::ScheduleDispatch>,		schedule_dispatch: std::optional<Motion::ScheduleDispatch>,
Line 1,065:		Line 1,067:

	<pre>struct Motion::RunDispatch {		<pre>struct Motion::RunDispatch {
	~~line_id: ID<Line>,~~
	~~station_id: ID<Station>,~~
	run: Run,		run: Run,
	run_epoch_start: i64,		run_epoch_start: i64,
Line 1,073:		Line 1,073:

	<pre>fn Motion::RunDispatch::current_stop(self: &Motion::RunDispatch, line: &Line): *Line::Stop</pre>		<pre>fn Motion::RunDispatch::current_stop(self: &Motion::RunDispatch, line: &Line): *Line::Stop</pre>
			<span id="type-motionrunstop"></span>
			=== Type Motion::RunStop ===

			<pre>struct Motion::RunStop {
			line_id: ID<Line>,
			station_id: ID<Station>,
			}</pre>
			Simulation state of a train performing a stop due to its line run.

	<span id="type-motionscheduledispatch"></span>		<span id="type-motionscheduledispatch"></span>
	=== Type Motion::ScheduleDispatch ===		=== Type Motion::ScheduleDispatch ===
Line 1,299:		Line 1,308:

	<pre>struct std::optional<Motion::RunStop> {}</pre>		<pre>struct std::optional<Motion::RunStop> {}</pre>
	<pre>fn std::optional<Motion::RunStop>::get(self: &std::optional<Motion::RunStop>): *Motion::~~RunDispatch~~</pre>		<pre>fn std::optional<Motion::RunStop>::get(self: &std::optional<Motion::RunStop>): *Motion::RunStop</pre>
	<span id="type-stdoptional-5"></span>		<span id="type-stdoptional-5"></span>
	=== Type std::optional<Motion::ScheduleDispatch> ===		=== Type std::optional<Motion::ScheduleDispatch> ===
Line 1,308:		Line 1,317:
	): *Motion::ScheduleDispatch</pre>		): *Motion::ScheduleDispatch</pre>
	<span id="type-stdoptional-6"></span>		<span id="type-stdoptional-6"></span>
	~~=== Type std::optional<Motion::ScheduleStationEvent> ===~~

	~~<pre>struct std::optional<Motion::ScheduleStationEvent> {}</pre>~~
	~~<span id="type-stdoptional-7"></span>~~
	=== Type std::optional<Motion::ScheduleStop> ===		=== Type std::optional<Motion::ScheduleStop> ===

Line 1,318:		Line 1,323:
	self: &std::optional<Motion::ScheduleStop>		self: &std::optional<Motion::ScheduleStop>
	): *Motion::ScheduleStop</pre>		): *Motion::ScheduleStop</pre>
			<span id="type-stdoptional-7"></span>
			=== Type std::optional<Motion::StationStop> ===

			<pre>struct std::optional<Motion::StationStop> {}</pre>
			<pre>fn std::optional<Motion::StationStop>::get(
			self: &std::optional<Motion::StationStop>
			): *Motion::StationStop</pre>
	<span id="type-stdoptional-8"></span>		<span id="type-stdoptional-8"></span>
	=== Type std::optional<Motion::TimedStop> ===		=== Type std::optional<Motion::TimedStop> ===
Line 1,323:		Line 1,335:
	<pre>struct std::optional<Motion::TimedStop> {}</pre>		<pre>struct std::optional<Motion::TimedStop> {}</pre>
	<pre>fn std::optional<Motion::TimedStop>::get(self: &std::optional<Motion::TimedStop>): *Motion::TimedStop</pre>		<pre>fn std::optional<Motion::TimedStop>::get(self: &std::optional<Motion::TimedStop>): *Motion::TimedStop</pre>
	~~<span id="top-level-2"></span>~~
	~~=== Top level ===~~

	~~<pre>fn std::optional<Motion::StationStop>::get(~~
	~~self: &std::optional<Motion::ScheduleStationEvent>~~
	~~): *Motion::StationStop</pre>~~
	<span id="type-id"></span>		<span id="type-id"></span>
	=== Type ID<Building> ===		=== Type ID<Building> ===
Line 1,454:		Line 1,460:
	self: &mut Vec<Motion::CachedHitcher>::Iterator		self: &mut Vec<Motion::CachedHitcher>::Iterator
	): *Motion::CachedHitcher</pre>		): *Motion::CachedHitcher</pre>
	<span id="top-level-3"></span>		<span id="top-level-2"></span>
	=== Top level ===		=== Top level ===

Admin at 18:00, 6 February 2026

2026-02-06T18:00:35Z

Admin at 10:48, 2 February 2026

2026-02-02T10:48:30Z

← Older revision		Revision as of 10:48, 2 February 2026
Line 1,035:		Line 1,035:
	waiting_signal_id: ID<Signal>,		waiting_signal_id: ID<Signal>,
	waiting_signal_last_check: i64,		waiting_signal_last_check: i64,
			arrival_us: i64,
	path: Path,		path: Path,
	goal_trace: TapeTrace,		goal_trace: TapeTrace,
Line 1,511:		Line 1,512:
	<pre>fn Extrapolator::reservation_probe(self: &Extrapolator, pos: &Pos): mut ScResvProbeIt</pre>		<pre>fn Extrapolator::reservation_probe(self: &Extrapolator, pos: &Pos): mut ScResvProbeIt</pre>
	Probe a track position for train reservations and occupations.		Probe a track position for train reservations and occupations.

			<pre>fn Extrapolator::view_last<Motion>(self: &Extrapolator, train_id: ID<Train>): *Motion</pre>
			Return the last frame Motion object associated to the train ID.

	<pre>fn Extrapolator::week_monday0000_epoch_s(self: &Extrapolator): mut i64</pre>		<pre>fn Extrapolator::week_monday0000_epoch_s(self: &Extrapolator): mut i64</pre>

Admin at 12:45, 30 January 2026

2026-01-30T12:45:02Z

← Older revision		Revision as of 12:45, 30 January 2026
Line 1,251:		Line 1,251:
	id: ID<Train>,		id: ID<Train>,
	tags: Tags,		tags: Tags,
			as_purchased: Train::Dynamics,
	}</pre>		}</pre>
	<span id="type-traindynamics"></span>		<span id="type-traindynamics"></span>

Admin at 16:56, 25 January 2026

2026-01-25T16:56:01Z

← Older revision		Revision as of 16:56, 25 January 2026
Line 1,242:		Line 1,242:
	station_id: ID<Station>,		station_id: ID<Station>,
	}</pre>		}</pre>
			<pre>fn Track::max_speed(self: &Track): f64</pre>
			Returns the min(physical, manual setting) max speed of the track, in m/s.

	<span id="type-train"></span>		<span id="type-train"></span>
	=== Type Train ===		=== Type Train ===

Admin at 18:43, 18 January 2026

2026-01-18T18:43:49Z

← Older revision		Revision as of 18:43, 18 January 2026
Line 404:		Line 404:
	train: &Train,		train: &Train,
	motion: &Motion,		motion: &Motion,
	signal: &Signal		signal: &Signal,
			sc: &mut SimpleSimController
	): SignalCheck { ... }</pre>		): SignalCheck { ... }</pre>
	<code>event_signal_check</code> script functions must be defined as a method of a <code>struct</code> which <code>extend</code>s the game object <code>Signal</code>. They must have the exact same parameters and return type as in the previous example.		<code>event_signal_check</code> script functions must be defined as a method of a <code>struct</code> which <code>extend</code>s the game object <code>Signal</code>. They must have the exact same parameters and return type as in the previous example.
Line 424:		Line 425:
	train_distance: f64,		train_distance: f64,
	check: SignalCheck,		check: SignalCheck,
			sc: &mut SimpleSimController,
	result: &mut SignalLookaheadResult		result: &mut SignalLookaheadResult
	) { ... }</pre>		) { ... }</pre>
	<code>event_signal_lookahead</code> script functions must be defined as a method of a <code>struct</code> which <code>extend</code>s the game object <code>Signal</code>. They must have the exact same parameters and return type as in the previous example.		<code>event_signal_lookahead</code> script functions must be defined as a method of a <code>struct</code> which <code>extend</code>s the game object <code>Signal</code>. They must have the exact same parameters and return type as in the previous example.

	<code>event_signal_lookahead</code> requires the player to enable their respective <code>struct</code> as an extension for a given signal in the track editor. From that moment the game simulation system which advances the train motion simulation (the <code>Extrapolator</code>) will call your <code>event_signal_lookahead</code> function at regular intervals for each signal 15km ahead of the train path. It is called for all signals, until one of these conditions hold: - One of the signals path checks as <code>Stop</code> - Another train is found - The train stop is found - 15km have been checked		<code>event_signal_lookahead</code> requires the player to enable their respective <code>struct</code> as an extension for a given signal in the track editor. From that moment the game simulation system which advances the train motion simulation (the <code>Extrapolator</code>) will call your <code>event_signal_lookahead</code> function at regular intervals for each signal 15km ahead of the train path. It is called for all signals, until one of these conditions hold:

			* One of the signals path checks as <code>Stop</code>
			* Another train is found
			* The train stop is found
			* 15km have been checked

	For both <code>Pass</code> and <code>Stop</code> signals, your <code>event_signal_lookahead</code> will be called, and you can check the path find result in <code>check</code>, and the distance from the train in <code>train_distance</code>.		For both <code>Pass</code> and <code>Stop</code> signals, your <code>event_signal_lookahead</code> will be called, and you can check the path find result in <code>check</code>, and the distance from the train in <code>train_distance</code>.
Line 447:		Line 454:
	signal: &Signal,		signal: &Signal,
	check: SignalCheck,		check: SignalCheck,
			sc: &mut SimpleSimController,
	result: &mut SignalChangePathResult		result: &mut SignalChangePathResult
	): SignalChangePath { ... }</pre>		): SignalChangePath { ... }</pre>
Line 695:		Line 703:

	Commands queued from events and <code>control_train</code> are executed asynchronously, there is no guaranteed order of execution! You must prepare your code and data for this design. For stand alone tasks scripts commands are executed in order and in isolation. You can queue up tasks from event and control scripts when you need to guarantee data consistency beyond “pick a random winner”.		Commands queued from events and <code>control_train</code> are executed asynchronously, there is no guaranteed order of execution! You must prepare your code and data for this design. For stand alone tasks scripts commands are executed in order and in isolation. You can queue up tasks from event and control scripts when you need to guarantee data consistency beyond “pick a random winner”.

			<code>SimpleSimController</code> is a cut down version of <code>SimController</code> for high frequency events like <code>event_signal_lookahead</code>. The reference in the second part of this document lists which <code>SimController</code> functions are available in <code>SimpleSimController</code>, and they work identically.

	<span id="simcontrollerqueue_train_intervention"></span>		<span id="simcontrollerqueue_train_intervention"></span>
Line 1,669:		Line 1,679:
	train: &Train,		train: &Train,
	pos: &Pos		pos: &Pos
			): void</pre>
			<span id="type-simplesimcontroller"></span>
			=== Type SimpleSimController ===

			<pre>struct SimpleSimController {}</pre>
			A limited API version of SimController.

			<pre>fn SimpleSimController::queue_attach(
			self: &mut SimpleSimController,
			model_obj: <Generic>,
			struct_obj: <Generic>
			): void</pre>
			<pre>fn SimpleSimController::queue_erase(
			self: &mut SimpleSimController,
			struct_obj: <Generic>
	): void</pre>		): void</pre>
	<span id="type-taskeventtrain"></span>		<span id="type-taskeventtrain"></span>

Admin at 20:27, 15 January 2026

2026-01-15T20:27:02Z

← Older revision		Revision as of 20:27, 15 January 2026
Line 519:		Line 519:
	self: &Example,		self: &Example,
	db: &DB,		db: &DB,
	signal: &Signal		signal: &Signal,
			clock_us: i64
	): i64 { ... }</pre>		): i64 { ... }</pre>
	<code>event_signal_texture_state</code> script functions must be defined as a method of a <code>struct</code> which <code>extend</code>s the game object <code>Signal</code>. They must have the exact same parameters and return type as in the previous example.		<code>event_signal_texture_state</code> script functions must be defined as a method of a <code>struct</code> which <code>extend</code>s the game object <code>Signal</code>. They must have the exact same parameters and return type as in the previous example.

	<code>event_signal_texture_state</code> requires the player to enable their respective <code>struct</code> as an extension for a given signal in the track editor. From that moment, when the game UI needs to query what is the current signal texture state index, it will call your <code>event_signal_texture_state</code>, with some potential caching to keep the call rate lower. In any case the call rate of this function is potentially very large when the user zooms out the map, so make sure to keep its code as efficient as possible. For this same reason it is given very little access to the APIs.		<code>event_signal_texture_state</code> requires the player to enable their respective <code>struct</code> as an extension for a given signal in the track editor. From that moment, when the game UI needs to query what is the current signal texture state index, it will call your <code>event_signal_texture_state</code>, with some potential caching to keep the call rate lower. In any case the call rate of this function is potentially very large when the user zooms out the map, so make sure to keep its code as efficient as possible. For this same reason it is given very little access to the APIs. <code>clock_us</code> is the number of sim-microseconds since the current save was created, you use it with the <code>zdiv</code> and <code>zmod</code> functions to make animations.

	The return value indicates which signal texture state is to be used. If it’s -1 or lower, the default algorithm will be used to select the texture index. If it’s 0 or larger, it will select the texture in the same order as the <code>state</code> lines in the <code>SignalTextures</code>. Larger values than the number of states will be clamped to the last state.		The return value indicates which signal texture state is to be used. If it’s -1 or lower, the default algorithm will be used to select the texture index. If it’s 0 or larger, it will select the texture in the same order as the <code>state</code> lines in the <code>SignalTextures</code>. Larger values than the number of states will be clamped to the last state.

← Older revision		Revision as of 18:00, 6 February 2026
Line 169:		Line 169:
	},		},
	}</pre>		}</pre>
	* The <code>label</code> meta field is accepted for all field types.		* The <code>label</code> meta field is accepted for all field types. It will be displayed as the input widget label.
			* The <code>description</code> meta field is accepted for all field types. It will be displayed as the input widget tooltip.
	* The <code>default</code> meta field is accepted for <code>bool</code>, <code>i64</code>, <code>f64</code> and <code>enum</code> field types.		* The <code>default</code> meta field is accepted for <code>bool</code>, <code>i64</code>, <code>f64</code> and <code>enum</code> field types.
	* The <code>min</code> and <code>max</code> meta field is accepted for <code>i64</code> and <code>f64</code> field types.		* The <code>min</code> and <code>max</code> meta field is accepted for <code>i64</code> and <code>f64</code> field types.
Line 439:		Line 440:
	For both <code>Pass</code> and <code>Stop</code> signals, your <code>event_signal_lookahead</code> will be called, and you can check the path find result in <code>check</code>, and the distance from the train in <code>train_distance</code>.		For both <code>Pass</code> and <code>Stop</code> signals, your <code>event_signal_lookahead</code> will be called, and you can check the path find result in <code>check</code>, and the distance from the train in <code>train_distance</code>.

	<code>result.max_speed</code> allows to set a maximum speed for the train, which goes into effect immediately. This works from any distance and past any amount of signals between the train and the caller signal. If multiple signals in the lookahead path return a <code>max_speed</code>, the slowest speed is picked. If no <code>max_speed</code> is set, or it is 0, the result is ignored.		<code>result.max_speed</code> allows to set a maximum speed for the train, which goes into effect immediately. It must be expressed as m/s. This works from any distance and past any amount of signals between the train and the caller signal. If multiple signals in the lookahead path return a <code>max_speed</code>, the slowest speed is picked. If no <code>max_speed</code> is set, or it is 0, the result is ignored.

	<code>result.max_speed</code> default value is 0, which is considered invalid and will be ignored. To stop the train at the signal implement <code>event_signal_check</code>.		<code>result.max_speed</code> default value is 0, which is considered invalid and will be ignored. To stop the train at the signal implement <code>event_signal_check</code>.
Line 551:		Line 552:
	<code>event_train_shift_setup</code> requires the player to enable their respective <code>struct</code> as an extension for a given train in the train editor. From that moment, when an unassigned train decides to lookup a new shift to run, it will first call <code>event_train_shift_setup</code>.		<code>event_train_shift_setup</code> requires the player to enable their respective <code>struct</code> as an extension for a given train in the train editor. From that moment, when an unassigned train decides to lookup a new shift to run, it will first call <code>event_train_shift_setup</code>.

	The parameter <code>ss</code> is both an input and output parameter. It is initialized with the current, relevant data for the given train state, and <code>event_train_shift_setup</code> can then change it, to influence which shifts will be considered by the shift selection algorithm. It can change the train position used for matching, the time used for matching, and disable the check for reservations. For matched shifts which do not correspond to the current train position, the Extrapolator system will automatically pathfind a temporary milestone for the train, like other path-changing features.		The parameter <code>ss</code> is both an input and output parameter. It is initialized with the current, relevant data for the given train state, and <code>event_train_shift_setup</code> can then change it, to influence which shifts will be considered by the shift selection algorithm. It can change the train position used for matching, the time used for matching, and disable the check for reservations. For matched shifts which do not correspond to the current train position, the Extrapolator system will automatically pathfind a temporary milestone for the train, like other path-changing features. <code>ShiftSetup::epoch_s</code> allowed range is between minus one week and plus one week from the current simulation time, with values outside this range being clamped into it.

	<span id="train-event_train_shift_allow"></span>		<span id="train-event_train_shift_allow"></span>