Spring - User contributions [en]

Spring MT

2013-09-01T16:49:01Z

Zerver: Add deprecation info

{{deprecated}}

'''Deprecated! Spring MT has been renamed to RTSMP and is no longer part of the Spring project.'''

== Spring MT ==
The Spring MT 94.11 release is
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the other Spring releases. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers will send you a chat message with instructions.

=== What is the downside? ===
The simulation may work slightly differently, possibly producing some negative effects. There is an increased risk of threading bugs that may cause a desync. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''SpringMT9411''' for streamlined access to MT autohosts.

'''Windows complete''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe 94.11 MT + 94.11 installer] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z 94.11 MT + 94.11 portable] 

'''Executables only''' 
Unzip both executables in the install folder of the official release.

:Windows [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z 94.11]. 
:
:Linux32 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/linux32/spring_94.1_minimal-portable-linux32-static.7z portable] installation 
:
:Linux64 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/linux64/spring_94.1_minimal-portable-linux64-static.7z portable] installation 
:
:OSX64 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-mt.zip 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/osx64/%7bMTsim3%7d94.1-16-ge49de6c_MacOSX-10.6-SnowLeopard_spring.zip 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/osx64/spring_94.1_MacOSX-10.6-SnowLeopard.zip portable] installation 

'''Source code''' 
:
:[https://github.com/zerver/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github 94.11 MT] 
:
:[https://github.com/zerver/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github 94.11] 

=== How do I install it on my autohost? ===

'''Dedicated server''' 

:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-dedicated.zip OSX64] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "Please note this server REQUIRES Spring MT 94.11. ".
"Installation instructions: http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-28T21:41:22Z

Zerver: /* How do I install it? */

== Spring MT ==
The Spring MT 94.11 release is
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the other Spring releases. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers will send you a chat message with instructions.

=== What is the downside? ===
The simulation may work slightly differently, possibly producing some negative effects. There is an increased risk of threading bugs that may cause a desync. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''SpringMT9411''' for streamlined access to MT autohosts.

'''Windows complete''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe 94.11 MT + 94.11 installer] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z 94.11 MT + 94.11 portable] 

'''Executables only''' 
Unzip both executables in the install folder of the official release.

:Windows [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z 94.11]. 
:
:Linux32 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/linux32/spring_94.1_minimal-portable-linux32-static.7z portable] installation 
:
:Linux64 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/linux64/spring_94.1_minimal-portable-linux64-static.7z portable] installation 
:
:OSX64 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-mt.zip 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/osx64/%7bMTsim3%7d94.1-16-ge49de6c_MacOSX-10.6-SnowLeopard_spring.zip 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/osx64/spring_94.1_MacOSX-10.6-SnowLeopard.zip portable] installation 

'''Source code''' 
:
:[https://github.com/zerver/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github 94.11 MT] 
:
:[https://github.com/zerver/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github 94.11] 

=== How do I install it on my autohost? ===

'''Dedicated server''' 

:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-dedicated.zip OSX64] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "Please note this server REQUIRES Spring MT 94.11. ".
"Installation instructions: http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-28T21:40:01Z

Zerver: /* On which servers can I play Spring MT? */

== Spring MT ==
The Spring MT 94.11 release is
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the other Spring releases. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers will send you a chat message with instructions.

=== What is the downside? ===
The simulation may work slightly differently, possibly producing some negative effects. There is an increased risk of threading bugs that may cause a desync. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''SpringMT9411''' to get access to MT autohosts.

'''Windows complete''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe 94.11 MT + 94.11 installer] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z 94.11 MT + 94.11 portable] 

'''Executables only''' 
Unzip both executables in the install folder of the official release.

:Windows [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z 94.11]. 
:
:Linux32 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/linux32/spring_94.1_minimal-portable-linux32-static.7z portable] installation 
:
:Linux64 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/linux64/spring_94.1_minimal-portable-linux64-static.7z portable] installation 
:
:OSX64 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-mt.zip 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/osx64/%7bMTsim3%7d94.1-16-ge49de6c_MacOSX-10.6-SnowLeopard_spring.zip 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/osx64/spring_94.1_MacOSX-10.6-SnowLeopard.zip portable] installation 

'''Source code''' 
:
:[https://github.com/zerver/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github 94.11 MT] 
:
:[https://github.com/zerver/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github 94.11] 

=== How do I install it on my autohost? ===

'''Dedicated server''' 

:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-dedicated.zip OSX64] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "Please note this server REQUIRES Spring MT 94.11. ".
"Installation instructions: http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-28T21:38:36Z

Zerver: /* How do I install it on my autohost? */

== Spring MT ==
The Spring MT 94.11 release is
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the other Spring releases. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, possibly producing some negative effects. There is an increased risk of threading bugs that may cause a desync. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''SpringMT9411''' to get access to MT autohosts.

'''Windows complete''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe 94.11 MT + 94.11 installer] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z 94.11 MT + 94.11 portable] 

'''Executables only''' 
Unzip both executables in the install folder of the official release.

:Windows [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z 94.11]. 
:
:Linux32 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/linux32/spring_94.1_minimal-portable-linux32-static.7z portable] installation 
:
:Linux64 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/linux64/spring_94.1_minimal-portable-linux64-static.7z portable] installation 
:
:OSX64 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-mt.zip 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/osx64/%7bMTsim3%7d94.1-16-ge49de6c_MacOSX-10.6-SnowLeopard_spring.zip 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/osx64/spring_94.1_MacOSX-10.6-SnowLeopard.zip portable] installation 

'''Source code''' 
:
:[https://github.com/zerver/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github 94.11 MT] 
:
:[https://github.com/zerver/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github 94.11] 

=== How do I install it on my autohost? ===

'''Dedicated server''' 

:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-dedicated.zip OSX64] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "Please note this server REQUIRES Spring MT 94.11. ".
"Installation instructions: http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-22T20:58:30Z

Zerver: /* What is Spring MT? */

== Spring MT ==
The Spring MT 94.11 release is
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the other Spring releases. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, possibly producing some negative effects. There is an increased risk of threading bugs that may cause a desync. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''SpringMT9411''' to get access to MT autohosts.

'''Windows complete''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe 94.11 MT + 94.11 installer] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z 94.11 MT + 94.11 portable] 

'''Executables only''' 
Unzip both executables in the install folder of the official release.

:Windows [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z 94.11]. 
:
:Linux32 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/linux32/spring_94.1_minimal-portable-linux32-static.7z portable] installation 
:
:Linux64 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/linux64/spring_94.1_minimal-portable-linux64-static.7z portable] installation 
:
:OSX64 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-mt.zip 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/osx64/%7bMTsim3%7d94.1-16-ge49de6c_MacOSX-10.6-SnowLeopard_spring.zip 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/osx64/spring_94.1_MacOSX-10.6-SnowLeopard.zip portable] installation 

'''Source code''' 
:
:[https://github.com/zerver/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github 94.11 MT] 
:
:[https://github.com/zerver/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github 94.11] 

=== How do I install it on my autohost? ===

'''Dedicated server''' 

:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-dedicated.zip OSX64] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.11. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-22T20:57:03Z

Zerver: /* How do I install it? */

== Spring MT ==
The Spring MT 94.11 release is
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT is an independent engine that uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, possibly producing some negative effects. There is an increased risk of threading bugs that may cause a desync. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''SpringMT9411''' to get access to MT autohosts.

'''Windows complete''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe 94.11 MT + 94.11 installer] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z 94.11 MT + 94.11 portable] 

'''Executables only''' 
Unzip both executables in the install folder of the official release.

:Windows [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z 94.11]. 
:
:Linux32 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/linux32/spring_94.1_minimal-portable-linux32-static.7z portable] installation 
:
:Linux64 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/linux64/spring_94.1_minimal-portable-linux64-static.7z portable] installation 
:
:OSX64 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-mt.zip 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/osx64/%7bMTsim3%7d94.1-16-ge49de6c_MacOSX-10.6-SnowLeopard_spring.zip 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/osx64/spring_94.1_MacOSX-10.6-SnowLeopard.zip portable] installation 

'''Source code''' 
:
:[https://github.com/zerver/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github 94.11 MT] 
:
:[https://github.com/zerver/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github 94.11] 

=== How do I install it on my autohost? ===

'''Dedicated server''' 

:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-dedicated.zip OSX64] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.11. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-22T17:33:22Z

Zerver: /* How do I install it? */ shuffle links

== Spring MT ==
The Spring MT 94.11 release is
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT is an independent engine that uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, possibly producing some negative effects. There is an increased risk of threading bugs that may cause a desync. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''SpringMT9411''' to get access to MT autohosts.

'''Windows complete''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe 94.11 MT + 94.11 installer] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z 94.11 MT + 94.11 portable] 

'''Executables only''' 
Unzip both executables the install folder of the official release.

:Windows [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z 94.11]. 
:
:Linux32 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/linux32/spring_94.1_minimal-portable-linux32-static.7z portable] installation 
:
:Linux64 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/linux64/spring_94.1_minimal-portable-linux64-static.7z portable] installation 
:
:OSX64 [http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-mt.zip 94.11 MT], [http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/osx64/%7bMTsim3%7d94.1-16-ge49de6c_MacOSX-10.6-SnowLeopard_spring.zip 94.11]. Requires a [http://springrts.com/dl/buildbot/default/master/94.1/osx64/spring_94.1_MacOSX-10.6-SnowLeopard.zip portable] installation 

'''Source code''' 
:
:[https://github.com/zerver/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github 94.11 MT] 
:
:[https://github.com/zerver/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github 94.11] 

=== How do I install it on my autohost? ===

'''Dedicated server''' 

:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-dedicated.zip OSX64] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.11. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-22T10:25:57Z

Zerver: /* Spring MT */

== Spring MT ==
The Spring MT 94.11 release is
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT is an independent engine that uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, possibly producing some negative effects. There is an increased risk of threading bugs that may cause a desync. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''SpringMT9411''' to get access to MT autohosts.

'''Complete 94.11 MT + 94.11''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe Windows installer] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z Windows portable] 

'''Executables only''' 
Unzip to the install folder of the official release. Linux and OSX may require a portable installation. 

:'''94.11 MT (ASIM APATH GML)''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-mt.zip OSX64] 

:'''94.11 (ASIM GML OMP)''' 
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/osx64/%7bMTsim3%7d94.1-16-ge49de6c_MacOSX-10.6-SnowLeopard_spring.zip OSX64] 

'''Source code''' 
:
:[https://github.com/zerver/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github 94.11 MT] 
:
:[https://github.com/zerver/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github 94.11] 

=== How do I install it on my autohost? ===

'''Dedicated server''' 

:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-dedicated.zip OSX64] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.11. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-21T15:44:54Z

Zerver: /* Why is this unofficial? */

== Spring MT ==
Unofficial 94.11 release,
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT is an independent engine that uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== Why is this unofficial? ===
The code base is somewhat complex, making it hard to maintain for developers who have only rudimentary multithreading skills.

=== What is the downside? ===
The simulation may work slightly differently, possibly producing some negative effects. There is an increased risk of threading bugs that may cause a desync. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''SpringMT9411''' to get access to MT autohosts.

'''Complete 94.11 MT + 94.11''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe Windows installer] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z Windows portable] 

'''Executables only''' 
Unzip to the install folder of the official release. Linux and OSX may require a portable installation. 

:'''94.11 MT (ASIM APATH GML)''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-mt.zip OSX64] 

:'''94.11 (ASIM GML OMP)''' 
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/osx64/%7bMTsim3%7d94.1-16-ge49de6c_MacOSX-10.6-SnowLeopard_spring.zip OSX64] 

'''Source code''' 
:
:[https://github.com/zerver/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github 94.11 MT] 
:
:[https://github.com/zerver/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github 94.11] 

=== How do I install it on my autohost? ===

'''Dedicated server''' 

:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-dedicated.zip OSX64] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.11. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-17T20:36:52Z

Zerver: /* How do I install it? */

== Spring MT ==
Unofficial 94.11 release,
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT is an independent engine that uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, producing some negative effects. This is also experimental stuff and may have crashbugs or desyncs. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''SpringMT9411''' to get access to MT autohosts.

'''Complete 94.11 MT + 94.11''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe Windows installer] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z Windows portable] 

'''Executables only''' 
Unzip to the install folder of the official release. Linux and OSX may require a portable installation. 

:'''94.11 MT (ASIM APATH GML)''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-mt.zip OSX64] 

:'''94.11 (ASIM GML OMP)''' 
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/osx64/%7bMTsim3%7d94.1-16-ge49de6c_MacOSX-10.6-SnowLeopard_spring.zip OSX64] 

'''Source code''' 
:
:[https://github.com/zerver/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github 94.11 MT] 
:
:[https://github.com/zerver/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github 94.11] 

=== How do I install it on my autohost? ===

'''Dedicated server''' 

:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-dedicated.zip OSX64] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.11. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-13T22:10:46Z

Zerver: /* How do I install it? */

== Spring MT ==
Unofficial 94.11 release,
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT is an independent engine that uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, producing some negative effects. This is also experimental stuff and may have crashbugs or desyncs. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''SpringMT9411''' to get access to MT autohosts.

'''Complete 94.11 MT + 94.11''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe Windows installer] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z Windows portable] 

'''Executables only''' 
Unzip to the install folder of the official release. Linux and OSX may require a portable installation. 

:'''94.11 MT (ASIM APATH GML)''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-mt.zip OSX64] 

:'''94.11 (ASIM GML OMP)''' 
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/osx64/%7bMTsim3%7d94.1-16-ge49de6c_MacOSX-10.6-SnowLeopard_spring.zip OSX64] 

'''Source code''' 
:
:[https://github.com/zerver/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github 94.11 MT] 
:
:[https://github.com/zerver/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github 94.11] 

=== How do I install it on my autohost? ===

'''Dedicated server''' 

:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-dedicated.zip OSX64] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.11. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-13T21:03:35Z

Zerver: /* How do I install it? */

== Spring MT ==
Unofficial 94.11 release,
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT is an independent engine that uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, producing some negative effects. This is also experimental stuff and may have crashbugs or desyncs. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''#SpringMT9411''' to get access to MT autohosts.

'''Complete 94.11 MT + 94.11''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe Windows installer] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z Windows portable] 

'''Executables only''' 
Unzip to the install folder of the official release. Linux and OSX may require a portable installation. 

:'''94.11 MT (ASIM APATH GML)''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-mt.zip OSX64] 

:'''94.11 (ASIM GML OMP)''' 
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/osx64/%7bMTsim3%7d94.1-16-ge49de6c_MacOSX-10.6-SnowLeopard_spring.zip OSX64] 

'''Source code''' 
:
:[https://github.com/zerver/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github 94.11 MT] 
:
:[https://github.com/zerver/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github 94.11] 

=== How do I install it on my autohost? ===

'''Dedicated server''' 

:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-dedicated.zip OSX64] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.11. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-08T16:28:20Z

Zerver: /* How do I install it on my autohost? */

== Spring MT ==
Unofficial 94.11 release,
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT is an independent engine that uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, producing some negative effects. This is also experimental stuff and may have crashbugs or desyncs. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''#SpringMT9411''' to get access to MT autohosts.

'''Complete 94.11 MT + 94.11''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe Windows installer] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z Windows portable] 

'''Executables only''' 
Unzip to the install folder of the official release. Linux and OSX may require a portable installation. 

:'''94.11 MT (ASIM APATH GML)''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-mt.zip OSX64] 

:'''94.11 (ASIM GML OMP)''' 
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/osx64/%7bMTsim3%7d94.1-16-ge49de6c_MacOSX-10.6-SnowLeopard_spring.zip OSX64] 

'''Source code''' 
:
:[https://github.com/spring/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github 94.11 MT] 
:
:[https://github.com/spring/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github 94.11] 

=== How do I install it on my autohost? ===

'''Dedicated server''' 

:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-dedicated.zip OSX64] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.11. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-08T16:27:54Z

Zerver: /* How do I install it? */

== Spring MT ==
Unofficial 94.11 release,
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT is an independent engine that uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, producing some negative effects. This is also experimental stuff and may have crashbugs or desyncs. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''#SpringMT9411''' to get access to MT autohosts.

'''Complete 94.11 MT + 94.11''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe Windows installer] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z Windows portable] 

'''Executables only''' 
Unzip to the install folder of the official release. Linux and OSX may require a portable installation. 

:'''94.11 MT (ASIM APATH GML)''' 
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-mt.zip OSX64] 

:'''94.11 (ASIM GML OMP)''' 
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z Windows] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z Linux32] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z Linux64] 
:
:[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/osx64/%7bMTsim3%7d94.1-16-ge49de6c_MacOSX-10.6-SnowLeopard_spring.zip OSX64] 

'''Source code''' 
:
:[https://github.com/spring/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github 94.11 MT] 
:
:[https://github.com/spring/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github 94.11] 

=== How do I install it on my autohost? ===

'''Dedicated server''' 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-dedicated.zip OSX64] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.11. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-08T01:15:35Z

Zerver: /* How do I install it? */

== Spring MT ==
Unofficial 94.11 release,
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT is an independent engine that uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, producing some negative effects. This is also experimental stuff and may have crashbugs or desyncs. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''#SpringMT9411''' to get access to MT autohosts.

'''Complete 94.11 MT + 94.11''' 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe Windows installer] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z Windows portable] 

'''Executables only''' 
Unzip to the install folder of the official release. Linux and OSX may require a portable installation. 

'''94.11 MT (ASIM APATH GML)''' 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z Windows] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z Linux32] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z Linux64] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-mt.zip OSX64] 

'''94.11 (ASIM GML OMP)''' 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z Windows] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z Linux32] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z Linux64] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/osx64/%7bMTsim3%7d94.1-16-ge49de6c_MacOSX-10.6-SnowLeopard_spring.zip OSX64] 

'''Source code''' 

[https://github.com/spring/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github 94.11 MT] 

[https://github.com/spring/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github 94.11] 

=== How do I install it on my autohost? ===

'''Dedicated server''' 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-dedicated.zip OSX64] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.11. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-05T10:03:00Z

Zerver: /* How do I install it on my autohost? */

== Spring MT ==
Unofficial 94.11 release,
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT is an independent engine that uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, producing some negative effects. This is also experimental stuff and may have crashbugs or desyncs. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''#SpringMT9411''' to get access to MT autohosts.

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe Windows 94.11 MT + 94.11 full installer] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z Windows 94.11 MT + 94.11 portable] 

'''94.11 MT (ASIM APATH GML) executables''' (unzip to the install folder of the official release) 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z Windows] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z Linux32] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z Linux64] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-mt.zip OSX64] 

'''94.11 (ASIM GML OMP) executables''' (unzip to the install folder of the official release) 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z Windows] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z Linux32] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z Linux64] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/osx64/%7bMTsim3%7d94.1-16-ge49de6c_MacOSX-10.6-SnowLeopard_spring.zip OSX64] 

'''Source code''' 

[https://github.com/spring/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github 94.11 MT] 

[https://github.com/spring/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github 94.11] 

=== How do I install it on my autohost? ===

'''Dedicated server''' 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-dedicated.zip OSX64] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.11. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-05T10:01:17Z

Zerver: /* How do I install it? */

== Spring MT ==
Unofficial 94.11 release,
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT is an independent engine that uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, producing some negative effects. This is also experimental stuff and may have crashbugs or desyncs. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''#SpringMT9411''' to get access to MT autohosts.

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe Windows 94.11 MT + 94.11 full installer] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z Windows 94.11 MT + 94.11 portable] 

'''94.11 MT (ASIM APATH GML) executables''' (unzip to the install folder of the official release) 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z Windows] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z Linux32] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z Linux64] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-mt.zip OSX64] 

'''94.11 (ASIM GML OMP) executables''' (unzip to the install folder of the official release) 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z Windows] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z Linux32] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z Linux64] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/osx64/%7bMTsim3%7d94.1-16-ge49de6c_MacOSX-10.6-SnowLeopard_spring.zip OSX64] 

'''Source code''' 

[https://github.com/spring/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github 94.11 MT] 

[https://github.com/spring/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github 94.11] 

=== How do I install it on my autohost? ===
[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows dedicated server] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32 dedicated server] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64 dedicated server] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-dedicated.zip OSX64 dedicated server] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.11. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-05T00:19:54Z

Zerver: /* How do I install it on my autohost? */ osx dedicated

== Spring MT ==
Unofficial 94.11 release,
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT is an independent engine that uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, producing some negative effects. This is also experimental stuff and may have crashbugs or desyncs. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''#SpringMT9411''' to get access to MT autohosts.

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe Windows full installer] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z Windows portable] 

'''Executables only''' (unzip to 94.1 install folder) 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z Windows 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z Windows 94.11] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z Linux32 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z Linux32 94.11] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z Linux64 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z Linux64 94.11] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-mt.zip OSX64 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/osx64/%7bMTsim3%7d94.1-16-ge49de6c_MacOSX-10.6-SnowLeopard_spring.zip OSX64 94.11] 

'''Source code''' 

[https://github.com/spring/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github 94.11 MT] 

[https://github.com/spring/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github 94.11] 

=== How do I install it on my autohost? ===
[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows dedicated server] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32 dedicated server] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64 dedicated server] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-dedicated.zip OSX64 dedicated server] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.11. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-05T00:18:24Z

Zerver: /* How do I install it? */ osx

== Spring MT ==
Unofficial 94.11 release,
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT is an independent engine that uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, producing some negative effects. This is also experimental stuff and may have crashbugs or desyncs. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''#SpringMT9411''' to get access to MT autohosts.

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe Windows full installer] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z Windows portable] 

'''Executables only''' (unzip to 94.1 install folder) 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z Windows 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z Windows 94.11] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z Linux32 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z Linux32 94.11] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z Linux64 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z Linux64 94.11] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/osx64/%7bMTsim2%7d94.1-19-g1f3d930_MacOSX-10.6-SnowLeopard_spring-mt.zip OSX64 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/osx64/%7bMTsim3%7d94.1-16-ge49de6c_MacOSX-10.6-SnowLeopard_spring.zip OSX64 94.11] 

'''Source code''' 

[https://github.com/spring/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github 94.11 MT] 

[https://github.com/spring/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github 94.11] 

=== How do I install it on my autohost? ===
[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows dedicated server] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32 dedicated server] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64 dedicated server] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.11. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-04T22:51:22Z

Zerver: /* What is Spring MT? */

== Spring MT ==
Unofficial 94.11 release,
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT is an independent engine that uses multithreaded asynchronous simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, producing some negative effects. This is also experimental stuff and may have crashbugs or desyncs. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''#SpringMT9411''' to get access to MT autohosts.

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe Windows full installer] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z Windows portable] 

'''Executables only''' (unzip to 94.1 install folder) 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z Windows 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z Windows 94.11] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z Linux32 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z Linux32 94.11] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z Linux64 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z Linux64 94.11] 

'''Source code''' 

[https://github.com/spring/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github Spring MT 94.11] 

[https://github.com/spring/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github Spring 94.11] 

=== How do I install it on my autohost? ===
[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows dedicated server] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32 dedicated server] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64 dedicated server] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.11. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-04T22:49:22Z

Zerver: /* Should I use MT even if I don't want to play on MT servers? */

== Spring MT ==
Unofficial 94.11 release,
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT is an independent engine that uses asynchronous multithreaded simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, producing some negative effects. This is also experimental stuff and may have crashbugs or desyncs. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring 94.11 (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''#SpringMT9411''' to get access to MT autohosts.

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe Windows full installer] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z Windows portable] 

'''Executables only''' (unzip to 94.1 install folder) 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z Windows 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z Windows 94.11] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z Linux32 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z Linux32 94.11] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z Linux64 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z Linux64 94.11] 

'''Source code''' 

[https://github.com/spring/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github Spring MT 94.11] 

[https://github.com/spring/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github Spring 94.11] 

=== How do I install it on my autohost? ===
[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows dedicated server] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32 dedicated server] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64 dedicated server] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.11. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-04T22:30:29Z

Zerver: /* How do I install it? */

== Spring MT ==
Unofficial 94.11 release,
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT is an independent engine that uses asynchronous multithreaded simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, producing some negative effects. This is also experimental stuff and may have crashbugs or desyncs. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''#SpringMT9411''' to get access to MT autohosts.

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe Windows full installer] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z Windows portable] 

'''Executables only''' (unzip to 94.1 install folder) 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z Windows 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z Windows 94.11] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z Linux32 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z Linux32 94.11] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z Linux64 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z Linux64 94.11] 

'''Source code''' 

[https://github.com/spring/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github Spring MT 94.11] 

[https://github.com/spring/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github Spring 94.11] 

=== How do I install it on my autohost? ===
[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows dedicated server] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32 dedicated server] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64 dedicated server] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.11. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-04-04T22:29:50Z

Zerver: /* Spring MT */ 94.11

== Spring MT ==
Unofficial 94.11 release,
compatible with Spring 94.1

=== What is Spring MT? ===
Spring MT is an independent engine that uses asynchronous multithreaded simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, producing some negative effects. This is also experimental stuff and may have crashbugs or desyncs. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''#SpringMT9411''' to get access to MT autohosts.

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930.exe Windows full installer] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/spring_94.1-19-g1f3d930_portable.7z Windows portable] 

'''Executables only''' (unzip to 94.0 install folder) 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt.7z Windows 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/win32/%7bMTsim3%7d94.1-16-ge49de6c_spring.7z Windows 94.11] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux32-static.7z Linux32 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux32/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux32-static.7z Linux32 94.11] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-mt-linux64-static.7z Linux64 94.11 MT] 

[http://springrts.com/dl/buildbot/default/MTsim3/94.1-16-ge49de6c/linux64/%7bMTsim3%7d94.1-16-ge49de6c_spring-linux64-static.7z Linux64 94.11] 

'''Source code''' 

[https://github.com/spring/spring/tree/1f3d930a716bb0260e8d12b7d80b8f8f0299a908 Github Spring MT 94.11] 

[https://github.com/spring/spring/tree/e49de6c299860728208ee60c2092c2131cae1363 Github Spring 94.11] 

=== How do I install it on my autohost? ===
[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/win32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated.7z Windows dedicated server] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux32/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux32-static.7z Linux32 dedicated server] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.1-19-g1f3d930/linux64/%7bMTsim2%7d94.1-19-g1f3d930_spring-dedicated-linux64-static.7z Linux64 dedicated server] 

In '''spads.conf''' set masterChannel:SpringMT9411 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.11. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-03-24T18:19:56Z

Zerver: /* Where can I get the source code? */

== Spring MT ==
Unofficial 94.01 release,
compatible with Spring 94.0

=== What is Spring MT? ===
Spring MT is an independent engine that uses asynchronous multithreaded simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, producing some negative effects. This is also experimental stuff and may have crashbugs or desyncs. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''#SpringMT9401''' to get access to MT autohosts.

[http://springrts.com/dl/buildbot/default/MTsim2/94.0-5-g67f92b3/win32/spring_94.0-5-g67f92b3.exe Windows full installer] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.0-5-g67f92b3/win32/spring_94.0-5-g67f92b3_portable.7z Windows portable] 

'''Executables only''' (unzip to 94.0 install folder) 

[http://springfiles.com/spring/spring-base/spring-mt-win32-executables Windows] 

[http://springfiles.com/spring/spring-base/spring-mt-linux32-executables Linux32] 

[http://springfiles.com/spring/spring-base/spring-mt-linux64-executables Linux64] 

[http://springfiles.com/spring/spring-base/spring-mt-osx64-executables OSX64] 

'''Source code''' 

[https://github.com/spring/spring/tree/67f92b36cf99c9374fb8f6a1b989bc86e7b50e74 Github Spring MT 94.01] 

[https://github.com/spring/spring/tree/5a59047e6bb2c85fcb3ed11b9379c28276832370 Github Spring 94.01] 

=== How do I install it on my autohost? ===
[http://springrts.com/dl/buildbot/default/MTsim2/94.0-5-g67f92b3/win32/%7bMTsim2%7d94.0-5-g67f92b3_spring-dedicated.7z Windows dedicated server] 

In '''spads.conf''' set masterChannel:SpringMT9401 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.01. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-03-24T18:16:19Z

Zerver: /* How do I install it? */ source code

== Spring MT ==
Unofficial 94.01 release,
compatible with Spring 94.0

=== What is Spring MT? ===
Spring MT is an independent engine that uses asynchronous multithreaded simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, producing some negative effects. This is also experimental stuff and may have crashbugs or desyncs. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''#SpringMT9401''' to get access to MT autohosts.

[http://springrts.com/dl/buildbot/default/MTsim2/94.0-5-g67f92b3/win32/spring_94.0-5-g67f92b3.exe Windows full installer] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.0-5-g67f92b3/win32/spring_94.0-5-g67f92b3_portable.7z Windows portable] 

'''Executables only''' (unzip to 94.0 install folder) 

[http://springfiles.com/spring/spring-base/spring-mt-win32-executables Windows] 

[http://springfiles.com/spring/spring-base/spring-mt-linux32-executables Linux32] 

[http://springfiles.com/spring/spring-base/spring-mt-linux64-executables Linux64] 

[http://springfiles.com/spring/spring-base/spring-mt-osx64-executables OSX64] 

=== Where can I get the source code? ===
[https://github.com/spring/spring/tree/67f92b36cf99c9374fb8f6a1b989bc86e7b50e74 Github Spring MT 94.01] 

[https://github.com/spring/spring/tree/5a59047e6bb2c85fcb3ed11b9379c28276832370 Github Spring 94.01] 

=== How do I install it on my autohost? ===
[http://springrts.com/dl/buildbot/default/MTsim2/94.0-5-g67f92b3/win32/%7bMTsim2%7d94.0-5-g67f92b3_spring-dedicated.7z Windows dedicated server] 

In '''spads.conf''' set masterChannel:SpringMT9401 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.01. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

Spring MT

2013-03-24T17:24:21Z

Zerver: /* Spring MT */ update 94.01

== Spring MT ==
Unofficial 94.01 release,
compatible with Spring 94.0

=== What is Spring MT? ===
Spring MT is an independent engine that uses asynchronous multithreaded simulation (MT ASIM) to a much higher degree than the official Spring release. It also uses asynchronous pathfinding (APATH). This typically translates into significantly higher performance, depending on your hardware.

=== What hardware do I need? ===
You need '''three physical cores''' to get any real benefit. A quad core or better is recommended. 
[[Image:Spring_MT_core_layout.gif|666px]]
=== How much faster is it? ===
Typically '''more than 100% faster''' with a quad core. Benchmarked using Core I7 2600K, BA7.72, DeltaSiegeDry, Default pathfinder, 4x "give all".

=== How can it be faster? ===
The simulation will run on several CPU cores, and the pathfinder may also run on a separate core.

=== How does Spring / Spring MT play together? ===
Spring MT includes Spring, and uses automatic engine type detection to make it sync-compatible.

=== On which servers can I play Spring MT? ===
Look for servers that have "Spring MT" or "MT" in the description. These servers may have protected access and will send you a chat message with instructions how to join.

=== What is the downside? ===
The simulation may work slightly differently, producing some negative effects. This is also experimental stuff and may have crashbugs or desyncs. The Default pathfinder is recommended because the QTPFS pathfinder tends to kill the performance of Spring MT.

=== Should I use MT even if I don't want to play on MT servers? ===
You can give it a try, the included Spring (non-MT) version also has automatic CPU affinity setup that may give you some more performance.

=== How do I install it? ===
Note: After installation, join lobby chat room '''#SpringMT9401''' to get access to MT autohosts.

[http://springrts.com/dl/buildbot/default/MTsim2/94.0-5-g67f92b3/win32/spring_94.0-5-g67f92b3.exe Windows full installer] 

[http://springrts.com/dl/buildbot/default/MTsim2/94.0-5-g67f92b3/win32/spring_94.0-5-g67f92b3_portable.7z Windows portable] 

'''Executables only''' (unzip to 94.0 install folder) 

[http://springfiles.com/spring/spring-base/spring-mt-win32-executables Windows] 

[http://springfiles.com/spring/spring-base/spring-mt-linux32-executables Linux32] 

[http://springfiles.com/spring/spring-base/spring-mt-linux64-executables Linux64] 

[http://springfiles.com/spring/spring-base/spring-mt-osx64-executables OSX64] 

=== How do I install it on my autohost? ===
[http://springrts.com/dl/buildbot/default/MTsim2/94.0-5-g67f92b3/win32/%7bMTsim2%7d94.0-5-g67f92b3_spring-dedicated.7z Windows dedicated server] 

In '''spads.conf''' set masterChannel:SpringMT9401 

In '''spads.pl''', search for "sub cbJoinBattleRequest" and insert these lines of code immediately after the second line (the one that starts with "my"):
<pre>
if (!exists $lobby->{channels}->{$masterChannel} ||
!exists $lobby->{channels}->{$masterChannel}->{$user}) {
my $mtmsg = "This server requires Spring MT 94.01. ".
"Install http://springrts.com/wiki/Spring_MT";
sayPrivate($user,$mtmsg);
queueLobbyCommand(['JOINBATTLEDENY',$user,$mtmsg]);
return;
}
</pre>
Consider disabling spads auto update to avoid the changes being overwritten.

[[Category:Engine Dev]]

File:Spring MT core layout.gif

2013-03-24T17:16:14Z

Zerver: CPU core layout for Spring MT

CPU core layout for Spring MT

Modrules.lua

2013-03-22T23:25:26Z

Zerver: /* system */

==Location==
<code>modrules.lua</code> is a file in the <code>Gamedata/</code> directory of a Spring game.

==Purpose==
This file controls various global parameters of the game, for example how fast units gain experience, what unit types can be transported, how fine grained the LOS system is, etc.

==Source==
The engine source code which parses the data from this file is viewable here:

* {{sourcelink|file=rts/Sim/Misc/ModInfo.cpp}}

==Details==
<code>Modrules.lua</code> is divided into several sub-tables containing tags specific to each section, as follows:

===capture===
{{tag
|name = energyCostFactor
|type = float
|default = 0.0
|description = How much of the original energy cost it requires to capture something.
}}

===construction===
{{tag
|name = constructionDecay
|type = bool
|default = true
|description = Do uncompleted building frames begin to decay if no builder is working on them?
}}

{{tag
|name = constructionDecayTime
|type = float
|default = 6.66
|description = The time in seconds before abandoned building frames begin to decay.
}}

{{tag
|name = constructionDecaySpeed
|type = float
|default = 0.03
|description = How fast build progress decays for abandoned building frames. Note that the rate is inversely proportional to the {{xtaglink|Units-UnitDefs|buildtime}} i.e. a building with a larger {{xtaglink|Units-UnitDefs|buildtime}} will decay more slowly for a given value of this tag than a building with a shorter {{xtaglink|Units-UnitDefs|buildtime}}.
}}

===experience===
{{tag
|name = experienceMult
|type = float
|default = 1.0
|description = Controls the amount of experience gained by units engaging in combat. The formulae used are:
::<code>xp for damage = 0.1 * experienceMult * damage / target_HP * target_power / attacker_power</code>
::<code>xp for kill = 0.1 * experienceMult * target_power / attacker_power</code>.
: Where {{xtaglink|Units-UnitDefs|power}} can be set by the UnitDef tag.
}}

{{tag
|name = powerScale
|type = float
|default = 1.0
|description = Controls how gaining experience changes the relative {{xtaglink|Units-UnitDefs|power}} of the unit. The formula used is <code>Power multiplier = powerScale * (1 + xp / (xp + 1))</code>.
}}

{{tag
|name = healthScale
|type = float
|default = 0.7
|description = Controls how gaining experience increases the {{xtaglink|Units-UnitDefs|maxDamage}} (total hitpoints) of the unit. The formula used is <code>Health multiplier = healthScale * (1 + xp / (xp + 1))</code>.
}}

{{tag
|name = reloadScale
|type = float
|default = 0.4
|description = Controls how gaining experience decreases the {{xtaglink|Units-UnitDefs|reloadTime}} of the unit's weapons. The formula used is <code>Rate of fire multiplier = reloadScale * (1 + xp / (xp + 1))</code>.
}}

===featureLOS===
{{tag
|name = featureVisibility
|type = int
|default = 3
|description = Controls the visibility of features. Can be <code>0</code> - no default LOS for features, <code>1</code> - Gaia features always visible, <code>2</code> - allyteam & Gaia features always visible, or <code>3</code> - all features always visible.
}}

===fireAtDead===
{{tag
|name = fireAtKilled
|type = bool
|default = false
|description = Will units continue to target and fire on enemies which are running their <code>Killed()</code> animation? (See [[Animation-LuaCallins#Generic]])
}}

{{tag
|name = fireAtCrashing
|type = bool
|default = false
|description = Will units continue to target and fire on enemy aircraft which are in the 'crashing' state? (See [[Lua_SyncedCtrl#Unit_Control]])
}}

===flankingBonus===
For a deeper explanation of the flanking system, see [[Units:FlankingBonus]].

{{tag
|name = defaultMode
|type = int
|default = 1
|description = The default {{xtaglink|Units-UnitDefs|flankingBonusMode}} for units. Can be <code>0</code> - No flanking bonus. Mode <code>1</code> builds up the ability to move over time, and swings to face attacks, but does not respect the way the unit is facing. Mode <code>2</code> also can swing, but moves with the unit as it turns. Mode <code>3</code> stays with the unit as it turns and otherwise doesn't move, the ideal mode to simulate something such as tank armour.
}}

====los====
{{tag
|name = losMipLevel
|type = int
|default = 1
|description = Controls the resolution of the LOS calculations. A higher value means lower resolution but increased performance. An increase by one level means half the resolution of the LOS map in both x and y direction. Must be between <code>0</code> and <code>6</code> inclusive.
}}

{{tag
|name = losMul
|type = float
|default = 1.0
|description = Multiplies all unit's {{xtaglink|Units-UnitDefs|sightDistance}} by this value. Generally speaking you should always use the default.
}}

{{tag
|name = airMipLevel
|type = int
|default = 2
|description = Controls the resolution of the LOS vs. aircraft calculations. A higher value means lower resolution but increased performance. An increase by one level means half the resolution of the air-LOS map in both x and y direction. Must be between <code>0</code> and <code>30</code> inclusive.
}}

{{tag
|name = airLosMul
|type = float
|default = 1.0
|description = Multiplies all unit's {{xtaglink|Units-UnitDefs|airSightDistance}} by this value. Generally speaking you should always use the default.
}}

===movement===
{{tag
|name = allowAirPlanesToLeaveMap
|type = bool
|default = true
|description = Are (gunship) aircraft allowed to fly outside the bounds of the map?
}}

{{tag
|name = allowAircraftToHitGround
|type = bool
|default = true
|special = {{new|90.0}}
|description = Are aircraft allowed to hit the ground whilst manoeuvring?
}}

{{tag
|name = allowPushingEnemyUnits
|type = bool
|default = false
|special = {{new|83.0}}
|description = Can enemy ground units push each other during collisions?
}}

{{tag
|name = allowCrushingAlliedUnits
|type = bool
|default = false
|special = {{new|85.0}}
|description = Can allied ground units crush each other during collisions? Units still have to be explicitly set as crushable using the <code>crushable</code> parameter of [[Lua_SyncedCtrl#Unit_Control|Spring.SetUnitBlocking]].
}}

{{tag
|name = allowUnitCollisionDamage
|type = bool
|default = false
|special = {{new|85.0}}
|description = Do unit-unit (skidding) collisions cause damage?
}}

{{tag
|name = allowUnitCollisionOverlap
|type = bool
|default = true
|special = {{new|89.0}}
|description = Can mobile units collision volumes overlap one another? Allows unit movement like [http://www.youtube.com/watch?v=mRtePUdVk2o this (video)] at the cost of more 'clumping'.
}}

{{tag
|name = allowGroundUnitGravity
|type = bool
|default = true
|special = {{new|92.0}}
|description = Allows fast moving mobile units to 'catch air' as they move over terrain.
}}

{{tag
|name = allowHoverUnitStrafing
|type = bool
|default = true if using QTPFS pathfinder
|special = {{new|92.0}}
|description = Allows hovercraft units to slide in turns.
}}

{{tag
|name = useClassicGroundMoveType
|type = bool
|default = false
|special = {{new|89.0}}
|description = A ticket back to unit movement circa 2009: no reversing, no {{xtaglink|Units-UnitDefs|turninplace|false}}, no smooth collision handling, no nothing. For comparison of pathfinding code.
}}

===nanospray===
{{tag
|name = allow_team_colors
|type = bool
|default = true
|description = Are players allowed to use teamcolour nanospray? Set by the <code>TeamNanoSpray</code> key in the [[Springrc|config file]].
}}

===paralyze===
{{tag
|name = paralyzeOnMaxHealth
|type = bool
|default = true
|description = Are units paralyzed when the level of emp is greater than their current health or their maximum health?
}}

===reclaim===
{{tag
|name = multiReclaim
|type = int
|default = 0
|description = Can multiple units reclaim a feature or only one? <code>0</code> implies the latter, all other values the former.
}}

{{tag
|name = reclaimMethod
|type = int
|default = 1
|description = Controls how features are reclaimed. Can be <code>0</code> - gradual reclaim, <code>1</code> - all reclaimed at end, any other positive value <code>n</code> - reclaim in <code>n</code> chunks.
}}

{{tag
|name = unitMethod
|type = int
|default = 1
|description = Controls how units are reclaimed. Can be <code>0</code> - gradual reclaim, <code>1</code> - all reclaimed at end, any other positive value <code>n</code> - reclaim in <code>n</code> chunks.
}}

{{tag
|name = featureEnergyCostFactor
|type = float
|default = 0.0
|description = How much energy should reclaiming a feature cost? Multiplier against the fraction of the features' {{xtaglink|Units-FeatureDefs|metal}} content reclaimed.
}}

{{tag
|name = unitEnergyCostFactor
|type = float
|default = 0.0
|description = How much energy should reclaiming a unit cost? Multiplier against the fraction of the unit's {{xtaglink|Units-UnitDefs|buildCostEnergy}} reclaimed.
}}

{{tag
|name = unitEfficiency
|type = float
|default = 1.0
|description = How much metal should reclaiming a unit return? Multiplier against the unit's {{xtaglink|Units-UnitDefs|buildCostMetal}}.
}}

{{tag
|name = allowEnemies
|type = bool
|default = true
|description = Can enemy units be reclaimed?
}}

{{tag
|name = allowAllies
|type = bool
|default = true
|description = Can allied units be reclaimed?
}}

===repair===
{{tag
|name = energyCostFactor
|type = float
|default = 0.0
|description = How much of the original energy cost it requires to repair something.
}}

===resurrect===
{{tag
|name = energyCostFactor
|type = float
|default = 0.5
|description = How much of the original energy cost it requires to resurrect something.
}}

===sensors===
{{tag
|name = requireSonarUnderWater
|type = bool
|default = true
|description = If <code>true</code> then when underwater, units only get LOS if they also have sonar.
}}

===system===
{{tag
|name = luaThreadingModel
|type = int
|default = 2
|description = Controls if and how the game supports Asynchronous Simulation, a more detailed explanation can be found [[Asynchronous_Simulation#Lua_Threading_Models|here]]. Can be:
::<code>0</code> - No MT, single threaded;
::<code>1</code> - Single state;
::<code>2</code> - Single state, batching of unsynced events;
::<code>3</code> - Dual states for synced, batching of unsynced events, synced/unsynced communication via EXPORT table and SendToUnsynced;
::<code>4</code> - Dual states for synced, batching of unsynced events, synced/unsynced communication via SendToUnsynced only;
::<code>5</code> - Dual states for all, all synced/unsynced communication (widgets included) via SendToUnsynced only;
::<code>6</code> - Dual states for all, all synced/unsynced communication (widgets included) is unmanaged and via SendToUnsynced only.}}

{{tag
|name = pathFinderSystem
|type = int
|default = 0
|special={{new|85.0}}
|description = Which pathfinder does the game use? Can be <code>0</code> - The legacy default pathfinder or <code>1</code> - Quad-Tree Pathfinder System ([[QTPFS]]).}}

===transportability===
{{tag
|name = transportAir
|type = bool
|default = false
|description = Can aircraft be transported?
}}

{{tag
|name = transportShip
|type = bool
|default = false
|description = Can ships be transported?
}}

{{tag
|name = transportHover
|type = bool
|default = false
|description = Can hovercraft be transported?
}}

{{tag
|name = transportGround
|type = bool
|default = true
|description = Can ground units be transported?
}}

{{tag
|name = targetableTransportedUnits
|type = bool
|default = false
|special = {{new|89.0}}
|description = Can transported units be targeted by weapons? <code>true</code> allows both manual and automatic targeting.
}}

==Examples==

===Empty===

<code>modrules.lua</code> can simply return an empty table like this:
<code><pre>
return {}
</pre></code>
If you do this, Spring will use the default values.

===Configurable by modoptions===
Interestingly <code>modrules.lua</code> can read [[Modoptions.lua|modoptions]], so these parameters can be scripted to be configurable from the lobby.
For example to allow selecting either legacy default pathfinder or [[QTPFS]] via a modoption:
<code>
system = {
pathFinderSystem = (Spring.GetModOptions() and (Spring.GetModOptions().qtpfs == "1") and 1) or 0,
},
</code>

===External Examples===
[http://imolarpg.dyndns.org/trac/balatest/browser/trunk/gamedata/modrules.lua 'Balanced Annihilation' Modrules.lua]

[http://trac.caspring.org/browser/trunk/mods/ca/gamedata/modrules.lua 'Complete Annihilation' Modrules.lua]

[http://code.google.com/p/conflictterra/source/browse/games/CT/gamedata/modrules.lua 'Conflict Terra' Modrules.lua]

[https://code.google.com/p/evolutionrts/source/browse/trunk/evolutiondev.sdd/Gamedata/modrules.lua 'Evolution RTS' Modrules.lua]

[http://spring1944.svn.sourceforge.net/viewvc/spring1944/trunk/S44Main.sdd/gamedata/modrules.lua?&view=markup 'Spring: 1944' Modrules.lua]

[http://code.google.com/p/zero-k/source/browse/trunk/mods/zk/gamedata/modrules.lua 'ZeroK' Modrules.lua]

[[Category:gamedata]]

Modrules.lua

2013-03-22T23:22:56Z

Zerver: /* system */

==Location==
<code>modrules.lua</code> is a file in the <code>Gamedata/</code> directory of a Spring game.

==Purpose==
This file controls various global parameters of the game, for example how fast units gain experience, what unit types can be transported, how fine grained the LOS system is, etc.

==Source==
The engine source code which parses the data from this file is viewable here:

* {{sourcelink|file=rts/Sim/Misc/ModInfo.cpp}}

==Details==
<code>Modrules.lua</code> is divided into several sub-tables containing tags specific to each section, as follows:

===capture===
{{tag
|name = energyCostFactor
|type = float
|default = 0.0
|description = How much of the original energy cost it requires to capture something.
}}

===construction===
{{tag
|name = constructionDecay
|type = bool
|default = true
|description = Do uncompleted building frames begin to decay if no builder is working on them?
}}

{{tag
|name = constructionDecayTime
|type = float
|default = 6.66
|description = The time in seconds before abandoned building frames begin to decay.
}}

{{tag
|name = constructionDecaySpeed
|type = float
|default = 0.03
|description = How fast build progress decays for abandoned building frames. Note that the rate is inversely proportional to the {{xtaglink|Units-UnitDefs|buildtime}} i.e. a building with a larger {{xtaglink|Units-UnitDefs|buildtime}} will decay more slowly for a given value of this tag than a building with a shorter {{xtaglink|Units-UnitDefs|buildtime}}.
}}

===experience===
{{tag
|name = experienceMult
|type = float
|default = 1.0
|description = Controls the amount of experience gained by units engaging in combat. The formulae used are:
::<code>xp for damage = 0.1 * experienceMult * damage / target_HP * target_power / attacker_power</code>
::<code>xp for kill = 0.1 * experienceMult * target_power / attacker_power</code>.
: Where {{xtaglink|Units-UnitDefs|power}} can be set by the UnitDef tag.
}}

{{tag
|name = powerScale
|type = float
|default = 1.0
|description = Controls how gaining experience changes the relative {{xtaglink|Units-UnitDefs|power}} of the unit. The formula used is <code>Power multiplier = powerScale * (1 + xp / (xp + 1))</code>.
}}

{{tag
|name = healthScale
|type = float
|default = 0.7
|description = Controls how gaining experience increases the {{xtaglink|Units-UnitDefs|maxDamage}} (total hitpoints) of the unit. The formula used is <code>Health multiplier = healthScale * (1 + xp / (xp + 1))</code>.
}}

{{tag
|name = reloadScale
|type = float
|default = 0.4
|description = Controls how gaining experience decreases the {{xtaglink|Units-UnitDefs|reloadTime}} of the unit's weapons. The formula used is <code>Rate of fire multiplier = reloadScale * (1 + xp / (xp + 1))</code>.
}}

===featureLOS===
{{tag
|name = featureVisibility
|type = int
|default = 3
|description = Controls the visibility of features. Can be <code>0</code> - no default LOS for features, <code>1</code> - Gaia features always visible, <code>2</code> - allyteam & Gaia features always visible, or <code>3</code> - all features always visible.
}}

===fireAtDead===
{{tag
|name = fireAtKilled
|type = bool
|default = false
|description = Will units continue to target and fire on enemies which are running their <code>Killed()</code> animation? (See [[Animation-LuaCallins#Generic]])
}}

{{tag
|name = fireAtCrashing
|type = bool
|default = false
|description = Will units continue to target and fire on enemy aircraft which are in the 'crashing' state? (See [[Lua_SyncedCtrl#Unit_Control]])
}}

===flankingBonus===
For a deeper explanation of the flanking system, see [[Units:FlankingBonus]].

{{tag
|name = defaultMode
|type = int
|default = 1
|description = The default {{xtaglink|Units-UnitDefs|flankingBonusMode}} for units. Can be <code>0</code> - No flanking bonus. Mode <code>1</code> builds up the ability to move over time, and swings to face attacks, but does not respect the way the unit is facing. Mode <code>2</code> also can swing, but moves with the unit as it turns. Mode <code>3</code> stays with the unit as it turns and otherwise doesn't move, the ideal mode to simulate something such as tank armour.
}}

====los====
{{tag
|name = losMipLevel
|type = int
|default = 1
|description = Controls the resolution of the LOS calculations. A higher value means lower resolution but increased performance. An increase by one level means half the resolution of the LOS map in both x and y direction. Must be between <code>0</code> and <code>6</code> inclusive.
}}

{{tag
|name = losMul
|type = float
|default = 1.0
|description = Multiplies all unit's {{xtaglink|Units-UnitDefs|sightDistance}} by this value. Generally speaking you should always use the default.
}}

{{tag
|name = airMipLevel
|type = int
|default = 2
|description = Controls the resolution of the LOS vs. aircraft calculations. A higher value means lower resolution but increased performance. An increase by one level means half the resolution of the air-LOS map in both x and y direction. Must be between <code>0</code> and <code>30</code> inclusive.
}}

{{tag
|name = airLosMul
|type = float
|default = 1.0
|description = Multiplies all unit's {{xtaglink|Units-UnitDefs|airSightDistance}} by this value. Generally speaking you should always use the default.
}}

===movement===
{{tag
|name = allowAirPlanesToLeaveMap
|type = bool
|default = true
|description = Are (gunship) aircraft allowed to fly outside the bounds of the map?
}}

{{tag
|name = allowAircraftToHitGround
|type = bool
|default = true
|special = {{new|90.0}}
|description = Are aircraft allowed to hit the ground whilst manoeuvring?
}}

{{tag
|name = allowPushingEnemyUnits
|type = bool
|default = false
|special = {{new|83.0}}
|description = Can enemy ground units push each other during collisions?
}}

{{tag
|name = allowCrushingAlliedUnits
|type = bool
|default = false
|special = {{new|85.0}}
|description = Can allied ground units crush each other during collisions? Units still have to be explicitly set as crushable using the <code>crushable</code> parameter of [[Lua_SyncedCtrl#Unit_Control|Spring.SetUnitBlocking]].
}}

{{tag
|name = allowUnitCollisionDamage
|type = bool
|default = false
|special = {{new|85.0}}
|description = Do unit-unit (skidding) collisions cause damage?
}}

{{tag
|name = allowUnitCollisionOverlap
|type = bool
|default = true
|special = {{new|89.0}}
|description = Can mobile units collision volumes overlap one another? Allows unit movement like [http://www.youtube.com/watch?v=mRtePUdVk2o this (video)] at the cost of more 'clumping'.
}}

{{tag
|name = allowGroundUnitGravity
|type = bool
|default = true
|special = {{new|92.0}}
|description = Allows fast moving mobile units to 'catch air' as they move over terrain.
}}

{{tag
|name = allowHoverUnitStrafing
|type = bool
|default = true if using QTPFS pathfinder
|special = {{new|92.0}}
|description = Allows hovercraft units to slide in turns.
}}

{{tag
|name = useClassicGroundMoveType
|type = bool
|default = false
|special = {{new|89.0}}
|description = A ticket back to unit movement circa 2009: no reversing, no {{xtaglink|Units-UnitDefs|turninplace|false}}, no smooth collision handling, no nothing. For comparison of pathfinding code.
}}

===nanospray===
{{tag
|name = allow_team_colors
|type = bool
|default = true
|description = Are players allowed to use teamcolour nanospray? Set by the <code>TeamNanoSpray</code> key in the [[Springrc|config file]].
}}

===paralyze===
{{tag
|name = paralyzeOnMaxHealth
|type = bool
|default = true
|description = Are units paralyzed when the level of emp is greater than their current health or their maximum health?
}}

===reclaim===
{{tag
|name = multiReclaim
|type = int
|default = 0
|description = Can multiple units reclaim a feature or only one? <code>0</code> implies the latter, all other values the former.
}}

{{tag
|name = reclaimMethod
|type = int
|default = 1
|description = Controls how features are reclaimed. Can be <code>0</code> - gradual reclaim, <code>1</code> - all reclaimed at end, any other positive value <code>n</code> - reclaim in <code>n</code> chunks.
}}

{{tag
|name = unitMethod
|type = int
|default = 1
|description = Controls how units are reclaimed. Can be <code>0</code> - gradual reclaim, <code>1</code> - all reclaimed at end, any other positive value <code>n</code> - reclaim in <code>n</code> chunks.
}}

{{tag
|name = featureEnergyCostFactor
|type = float
|default = 0.0
|description = How much energy should reclaiming a feature cost? Multiplier against the fraction of the features' {{xtaglink|Units-FeatureDefs|metal}} content reclaimed.
}}

{{tag
|name = unitEnergyCostFactor
|type = float
|default = 0.0
|description = How much energy should reclaiming a unit cost? Multiplier against the fraction of the unit's {{xtaglink|Units-UnitDefs|buildCostEnergy}} reclaimed.
}}

{{tag
|name = unitEfficiency
|type = float
|default = 1.0
|description = How much metal should reclaiming a unit return? Multiplier against the unit's {{xtaglink|Units-UnitDefs|buildCostMetal}}.
}}

{{tag
|name = allowEnemies
|type = bool
|default = true
|description = Can enemy units be reclaimed?
}}

{{tag
|name = allowAllies
|type = bool
|default = true
|description = Can allied units be reclaimed?
}}

===repair===
{{tag
|name = energyCostFactor
|type = float
|default = 0.0
|description = How much of the original energy cost it requires to repair something.
}}

===resurrect===
{{tag
|name = energyCostFactor
|type = float
|default = 0.5
|description = How much of the original energy cost it requires to resurrect something.
}}

===sensors===
{{tag
|name = requireSonarUnderWater
|type = bool
|default = true
|description = If <code>true</code> then when underwater, units only get LOS if they also have sonar.
}}

===system===
{{tag
|name = luaThreadingModel
|type = int
|default = 2
|description = Controls which Lua MT optimizations the mod will use by default, for a more detailed explanation see [[Asynchronous_Simulation#Lua_Threading_Models|here]]. Can be:
::<code>0</code> - No MT, single threaded;
::<code>1</code> - Single state;
::<code>2</code> - Single state, batching of unsynced events;
::<code>3</code> - Dual states for synced, batching of unsynced events, synced/unsynced communication via EXPORT table and SendToUnsynced;
::<code>4</code> - Dual states for synced, batching of unsynced events, synced/unsynced communication via SendToUnsynced only;
::<code>5</code> - Dual states for all, all synced/unsynced communication (widgets included) via SendToUnsynced only;
::<code>6</code> - Dual states for all, all synced/unsynced communication (widgets included) is unmanaged and via SendToUnsynced only.}}

{{tag
|name = pathFinderSystem
|type = int
|default = 0
|special={{new|85.0}}
|description = Which pathfinder does the game use? Can be <code>0</code> - The legacy default pathfinder or <code>1</code> - Quad-Tree Pathfinder System ([[QTPFS]]).}}

===transportability===
{{tag
|name = transportAir
|type = bool
|default = false
|description = Can aircraft be transported?
}}

{{tag
|name = transportShip
|type = bool
|default = false
|description = Can ships be transported?
}}

{{tag
|name = transportHover
|type = bool
|default = false
|description = Can hovercraft be transported?
}}

{{tag
|name = transportGround
|type = bool
|default = true
|description = Can ground units be transported?
}}

{{tag
|name = targetableTransportedUnits
|type = bool
|default = false
|special = {{new|89.0}}
|description = Can transported units be targeted by weapons? <code>true</code> allows both manual and automatic targeting.
}}

==Examples==

===Empty===

<code>modrules.lua</code> can simply return an empty table like this:
<code><pre>
return {}
</pre></code>
If you do this, Spring will use the default values.

===Configurable by modoptions===
Interestingly <code>modrules.lua</code> can read [[Modoptions.lua|modoptions]], so these parameters can be scripted to be configurable from the lobby.
For example to allow selecting either legacy default pathfinder or [[QTPFS]] via a modoption:
<code>
system = {
pathFinderSystem = (Spring.GetModOptions() and (Spring.GetModOptions().qtpfs == "1") and 1) or 0,
},
</code>

===External Examples===
[http://imolarpg.dyndns.org/trac/balatest/browser/trunk/gamedata/modrules.lua 'Balanced Annihilation' Modrules.lua]

[http://trac.caspring.org/browser/trunk/mods/ca/gamedata/modrules.lua 'Complete Annihilation' Modrules.lua]

[http://code.google.com/p/conflictterra/source/browse/games/CT/gamedata/modrules.lua 'Conflict Terra' Modrules.lua]

[https://code.google.com/p/evolutionrts/source/browse/trunk/evolutiondev.sdd/Gamedata/modrules.lua 'Evolution RTS' Modrules.lua]

[http://spring1944.svn.sourceforge.net/viewvc/spring1944/trunk/S44Main.sdd/gamedata/modrules.lua?&view=markup 'Spring: 1944' Modrules.lua]

[http://code.google.com/p/zero-k/source/browse/trunk/mods/zk/gamedata/modrules.lua 'ZeroK' Modrules.lua]

[[Category:gamedata]]

Asynchronous Simulation

2013-03-22T23:18:08Z

Zerver: /* Common side effects */

== Asynchronous Simulation ==
Asynchronous simulation (ASIM) allows the game physics simulation to run alongside the 3D graphics rendering on a dual core CPU or better. This gives higher performance, and allows the engine to maintain a high rendering frame rate (FPS) at all times even in big battles.

Spring <code>disables ASIM by default</code>, unless a game has been specifically designed to support it. The reason is that ASIM gives rise to Lua related side effects that can be a bit hard to understand, especially for a game designer who has little experience with threaded programming.

== Steps required to support ASIM ==
:'''1.''' Choose a Lua Threading Model > 2 below
:'''2.''' Rewrite the Lua code to conform with the rules imposed by that threading model
:'''3.''' Learn about the side effects of the model chosen and tweak your code to work around it

== Lua Threading Models==
These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better, with less side effects, but also requires more work. A game that specifies <code>luaThreadingModel > 2</code> will be considered ASIM compatible, and will have <code>ASIM enabled by default.</code>

:'''<code>0</code>. No MT, single threaded'''
::For reference only, this mode should never be used in practice

:'''<code>1</code>. Single state'''
::This mode has a single Lua environment for everything. It will cause a significant slowdown because simulation and rendering threads block each other trying to access the shared Lua environment. Especially problematic is Lua rendering; being inherently time consuming (looping through large amounts of units etc.) it will force the simulation thread to wait. This gives rise to the classic phenomenon of having incredibly high FPS but still lagging behind (high ping) since simulation cannot keep up with the normal pace.

:'''<code>2</code>. Single state, batching of unsynced events <code>(default mode)</code>'''
::This mode is considerably better than mode(1) since it has a separate Lua environment for LuaUI.
::All simulation events sent to LuaUI are also batched/delayed to reduce the need for the threads to block each other. For instance, if simulation triggers UnitMoved(), the event will not reach LuaUI right away, but is put in a batch and handled as soon as possible by the rendering thread. The batching system is managed, i.e. if the unit that triggered UnitMoved is about to be deleted (and thus invalidated) the batch is forcefully run before deletion occurs. Because the forced batch run is performed by the simulation thread, locking is required and this can degrade simulation performance for the same reasons as in mode(1).
::The other means of unsynced communication, SendToUnsynced and Script.LuaUI.XXX() are also batched and managed to make sure any object ID or such sent are still valid once the message arrives. Note: Script.LuaUI.XXX() does because of the batching NOT have a return value.
::This mode unfortunately suffers the same problems as mode(1) for rendering gadgets, since simulation events must be sent to the gadgets directly (without batching) in order not to desync the game.
::With this mode, it is illegal to invoke LuaUI from another Lua environment (LuaGaia or LuaRules). This can happen depending on what call-ins the game and any user-enabled widgets implement. If such an attempt to invoke LuaUI is detected, it will be skipped to prevent a deadlock, and a warning will also be printed in the console. Unfortunately there is no other solution than to stop using the call-in that throws the error, or to use a higher threading model.

:'''<code>3</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via EXPORT table and SendToUnsynced'''
::Same as mode(2), but the gadgets have separate Lua environments depending on whether the simulation or rendering thread is invoking it. This alleviates the negative performance impact for rendering gadgets, but makes it impossible to directly share synced gadget data to the unsynced part via _G --> SYNCED. To work around this limitation, this mode introduces _G.EXPORT that is automatically copied to SYNCED.EXPORT. Only small amounts of data should be stored in the EXPORT table, because the copying is performed very frequently. Cyclical and/or very deeply nested tables are not allowed. Larger data can be stored temporarily, e.g.
::_G.EXPORT.myhugetable = huge_table
::SendToUnsynced("huge_table_available")
::_G.EXPORT.myhugetable = nil

:'''<code>4</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via SendToUnsynced only'''
::Same as mode(3) but with the EXPORT table disabled to increase the performance further. You don't need EXPORT, SendToUnsynced alone is sufficient.

:'''<code>5</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''via SendToUnsynced only'''
::Same as mode(4), but adds separate Lua environments for LuaUI depending on whether the simulation or rendering thread is invoking it. With dual LuaUI states, batching is no longer needed and therefore disabled. This makes it even faster, since batching overhead is eliminated and forced batch runs (see mode(2)) are not needed. However, this mode adds significant complexity for the programmer, since essentially two instances of the same widget are run, and only the calling thread determines which one is invoked. As a rule of thumb, all simulation events (GameFrame etc.) are invoked by the simulation thread. All UI and rendering events and Update() are invoked by the rendering thread. So, if a variable is modified in GameFrame(), that change cannot be seen in Update(). The widget must instead use SendToUnsynced to communicate any data from the simulation widget instance to the rendering widget instance. Design wise it may be suitable to write the widget similarly to a gadget, with clearly separated "synced" and "unsynced" parts, each with their own variables, functions and call-ins.

:'''<code>6</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''is unmanaged and via SendToUnsynced only'''
::Same as mode(5) but the SendToUnsynced and Script.LuaUI.XXX() communication is unmanaged. The Lua coder must manually check if object references sent are still valid when the message arrives.

== Common side effects ==
:'''1. Out-of-order execution''', applies to all threading models
::All rendering call-ins (Draw*, Update, Mouse/Keyboard) must be designed so that they work correctly even if objects are deleted (and possibly replaced by another object with same ID) in between the rendering call-ins. This means rendering code that stores lists of e.g. units in global variables must update these according to UnitCreated/UnitDestroyed events or re-check the units for validity before use. Keep in mind that if an object has been replaced, the operation that you intended to perform may no longer be valid for the new object.

:'''2. Performance hit for rendering call-ins in gadgets''', applies to threading models < 3
::Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget by calling Script.LuaUI.XXX(), but the value returned from this call is undefined if ASIM is enabled. Similarly, the result obtained when checking for the existence of a Script.LuaUI.XXX function can be unpredictable, instead the widget may send a LuaRules message to indicate that the function now exists or has ceased to exist. If the LUA-SYNC-CPU indicator appears in the upper right part of the window it usually indicates a performance problem

:'''3. Batching glitches''', applies to threading models 2 - 4
::For example, a widget that processes an UnitEnteredLOS event cannot safely make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this type of issue.

[[Category:Lua]]

Asynchronous Simulation

2013-03-22T23:15:49Z

Zerver: /* Lua Threading Models */

Asynchronous Simulation

2013-03-22T23:14:35Z

Zerver: /* Lua Threading Models */

== Asynchronous Simulation ==
Asynchronous simulation (ASIM) allows the game physics simulation to run alongside the 3D graphics rendering on a dual core CPU or better. This gives higher performance, and allows the engine to maintain a high rendering frame rate (FPS) at all times even in big battles.

Spring <code>disables ASIM by default</code>, unless a game has been specifically designed to support it. The reason is that ASIM gives rise to Lua related side effects that can be a bit hard to understand, especially for a game designer who has little experience with threaded programming.

== Steps required to support ASIM ==
:'''1.''' Choose a Lua Threading Model > 2 below
:'''2.''' Rewrite the Lua code to conform with the rules imposed by that threading model
:'''3.''' Learn about the side effects of the model chosen and tweak your code to work around it

== Lua Threading Models==
These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better, with less side effects, but also requires more work. A game that specifies <code>luaThreadingModel > 2</code> will be considered ASIM compatible, and will have the <code>simulation thread enabled by default.</code>

:'''<code>0</code>. No MT, single threaded'''
::For reference only, this mode should never be used in practice

:'''<code>1</code>. Single state'''
::This mode has a single Lua environment for everything. It will cause a significant slowdown because simulation and rendering threads block each other trying to access the shared Lua environment. Especially problematic is Lua rendering; being inherently time consuming (looping through large amounts of units etc.) it will force the simulation thread to wait. This gives rise to the classic phenomenon of having incredibly high FPS but still lagging behind (high ping) since simulation cannot keep up with the normal pace.

:'''<code>2</code>. Single state, batching of unsynced events <code>(default mode)</code>'''
::This mode is considerably better than mode(1) since it has a separate Lua environment for LuaUI.
::All simulation events sent to LuaUI are also batched/delayed to reduce the need for the threads to block each other. For instance, if simulation triggers UnitMoved(), the event will not reach LuaUI right away, but is put in a batch and handled as soon as possible by the rendering thread. The batching system is managed, i.e. if the unit that triggered UnitMoved is about to be deleted (and thus invalidated) the batch is forcefully run before deletion occurs. Because the forced batch run is performed by the simulation thread, locking is required and this can degrade simulation performance for the same reasons as in mode(1).
::The other means of unsynced communication, SendToUnsynced and Script.LuaUI.XXX() are also batched and managed to make sure any object ID or such sent are still valid once the message arrives. Note: Script.LuaUI.XXX() does because of the batching NOT have a return value.
::This mode unfortunately suffers the same problems as mode(1) for rendering gadgets, since simulation events must be sent to the gadgets directly (without batching) in order not to desync the game.
::With this mode, it is illegal to invoke LuaUI from another Lua environment (LuaGaia or LuaRules). This can happen depending on what call-ins the game and any user-enabled widgets implement. If such an attempt to invoke LuaUI is detected, it will be skipped to prevent a deadlock, and a warning will also be printed in the console. Unfortunately there is no other solution than to stop using the call-in that throws the error, or to use a higher threading model.

:'''<code>3</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via EXPORT table and SendToUnsynced'''
::Same as mode(2), but the gadgets have separate Lua environments depending on whether the simulation or rendering thread is invoking it. This alleviates the negative performance impact for rendering gadgets, but makes it impossible to directly share synced gadget data to the unsynced part via _G --> SYNCED. To work around this limitation, this mode introduces _G.EXPORT that is automatically copied to SYNCED.EXPORT. Only small amounts of data should be stored in the EXPORT table, because the copying is performed very frequently. Cyclical and/or very deeply nested tables are not allowed. Larger data can be stored temporarily, e.g.
::_G.EXPORT.myhugetable = huge_table
::SendToUnsynced("huge_table_available")
::_G.EXPORT.myhugetable = nil

:'''<code>4</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via SendToUnsynced only'''
::Same as mode(3) but with the EXPORT table disabled to increase the performance further. You don't need EXPORT, SendToUnsynced alone is sufficient.

:'''<code>5</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''via SendToUnsynced only'''
::Same as mode(4), but adds separate Lua environments for LuaUI depending on whether the simulation or rendering thread is invoking it. With dual LuaUI states, batching is no longer needed and therefore disabled. This makes it even faster, since batching overhead is eliminated and forced batch runs (see mode(2)) are not needed. However, this mode adds significant complexity for the programmer, since essentially two instances of the same widget are run, and only the calling thread determines which one is invoked. As a rule of thumb, all simulation events (GameFrame etc.) are invoked by the simulation thread. All UI and rendering events and Update() are invoked by the rendering thread. So, if a variable is modified in GameFrame(), that change cannot be seen in Update(). The widget must instead use SendToUnsynced to communicate any data from the simulation widget instance to the rendering widget instance. Design wise it may be suitable to write the widget similarly to a gadget, with clearly separated "synced" and "unsynced" parts, each with their own variables, functions and call-ins.

:'''<code>6</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''is unmanaged and via SendToUnsynced only'''
::Same as mode(5) but the SendToUnsynced and Script.LuaUI.XXX() communication is unmanaged. The Lua coder must manually check if object references sent are still valid when the message arrives.

== Common side effects ==
:'''1. Out-of-order execution''', applies to all threading models
::All rendering call-ins (Draw*, Update, Mouse/Keyboard) must be designed so that they work correctly even if objects are deleted (and possibly replaced by another object with same ID) in between the rendering call-ins. This means rendering code that stores lists of e.g. units in global variables must update these according to UnitCreated/UnitDestroyed events or re-check the units for validity before use. Keep in mind that if an object has been replaced, the operation that you intended to perform may no longer be valid for the new object.

:'''2. Performance hit for rendering call-ins in gadgets''', applies to threading models < 3
::Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget by calling Script.LuaUI.XXX(), but the value returned from this call is undefined if ASIM is enabled. Similarly, the result obtained when checking for the existence of a Script.LuaUI.XXX function can be unpredictable, instead the widget may send a LuaRules message to indicate that the function now exists or has ceased to exist. If the LUA-SYNC-CPU indicator appears in the upper right part of the window it usually indicates a performance problem

:'''3. Batching glitches''', applies to threading models 2 - 4
::For example, a widget that processes an UnitEnteredLOS event cannot safely make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this type of issue. Batch management is expensive, making it very difficult to solve this problem engine side.

[[Category:Lua]]

Asynchronous Simulation

2013-03-22T23:08:54Z

Zerver: /* Steps required to support ASIM in your game */

== Asynchronous Simulation ==
Asynchronous simulation (ASIM) allows the game physics simulation to run alongside the 3D graphics rendering on a dual core CPU or better. This gives higher performance, and allows the engine to maintain a high rendering frame rate (FPS) at all times even in big battles.

Spring <code>disables ASIM by default</code>, unless a game has been specifically designed to support it. The reason is that ASIM gives rise to Lua related side effects that can be a bit hard to understand, especially for a game designer who has little experience with threaded programming.

== Steps required to support ASIM ==
:'''1.''' Choose a Lua Threading Model > 2 below
:'''2.''' Rewrite the Lua code to conform with the rules imposed by that threading model
:'''3.''' Learn about the side effects of the model chosen and tweak your code to work around it

== Lua Threading Models==
These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better, with less side effects, but also requires more work. A game that specifies <code>luaThreadingModel > 2</code> will be considered asynchronous simulation (ASIM) compatible, and will have the <code>simulation thread enabled by default.</code>

:'''<code>0</code>. No MT, single threaded'''
::For reference only, this mode should never be used in practice

:'''<code>1</code>. Single state'''
::This mode has a single Lua environment for everything. It will cause a significant slowdown because simulation and rendering threads block each other trying to access the shared Lua environment. Especially problematic is Lua rendering; being inherently time consuming (looping through large amounts of units etc.) it will force the simulation thread to wait. This gives rise to the classic phenomenon of having incredibly high FPS but still lagging behind (high ping) since simulation cannot keep up with the normal pace.

:'''<code>2</code>. Single state, batching of unsynced events <code>(default mode)</code>'''
::This mode is considerably better than mode(1) since it has a separate Lua environment for LuaUI.
::All simulation events sent to LuaUI are also batched/delayed to reduce the need for the threads to block each other. For instance, if simulation triggers UnitMoved(), the event will not reach LuaUI right away, but is put in a batch and handled as soon as possible by the rendering thread. The batching system is managed, i.e. if the unit that triggered UnitMoved is about to be deleted (and thus invalidated) the batch is forcefully run before deletion occurs. Because the forced batch run is performed by the simulation thread, locking is required and this can degrade simulation performance for the same reasons as in mode(1).
::The other means of unsynced communication, SendToUnsynced and Script.LuaUI.XXX() are also batched and managed to make sure any object ID or such sent are still valid once the message arrives. Note: Script.LuaUI.XXX() does because of the batching NOT have a return value.
::This mode unfortunately suffers the same problems as mode(1) for rendering gadgets, since simulation events must be sent to the gadgets directly (without batching) in order not to desync the game.
::With this mode, it is illegal to invoke LuaUI from another Lua environment (LuaGaia or LuaRules). This can happen depending on what call-ins the game and any user-enabled widgets implement. If such an attempt to invoke LuaUI is detected, it will be skipped to prevent a deadlock, and a warning will also be printed in the console. Unfortunately there is no other solution than to stop using the call-in that throws the error, or to use a higher threading model.

:'''<code>3</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via EXPORT table and SendToUnsynced'''
::Same as mode(2), but the gadgets have separate Lua environments depending on whether the simulation or rendering thread is invoking it. This alleviates the negative performance impact for rendering gadgets, but makes it impossible to directly share synced gadget data to the unsynced part via _G --> SYNCED. To work around this limitation, this mode introduces _G.EXPORT that is automatically copied to SYNCED.EXPORT. Only small amounts of data should be stored in the EXPORT table, because the copying is performed very frequently. Cyclical and/or very deeply nested tables are not allowed. Larger data can be stored temporarily, e.g.
::_G.EXPORT.myhugetable = huge_table
::SendToUnsynced("huge_table_available")
::_G.EXPORT.myhugetable = nil

:'''<code>4</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via SendToUnsynced only'''
::Same as mode(3) but with the EXPORT table disabled to increase the performance further. You don't need EXPORT, SendToUnsynced alone is sufficient.

:'''<code>5</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''via SendToUnsynced only'''
::Same as mode(4), but adds separate Lua environments for LuaUI depending on whether the simulation or rendering thread is invoking it. With dual LuaUI states, batching is no longer needed and therefore disabled. This makes it even faster, since batching overhead is eliminated and forced batch runs (see mode(2)) are not needed. However, this mode adds significant complexity for the programmer, since essentially two instances of the same widget are run, and only the calling thread determines which one is invoked. As a rule of thumb, all simulation events (GameFrame etc.) are invoked by the simulation thread. All UI and rendering events and Update() are invoked by the rendering thread. So, if a variable is modified in GameFrame(), that change cannot be seen in Update(). The widget must instead use SendToUnsynced to communicate any data from the simulation widget instance to the rendering widget instance. Design wise it may be suitable to write the widget similarly to a gadget, with clearly separated "synced" and "unsynced" parts, each with their own variables, functions and call-ins.

:'''<code>6</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''is unmanaged and via SendToUnsynced only'''
::Same as mode(5) but the SendToUnsynced and Script.LuaUI.XXX() communication is unmanaged. The Lua coder must manually check if object references sent are still valid when the message arrives.

== Common side effects ==
:'''1. Out-of-order execution''', applies to all threading models
::All rendering call-ins (Draw*, Update, Mouse/Keyboard) must be designed so that they work correctly even if objects are deleted (and possibly replaced by another object with same ID) in between the rendering call-ins. This means rendering code that stores lists of e.g. units in global variables must update these according to UnitCreated/UnitDestroyed events or re-check the units for validity before use. Keep in mind that if an object has been replaced, the operation that you intended to perform may no longer be valid for the new object.

:'''2. Performance hit for rendering call-ins in gadgets''', applies to threading models < 3
::Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget by calling Script.LuaUI.XXX(), but the value returned from this call is undefined if ASIM is enabled. Similarly, the result obtained when checking for the existence of a Script.LuaUI.XXX function can be unpredictable, instead the widget may send a LuaRules message to indicate that the function now exists or has ceased to exist. If the LUA-SYNC-CPU indicator appears in the upper right part of the window it usually indicates a performance problem

:'''3. Batching glitches''', applies to threading models 2 - 4
::For example, a widget that processes an UnitEnteredLOS event cannot safely make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this type of issue. Batch management is expensive, making it very difficult to solve this problem engine side.

[[Category:Lua]]

Asynchronous Simulation

2013-03-22T23:06:49Z

Zerver: /* Lua Threading Models */

== Asynchronous Simulation ==
Asynchronous simulation (ASIM) allows the game physics simulation to run alongside the 3D graphics rendering on a dual core CPU or better. This gives higher performance, and allows the engine to maintain a high rendering frame rate (FPS) at all times even in big battles.

Spring <code>disables ASIM by default</code>, unless a game has been specifically designed to support it. The reason is that ASIM gives rise to Lua related side effects that can be a bit hard to understand, especially for a game designer who has little experience with threaded programming.

== Steps required to support ASIM in your game ==
:'''1.''' Choose a Lua Threading Model > 2 below
:'''2.''' Rewrite your lua code to conform with the rules imposed by that threading model
:'''3.''' Learn about the side effects of the model chosen and tweak your code to work around it

== Lua Threading Models==
These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better, with less side effects, but also requires more work. A game that specifies <code>luaThreadingModel > 2</code> will be considered asynchronous simulation (ASIM) compatible, and will have the <code>simulation thread enabled by default.</code>

:'''<code>0</code>. No MT, single threaded'''
::For reference only, this mode should never be used in practice

:'''<code>1</code>. Single state'''
::This mode has a single Lua environment for everything. It will cause a significant slowdown because simulation and rendering threads block each other trying to access the shared Lua environment. Especially problematic is Lua rendering; being inherently time consuming (looping through large amounts of units etc.) it will force the simulation thread to wait. This gives rise to the classic phenomenon of having incredibly high FPS but still lagging behind (high ping) since simulation cannot keep up with the normal pace.

:'''<code>2</code>. Single state, batching of unsynced events <code>(default mode)</code>'''
::This mode is considerably better than mode(1) since it has a separate Lua environment for LuaUI.
::All simulation events sent to LuaUI are also batched/delayed to reduce the need for the threads to block each other. For instance, if simulation triggers UnitMoved(), the event will not reach LuaUI right away, but is put in a batch and handled as soon as possible by the rendering thread. The batching system is managed, i.e. if the unit that triggered UnitMoved is about to be deleted (and thus invalidated) the batch is forcefully run before deletion occurs. Because the forced batch run is performed by the simulation thread, locking is required and this can degrade simulation performance for the same reasons as in mode(1).
::The other means of unsynced communication, SendToUnsynced and Script.LuaUI.XXX() are also batched and managed to make sure any object ID or such sent are still valid once the message arrives. Note: Script.LuaUI.XXX() does because of the batching NOT have a return value.
::This mode unfortunately suffers the same problems as mode(1) for rendering gadgets, since simulation events must be sent to the gadgets directly (without batching) in order not to desync the game.
::With this mode, it is illegal to invoke LuaUI from another Lua environment (LuaGaia or LuaRules). This can happen depending on what call-ins the game and any user-enabled widgets implement. If such an attempt to invoke LuaUI is detected, it will be skipped to prevent a deadlock, and a warning will also be printed in the console. Unfortunately there is no other solution than to stop using the call-in that throws the error, or to use a higher threading model.

:'''<code>3</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via EXPORT table and SendToUnsynced'''
::Same as mode(2), but the gadgets have separate Lua environments depending on whether the simulation or rendering thread is invoking it. This alleviates the negative performance impact for rendering gadgets, but makes it impossible to directly share synced gadget data to the unsynced part via _G --> SYNCED. To work around this limitation, this mode introduces _G.EXPORT that is automatically copied to SYNCED.EXPORT. Only small amounts of data should be stored in the EXPORT table, because the copying is performed very frequently. Cyclical and/or very deeply nested tables are not allowed. Larger data can be stored temporarily, e.g.
::_G.EXPORT.myhugetable = huge_table
::SendToUnsynced("huge_table_available")
::_G.EXPORT.myhugetable = nil

:'''<code>4</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via SendToUnsynced only'''
::Same as mode(3) but with the EXPORT table disabled to increase the performance further. You don't need EXPORT, SendToUnsynced alone is sufficient.

:'''<code>5</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''via SendToUnsynced only'''
::Same as mode(4), but adds separate Lua environments for LuaUI depending on whether the simulation or rendering thread is invoking it. With dual LuaUI states, batching is no longer needed and therefore disabled. This makes it even faster, since batching overhead is eliminated and forced batch runs (see mode(2)) are not needed. However, this mode adds significant complexity for the programmer, since essentially two instances of the same widget are run, and only the calling thread determines which one is invoked. As a rule of thumb, all simulation events (GameFrame etc.) are invoked by the simulation thread. All UI and rendering events and Update() are invoked by the rendering thread. So, if a variable is modified in GameFrame(), that change cannot be seen in Update(). The widget must instead use SendToUnsynced to communicate any data from the simulation widget instance to the rendering widget instance. Design wise it may be suitable to write the widget similarly to a gadget, with clearly separated "synced" and "unsynced" parts, each with their own variables, functions and call-ins.

:'''<code>6</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''is unmanaged and via SendToUnsynced only'''
::Same as mode(5) but the SendToUnsynced and Script.LuaUI.XXX() communication is unmanaged. The Lua coder must manually check if object references sent are still valid when the message arrives.

== Common side effects ==
:'''1. Out-of-order execution''', applies to all threading models
::All rendering call-ins (Draw*, Update, Mouse/Keyboard) must be designed so that they work correctly even if objects are deleted (and possibly replaced by another object with same ID) in between the rendering call-ins. This means rendering code that stores lists of e.g. units in global variables must update these according to UnitCreated/UnitDestroyed events or re-check the units for validity before use. Keep in mind that if an object has been replaced, the operation that you intended to perform may no longer be valid for the new object.

:'''2. Performance hit for rendering call-ins in gadgets''', applies to threading models < 3
::Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget by calling Script.LuaUI.XXX(), but the value returned from this call is undefined if ASIM is enabled. Similarly, the result obtained when checking for the existence of a Script.LuaUI.XXX function can be unpredictable, instead the widget may send a LuaRules message to indicate that the function now exists or has ceased to exist. If the LUA-SYNC-CPU indicator appears in the upper right part of the window it usually indicates a performance problem

:'''3. Batching glitches''', applies to threading models 2 - 4
::For example, a widget that processes an UnitEnteredLOS event cannot safely make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this type of issue. Batch management is expensive, making it very difficult to solve this problem engine side.

[[Category:Lua]]

Asynchronous Simulation

2013-03-22T23:03:22Z

Zerver: /* Lua Threading Models */

== Asynchronous Simulation ==
Asynchronous simulation (ASIM) allows the game physics simulation to run alongside the 3D graphics rendering on a dual core CPU or better. This gives higher performance, and allows the engine to maintain a high rendering frame rate (FPS) at all times even in big battles.

Spring <code>disables ASIM by default</code>, unless a game has been specifically designed to support it. The reason is that ASIM gives rise to Lua related side effects that can be a bit hard to understand, especially for a game designer who has little experience with threaded programming.

== Steps required to support ASIM in your game ==
:'''1.''' Choose a Lua Threading Model > 2 below
:'''2.''' Rewrite your lua code to conform with the rules imposed by that threading model
:'''3.''' Learn about the side effects of the model chosen and tweak your code to work around it

== Lua Threading Models==
These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better, with less side effects, but also requires more work. A game that specifies <code>luaThreadingModel > 2</code> will be considered asynchronous simulation (ASIM) compatible, and will have the <code>simulation thread enabled by default.</code>

:'''<code>0</code>. No MT, single threaded'''
::For reference only, this mode should never be used in practice

:'''<code>1</code>. Single state'''
::This mode has a single Lua environment for everything. It will cause a significant slowdown because simulation and rendering threads block each other trying to access the shared Lua environment. Especially problematic is Lua rendering; being inherently time consuming (looping through large amounts of units etc.) it will force the simulation thread to wait. This gives rise to the classic phenomenon of having incredibly high FPS but still lagging behind (high ping) since simulation cannot keep up with the normal pace.

:'''<code>2</code>. Single state, batching of unsynced events <code>(default mode)</code>'''
::This mode is considerably better than mode(1) since it has a separate Lua environment for LuaUI.
::All simulation events sent to LuaUI are also batched/delayed to reduce the need for the threads to block each other. For instance, if simulation triggers UnitMoved(), the event will not reach LuaUI right away, but is put in a batch and handled as soon as possible by the rendering thread. The batching system is managed, i.e. if the unit that triggered UnitMoved is about to be deleted (and thus invalidated) the batch is forcefully run before deletion occurs. Because the forced batch run is performed by the simulation thread, locking is required and this can degrade simulation performance for the same reasons as in mode(1).
::The other means of unsynced communication, SendToUnsynced and Script.LuaUI.XXX() are also batched and managed to make sure any object ID or such sent are still valid once the message arrives. Note: Script.LuaUI.XXX() does because of the batching NOT have a return value.
::This mode unfortunately suffers the same problems as mode(1) for rendering gadgets, since simulation events must be sent to the gadgets directly (without batching) in order not to desync the game.
::With this mode, it is illegal to invoke LuaUI from another Lua environment (LuaGaia or LuaRules). This can happen depending on what features (call-ins) the game implements, and what widgets the user has activated. If such an attempt to invoke LuaUI is detected, it will be skipped to prevent a deadlock, and a warning will also be printed in the console. Unfortunately there is no other solution than to stop using the call-in that throws the error, or to use a higher threading model.

:'''<code>3</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via EXPORT table and SendToUnsynced'''
::Same as mode(2), but the gadgets have separate Lua environments depending on whether the simulation or rendering thread is invoking it. This alleviates the negative performance impact for rendering gadgets, but makes it impossible to directly share synced gadget data to the unsynced part via _G --> SYNCED. To work around this limitation, this mode introduces _G.EXPORT that is automatically copied to SYNCED.EXPORT. Only small amounts of data should be stored in the EXPORT table, because the copying is performed very frequently. Cyclical and/or very deeply nested tables are not allowed. Larger data can be stored temporarily, e.g.
::_G.EXPORT.myhugetable = huge_table
::SendToUnsynced("huge_table_available")
::_G.EXPORT.myhugetable = nil

:'''<code>4</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via SendToUnsynced only'''
::Same as mode(3) but with the EXPORT table disabled to increase the performance further. You don't need EXPORT, SendToUnsynced alone is sufficient.

:'''<code>5</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''via SendToUnsynced only'''
::Same as mode(4), but adds separate Lua environments for LuaUI depending on whether the simulation or rendering thread is invoking it. With dual LuaUI states, batching is no longer needed and therefore disabled. This makes it even faster, since batching overhead is eliminated and forced batch runs (see mode(2)) are not needed. However, this mode adds significant complexity for the programmer, since essentially two instances of the same widget are run, and only the calling thread determines which one is invoked. As a rule of thumb, all simulation events (GameFrame etc.) are invoked by the simulation thread. All UI and rendering events and Update() are invoked by the rendering thread. So, if a variable is modified in GameFrame(), that change cannot be seen in Update(). The widget must instead use SendToUnsynced to communicate any data from the simulation widget instance to the rendering widget instance. Design wise it may be suitable to write the widget similarly to a gadget, with clearly separated "synced" and "unsynced" parts, each with their own variables, functions and call-ins.

:'''<code>6</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''is unmanaged and via SendToUnsynced only'''
::Same as mode(5) but the SendToUnsynced and Script.LuaUI.XXX() communication is unmanaged. The Lua coder must manually check if object references sent are still valid when the message arrives.

== Common side effects ==
:'''1. Out-of-order execution''', applies to all threading models
::All rendering call-ins (Draw*, Update, Mouse/Keyboard) must be designed so that they work correctly even if objects are deleted (and possibly replaced by another object with same ID) in between the rendering call-ins. This means rendering code that stores lists of e.g. units in global variables must update these according to UnitCreated/UnitDestroyed events or re-check the units for validity before use. Keep in mind that if an object has been replaced, the operation that you intended to perform may no longer be valid for the new object.

:'''2. Performance hit for rendering call-ins in gadgets''', applies to threading models < 3
::Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget by calling Script.LuaUI.XXX(), but the value returned from this call is undefined if ASIM is enabled. Similarly, the result obtained when checking for the existence of a Script.LuaUI.XXX function can be unpredictable, instead the widget may send a LuaRules message to indicate that the function now exists or has ceased to exist. If the LUA-SYNC-CPU indicator appears in the upper right part of the window it usually indicates a performance problem

:'''3. Batching glitches''', applies to threading models 2 - 4
::For example, a widget that processes an UnitEnteredLOS event cannot safely make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this type of issue. Batch management is expensive, making it very difficult to solve this problem engine side.

[[Category:Lua]]

Asynchronous Simulation

2013-03-22T23:02:02Z

Zerver: /* Asynchronous Simulation */

== Asynchronous Simulation ==
Asynchronous simulation (ASIM) allows the game physics simulation to run alongside the 3D graphics rendering on a dual core CPU or better. This gives higher performance, and allows the engine to maintain a high rendering frame rate (FPS) at all times even in big battles.

Spring <code>disables ASIM by default</code>, unless a game has been specifically designed to support it. The reason is that ASIM gives rise to Lua related side effects that can be a bit hard to understand, especially for a game designer who has little experience with threaded programming.

== Steps required to support ASIM in your game ==
:'''1.''' Choose a Lua Threading Model > 2 below
:'''2.''' Rewrite your lua code to conform with the rules imposed by that threading model
:'''3.''' Learn about the side effects of the model chosen and tweak your code to work around it

== Lua Threading Models==
These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better. A game that specifies <code>luaThreadingModel > 2</code> will be considered asynchronous simulation (ASIM) compatible, and will have the <code>simulation thread enabled by default.</code>

:'''<code>0</code>. No MT, single threaded'''
::For reference only, this mode should never be used in practice

:'''<code>1</code>. Single state'''
::This mode has a single Lua environment for everything. It will cause a significant slowdown because simulation and rendering threads block each other trying to access the shared Lua environment. Especially problematic is Lua rendering; being inherently time consuming (looping through large amounts of units etc.) it will force the simulation thread to wait. This gives rise to the classic phenomenon of having incredibly high FPS but still lagging behind (high ping) since simulation cannot keep up with the normal pace.

:'''<code>2</code>. Single state, batching of unsynced events <code>(default mode)</code>'''
::This mode is considerably better than mode(1) since it has a separate Lua environment for LuaUI.
::All simulation events sent to LuaUI are also batched/delayed to reduce the need for the threads to block each other. For instance, if simulation triggers UnitMoved(), the event will not reach LuaUI right away, but is put in a batch and handled as soon as possible by the rendering thread. The batching system is managed, i.e. if the unit that triggered UnitMoved is about to be deleted (and thus invalidated) the batch is forcefully run before deletion occurs. Because the forced batch run is performed by the simulation thread, locking is required and this can degrade simulation performance for the same reasons as in mode(1).
::The other means of unsynced communication, SendToUnsynced and Script.LuaUI.XXX() are also batched and managed to make sure any object ID or such sent are still valid once the message arrives. Note: Script.LuaUI.XXX() does because of the batching NOT have a return value.
::This mode unfortunately suffers the same problems as mode(1) for rendering gadgets, since simulation events must be sent to the gadgets directly (without batching) in order not to desync the game.
::With this mode, it is illegal to invoke LuaUI from another Lua environment (LuaGaia or LuaRules). This can happen depending on what features (call-ins) the game implements, and what widgets the user has activated. If such an attempt to invoke LuaUI is detected, it will be skipped to prevent a deadlock, and a warning will also be printed in the console. Unfortunately there is no other solution than to stop using the call-in that throws the error, or to use a higher threading model.

:'''<code>3</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via EXPORT table and SendToUnsynced'''
::Same as mode(2), but the gadgets have separate Lua environments depending on whether the simulation or rendering thread is invoking it. This alleviates the negative performance impact for rendering gadgets, but makes it impossible to directly share synced gadget data to the unsynced part via _G --> SYNCED. To work around this limitation, this mode introduces _G.EXPORT that is automatically copied to SYNCED.EXPORT. Only small amounts of data should be stored in the EXPORT table, because the copying is performed very frequently. Cyclical and/or very deeply nested tables are not allowed. Larger data can be stored temporarily, e.g.
::_G.EXPORT.myhugetable = huge_table
::SendToUnsynced("huge_table_available")
::_G.EXPORT.myhugetable = nil

:'''<code>4</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via SendToUnsynced only'''
::Same as mode(3) but with the EXPORT table disabled to increase the performance further. You don't need EXPORT, SendToUnsynced alone is sufficient.

:'''<code>5</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''via SendToUnsynced only'''
::Same as mode(4), but adds separate Lua environments for LuaUI depending on whether the simulation or rendering thread is invoking it. With dual LuaUI states, batching is no longer needed and therefore disabled. This makes it even faster, since batching overhead is eliminated and forced batch runs (see mode(2)) are not needed. However, this mode adds significant complexity for the programmer, since essentially two instances of the same widget are run, and only the calling thread determines which one is invoked. As a rule of thumb, all simulation events (GameFrame etc.) are invoked by the simulation thread. All UI and rendering events and Update() are invoked by the rendering thread. So, if a variable is modified in GameFrame(), that change cannot be seen in Update(). The widget must instead use SendToUnsynced to communicate any data from the simulation widget instance to the rendering widget instance. Design wise it may be suitable to write the widget similarly to a gadget, with clearly separated "synced" and "unsynced" parts, each with their own variables, functions and call-ins.

:'''<code>6</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''is unmanaged and via SendToUnsynced only'''
::Same as mode(5) but the SendToUnsynced and Script.LuaUI.XXX() communication is unmanaged. The Lua coder must manually check if object references sent are still valid when the message arrives.

== Common side effects ==
:'''1. Out-of-order execution''', applies to all threading models
::All rendering call-ins (Draw*, Update, Mouse/Keyboard) must be designed so that they work correctly even if objects are deleted (and possibly replaced by another object with same ID) in between the rendering call-ins. This means rendering code that stores lists of e.g. units in global variables must update these according to UnitCreated/UnitDestroyed events or re-check the units for validity before use. Keep in mind that if an object has been replaced, the operation that you intended to perform may no longer be valid for the new object.

:'''2. Performance hit for rendering call-ins in gadgets''', applies to threading models < 3
::Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget by calling Script.LuaUI.XXX(), but the value returned from this call is undefined if ASIM is enabled. Similarly, the result obtained when checking for the existence of a Script.LuaUI.XXX function can be unpredictable, instead the widget may send a LuaRules message to indicate that the function now exists or has ceased to exist. If the LUA-SYNC-CPU indicator appears in the upper right part of the window it usually indicates a performance problem

:'''3. Batching glitches''', applies to threading models 2 - 4
::For example, a widget that processes an UnitEnteredLOS event cannot safely make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this type of issue. Batch management is expensive, making it very difficult to solve this problem engine side.

[[Category:Lua]]

Asynchronous Simulation

2013-03-22T23:01:10Z

Zerver: /* Asynchronous Simulation */

== Asynchronous Simulation ==
Asynchronous simulation (ASIM) allows the game physics simulation to run alongside the 3D graphics rendering on a dual core CPU or better. This gives higher performance, and allows the engine to maintain a high rendering frame rate (FPS) at all times even in big battles.

Spring <code>disables ASIM by default</code>, unless a game has been specifically designed to support it. The reason is that ASIM gives rise to numerous Lua related side effects that can be a bit hard to understand, especially for a game designer who has little experience with threaded programming.

== Steps required to support ASIM in your game ==
:'''1.''' Choose a Lua Threading Model > 2 below
:'''2.''' Rewrite your lua code to conform with the rules imposed by that threading model
:'''3.''' Learn about the side effects of the model chosen and tweak your code to work around it

== Lua Threading Models==
These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better. A game that specifies <code>luaThreadingModel > 2</code> will be considered asynchronous simulation (ASIM) compatible, and will have the <code>simulation thread enabled by default.</code>

:'''<code>0</code>. No MT, single threaded'''
::For reference only, this mode should never be used in practice

:'''<code>1</code>. Single state'''
::This mode has a single Lua environment for everything. It will cause a significant slowdown because simulation and rendering threads block each other trying to access the shared Lua environment. Especially problematic is Lua rendering; being inherently time consuming (looping through large amounts of units etc.) it will force the simulation thread to wait. This gives rise to the classic phenomenon of having incredibly high FPS but still lagging behind (high ping) since simulation cannot keep up with the normal pace.

:'''<code>2</code>. Single state, batching of unsynced events <code>(default mode)</code>'''
::This mode is considerably better than mode(1) since it has a separate Lua environment for LuaUI.
::All simulation events sent to LuaUI are also batched/delayed to reduce the need for the threads to block each other. For instance, if simulation triggers UnitMoved(), the event will not reach LuaUI right away, but is put in a batch and handled as soon as possible by the rendering thread. The batching system is managed, i.e. if the unit that triggered UnitMoved is about to be deleted (and thus invalidated) the batch is forcefully run before deletion occurs. Because the forced batch run is performed by the simulation thread, locking is required and this can degrade simulation performance for the same reasons as in mode(1).
::The other means of unsynced communication, SendToUnsynced and Script.LuaUI.XXX() are also batched and managed to make sure any object ID or such sent are still valid once the message arrives. Note: Script.LuaUI.XXX() does because of the batching NOT have a return value.
::This mode unfortunately suffers the same problems as mode(1) for rendering gadgets, since simulation events must be sent to the gadgets directly (without batching) in order not to desync the game.
::With this mode, it is illegal to invoke LuaUI from another Lua environment (LuaGaia or LuaRules). This can happen depending on what features (call-ins) the game implements, and what widgets the user has activated. If such an attempt to invoke LuaUI is detected, it will be skipped to prevent a deadlock, and a warning will also be printed in the console. Unfortunately there is no other solution than to stop using the call-in that throws the error, or to use a higher threading model.

:'''<code>3</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via EXPORT table and SendToUnsynced'''
::Same as mode(2), but the gadgets have separate Lua environments depending on whether the simulation or rendering thread is invoking it. This alleviates the negative performance impact for rendering gadgets, but makes it impossible to directly share synced gadget data to the unsynced part via _G --> SYNCED. To work around this limitation, this mode introduces _G.EXPORT that is automatically copied to SYNCED.EXPORT. Only small amounts of data should be stored in the EXPORT table, because the copying is performed very frequently. Cyclical and/or very deeply nested tables are not allowed. Larger data can be stored temporarily, e.g.
::_G.EXPORT.myhugetable = huge_table
::SendToUnsynced("huge_table_available")
::_G.EXPORT.myhugetable = nil

:'''<code>4</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via SendToUnsynced only'''
::Same as mode(3) but with the EXPORT table disabled to increase the performance further. You don't need EXPORT, SendToUnsynced alone is sufficient.

:'''<code>5</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''via SendToUnsynced only'''
::Same as mode(4), but adds separate Lua environments for LuaUI depending on whether the simulation or rendering thread is invoking it. With dual LuaUI states, batching is no longer needed and therefore disabled. This makes it even faster, since batching overhead is eliminated and forced batch runs (see mode(2)) are not needed. However, this mode adds significant complexity for the programmer, since essentially two instances of the same widget are run, and only the calling thread determines which one is invoked. As a rule of thumb, all simulation events (GameFrame etc.) are invoked by the simulation thread. All UI and rendering events and Update() are invoked by the rendering thread. So, if a variable is modified in GameFrame(), that change cannot be seen in Update(). The widget must instead use SendToUnsynced to communicate any data from the simulation widget instance to the rendering widget instance. Design wise it may be suitable to write the widget similarly to a gadget, with clearly separated "synced" and "unsynced" parts, each with their own variables, functions and call-ins.

:'''<code>6</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''is unmanaged and via SendToUnsynced only'''
::Same as mode(5) but the SendToUnsynced and Script.LuaUI.XXX() communication is unmanaged. The Lua coder must manually check if object references sent are still valid when the message arrives.

== Common side effects ==
:'''1. Out-of-order execution''', applies to all threading models
::All rendering call-ins (Draw*, Update, Mouse/Keyboard) must be designed so that they work correctly even if objects are deleted (and possibly replaced by another object with same ID) in between the rendering call-ins. This means rendering code that stores lists of e.g. units in global variables must update these according to UnitCreated/UnitDestroyed events or re-check the units for validity before use. Keep in mind that if an object has been replaced, the operation that you intended to perform may no longer be valid for the new object.

:'''2. Performance hit for rendering call-ins in gadgets''', applies to threading models < 3
::Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget by calling Script.LuaUI.XXX(), but the value returned from this call is undefined if ASIM is enabled. Similarly, the result obtained when checking for the existence of a Script.LuaUI.XXX function can be unpredictable, instead the widget may send a LuaRules message to indicate that the function now exists or has ceased to exist. If the LUA-SYNC-CPU indicator appears in the upper right part of the window it usually indicates a performance problem

:'''3. Batching glitches''', applies to threading models 2 - 4
::For example, a widget that processes an UnitEnteredLOS event cannot safely make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this type of issue. Batch management is expensive, making it very difficult to solve this problem engine side.

[[Category:Lua]]

Lua:Main

2013-03-22T16:48:47Z

Zerver: /* Other useful information */ link update

[[Engine_Development|Development]] < {{FULLPAGENAME}}

=Lua FAQ=
[[Lua_Beginners_FAQ]] 
[http://springrts.com/phpbb/viewtopic.php?f=23&t=15596 Forum topic with some basic information about gadgets] 
[http://springrts.com/phpbb/viewtopic.php?f=23&t=16223 Forum topic with a manual on Spring lua scripting] 
[http://answers.springlobby.info/ Q&A Site for Spring Developement]

=Interfaces {{HeaderNotice|(last update: 0.82rc)}}=
[[:Category:Lua]] (shows which interfaces are loaded by LuaUI,LuaRules,etc.) 
{{LuaInterfaces}}

=Tutorials=
* [[LuaTutorials::InterCommunications]] (i.e. synced <-> unsynced communications)

=Other useful information=
* [[LuaCallinReturn]]
* [[Lua_Performance | Lua performance tips]]
* [[Asynchronous_Simulation | Asynchronous Simulation and Lua]]
* [http://spring.clan-sy.com/wiki/COB_Constants#Custom_Variables COB Custom Variables]
* [http://springrts.com/phpbb/viewtopic.php?f=12&t=19560 Font Drawing System]
* [[UI_commands]]
* [[Animation-LuaScripting | Unit animation scripting with Lua]]
* [[LUA ComonPitfalls]]
* [[LuaSocket]]

=Official Lua documentation=
[http://www.lua.org/pil/ 'Programming in Lua' book online] 
[http://www.lua.org/manual/5.1/ Lua 5.1 Reference manual] 
[http://lua-users.org/wiki/TutorialDirectory Lua tutorials]
[[Category: Lua]]

=Widget Database=
[[WidgetDatabaseFAQ]] 
[http://widgets.springrts.de/ Web-Interface]

Asynchronous Simulation

2013-03-22T16:21:17Z

Zerver: /* Asynchronous Simulation */

== Asynchronous Simulation ==
Spring disables asynchronous simulation (ASIM) by default, unless a game has been specifically designed to support it. The reason is that ASIM gives rise to numerous Lua related side effects that can be a bit hard to understand, especially for a game designer who has little experience with threaded programming.

== Steps required to support ASIM in your game ==
:'''1.''' Choose a Lua Threading Model > 2 below
:'''2.''' Rewrite your lua code to conform with the rules imposed by that threading model
:'''3.''' Learn about the side effects of the model chosen and tweak your code to work around it

== Lua Threading Models==
These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better. A game that specifies <code>luaThreadingModel > 2</code> will be considered asynchronous simulation (ASIM) compatible, and will have the <code>simulation thread enabled by default.</code>

:'''<code>0</code>. No MT, single threaded'''
::For reference only, this mode should never be used in practice

:'''<code>1</code>. Single state'''
::This mode has a single Lua environment for everything. It will cause a significant slowdown because simulation and rendering threads block each other trying to access the shared Lua environment. Especially problematic is Lua rendering; being inherently time consuming (looping through large amounts of units etc.) it will force the simulation thread to wait. This gives rise to the classic phenomenon of having incredibly high FPS but still lagging behind (high ping) since simulation cannot keep up with the normal pace.

:'''<code>2</code>. Single state, batching of unsynced events <code>(default mode)</code>'''
::This mode is considerably better than mode(1) since it has a separate Lua environment for LuaUI.
::All simulation events sent to LuaUI are also batched/delayed to reduce the need for the threads to block each other. For instance, if simulation triggers UnitMoved(), the event will not reach LuaUI right away, but is put in a batch and handled as soon as possible by the rendering thread. The batching system is managed, i.e. if the unit that triggered UnitMoved is about to be deleted (and thus invalidated) the batch is forcefully run before deletion occurs. Because the forced batch run is performed by the simulation thread, locking is required and this can degrade simulation performance for the same reasons as in mode(1).
::The other means of unsynced communication, SendToUnsynced and Script.LuaUI.XXX() are also batched and managed to make sure any object ID or such sent are still valid once the message arrives. Note: Script.LuaUI.XXX() does because of the batching NOT have a return value.
::This mode unfortunately suffers the same problems as mode(1) for rendering gadgets, since simulation events must be sent to the gadgets directly (without batching) in order not to desync the game.
::With this mode, it is illegal to invoke LuaUI from another Lua environment (LuaGaia or LuaRules). This can happen depending on what features (call-ins) the game implements, and what widgets the user has activated. If such an attempt to invoke LuaUI is detected, it will be skipped to prevent a deadlock, and a warning will also be printed in the console. Unfortunately there is no other solution than to stop using the call-in that throws the error, or to use a higher threading model.

:'''<code>3</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via EXPORT table and SendToUnsynced'''
::Same as mode(2), but the gadgets have separate Lua environments depending on whether the simulation or rendering thread is invoking it. This alleviates the negative performance impact for rendering gadgets, but makes it impossible to directly share synced gadget data to the unsynced part via _G --> SYNCED. To work around this limitation, this mode introduces _G.EXPORT that is automatically copied to SYNCED.EXPORT. Only small amounts of data should be stored in the EXPORT table, because the copying is performed very frequently. Cyclical and/or very deeply nested tables are not allowed. Larger data can be stored temporarily, e.g.
::_G.EXPORT.myhugetable = huge_table
::SendToUnsynced("huge_table_available")
::_G.EXPORT.myhugetable = nil

:'''<code>4</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via SendToUnsynced only'''
::Same as mode(3) but with the EXPORT table disabled to increase the performance further. You don't need EXPORT, SendToUnsynced alone is sufficient.

:'''<code>5</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''via SendToUnsynced only'''
::Same as mode(4), but adds separate Lua environments for LuaUI depending on whether the simulation or rendering thread is invoking it. With dual LuaUI states, batching is no longer needed and therefore disabled. This makes it even faster, since batching overhead is eliminated and forced batch runs (see mode(2)) are not needed. However, this mode adds significant complexity for the programmer, since essentially two instances of the same widget are run, and only the calling thread determines which one is invoked. As a rule of thumb, all simulation events (GameFrame etc.) are invoked by the simulation thread. All UI and rendering events and Update() are invoked by the rendering thread. So, if a variable is modified in GameFrame(), that change cannot be seen in Update(). The widget must instead use SendToUnsynced to communicate any data from the simulation widget instance to the rendering widget instance. Design wise it may be suitable to write the widget similarly to a gadget, with clearly separated "synced" and "unsynced" parts, each with their own variables, functions and call-ins.

:'''<code>6</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''is unmanaged and via SendToUnsynced only'''
::Same as mode(5) but the SendToUnsynced and Script.LuaUI.XXX() communication is unmanaged. The Lua coder must manually check if object references sent are still valid when the message arrives.

== Common side effects ==
:'''1. Out-of-order execution''', applies to all threading models
::All rendering call-ins (Draw*, Update, Mouse/Keyboard) must be designed so that they work correctly even if objects are deleted (and possibly replaced by another object with same ID) in between the rendering call-ins. This means rendering code that stores lists of e.g. units in global variables must update these according to UnitCreated/UnitDestroyed events or re-check the units for validity before use. Keep in mind that if an object has been replaced, the operation that you intended to perform may no longer be valid for the new object.

:'''2. Performance hit for rendering call-ins in gadgets''', applies to threading models < 3
::Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget by calling Script.LuaUI.XXX(), but the value returned from this call is undefined if ASIM is enabled. Similarly, the result obtained when checking for the existence of a Script.LuaUI.XXX function can be unpredictable, instead the widget may send a LuaRules message to indicate that the function now exists or has ceased to exist. If the LUA-SYNC-CPU indicator appears in the upper right part of the window it usually indicates a performance problem

:'''3. Batching glitches''', applies to threading models 2 - 4
::For example, a widget that processes an UnitEnteredLOS event cannot safely make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this type of issue. Batch management is expensive, making it very difficult to solve this problem engine side.

[[Category:Lua]]

Asynchronous Simulation

2013-03-22T16:20:18Z

Zerver: /* Lua Compatibility for Asynchronous Simulation */

== Asynchronous Simulation ==
Spring disables asynchronous simulation (ASIM) by default, unless a game has been specifically designed to support it. The reason is that ASIM gives rise to numerous side effects that can be a bit hard to understand, especially for a game designer who has little experience with threaded programming.

== Steps required to support ASIM in your game ==
:'''1.''' Choose a Lua Threading Model > 2 below
:'''2.''' Rewrite your lua code to conform with the rules imposed by that threading model
:'''3.''' Learn about the side effects of the model chosen and tweak your code to work around it

== Lua Threading Models==
These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better. A game that specifies <code>luaThreadingModel > 2</code> will be considered asynchronous simulation (ASIM) compatible, and will have the <code>simulation thread enabled by default.</code>

:'''<code>0</code>. No MT, single threaded'''
::For reference only, this mode should never be used in practice

:'''<code>1</code>. Single state'''
::This mode has a single Lua environment for everything. It will cause a significant slowdown because simulation and rendering threads block each other trying to access the shared Lua environment. Especially problematic is Lua rendering; being inherently time consuming (looping through large amounts of units etc.) it will force the simulation thread to wait. This gives rise to the classic phenomenon of having incredibly high FPS but still lagging behind (high ping) since simulation cannot keep up with the normal pace.

:'''<code>2</code>. Single state, batching of unsynced events <code>(default mode)</code>'''
::This mode is considerably better than mode(1) since it has a separate Lua environment for LuaUI.
::All simulation events sent to LuaUI are also batched/delayed to reduce the need for the threads to block each other. For instance, if simulation triggers UnitMoved(), the event will not reach LuaUI right away, but is put in a batch and handled as soon as possible by the rendering thread. The batching system is managed, i.e. if the unit that triggered UnitMoved is about to be deleted (and thus invalidated) the batch is forcefully run before deletion occurs. Because the forced batch run is performed by the simulation thread, locking is required and this can degrade simulation performance for the same reasons as in mode(1).
::The other means of unsynced communication, SendToUnsynced and Script.LuaUI.XXX() are also batched and managed to make sure any object ID or such sent are still valid once the message arrives. Note: Script.LuaUI.XXX() does because of the batching NOT have a return value.
::This mode unfortunately suffers the same problems as mode(1) for rendering gadgets, since simulation events must be sent to the gadgets directly (without batching) in order not to desync the game.
::With this mode, it is illegal to invoke LuaUI from another Lua environment (LuaGaia or LuaRules). This can happen depending on what features (call-ins) the game implements, and what widgets the user has activated. If such an attempt to invoke LuaUI is detected, it will be skipped to prevent a deadlock, and a warning will also be printed in the console. Unfortunately there is no other solution than to stop using the call-in that throws the error, or to use a higher threading model.

:'''<code>3</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via EXPORT table and SendToUnsynced'''
::Same as mode(2), but the gadgets have separate Lua environments depending on whether the simulation or rendering thread is invoking it. This alleviates the negative performance impact for rendering gadgets, but makes it impossible to directly share synced gadget data to the unsynced part via _G --> SYNCED. To work around this limitation, this mode introduces _G.EXPORT that is automatically copied to SYNCED.EXPORT. Only small amounts of data should be stored in the EXPORT table, because the copying is performed very frequently. Cyclical and/or very deeply nested tables are not allowed. Larger data can be stored temporarily, e.g.
::_G.EXPORT.myhugetable = huge_table
::SendToUnsynced("huge_table_available")
::_G.EXPORT.myhugetable = nil

:'''<code>4</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via SendToUnsynced only'''
::Same as mode(3) but with the EXPORT table disabled to increase the performance further. You don't need EXPORT, SendToUnsynced alone is sufficient.

:'''<code>5</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''via SendToUnsynced only'''
::Same as mode(4), but adds separate Lua environments for LuaUI depending on whether the simulation or rendering thread is invoking it. With dual LuaUI states, batching is no longer needed and therefore disabled. This makes it even faster, since batching overhead is eliminated and forced batch runs (see mode(2)) are not needed. However, this mode adds significant complexity for the programmer, since essentially two instances of the same widget are run, and only the calling thread determines which one is invoked. As a rule of thumb, all simulation events (GameFrame etc.) are invoked by the simulation thread. All UI and rendering events and Update() are invoked by the rendering thread. So, if a variable is modified in GameFrame(), that change cannot be seen in Update(). The widget must instead use SendToUnsynced to communicate any data from the simulation widget instance to the rendering widget instance. Design wise it may be suitable to write the widget similarly to a gadget, with clearly separated "synced" and "unsynced" parts, each with their own variables, functions and call-ins.

:'''<code>6</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''is unmanaged and via SendToUnsynced only'''
::Same as mode(5) but the SendToUnsynced and Script.LuaUI.XXX() communication is unmanaged. The Lua coder must manually check if object references sent are still valid when the message arrives.

== Common side effects ==
:'''1. Out-of-order execution''', applies to all threading models
::All rendering call-ins (Draw*, Update, Mouse/Keyboard) must be designed so that they work correctly even if objects are deleted (and possibly replaced by another object with same ID) in between the rendering call-ins. This means rendering code that stores lists of e.g. units in global variables must update these according to UnitCreated/UnitDestroyed events or re-check the units for validity before use. Keep in mind that if an object has been replaced, the operation that you intended to perform may no longer be valid for the new object.

:'''2. Performance hit for rendering call-ins in gadgets''', applies to threading models < 3
::Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget by calling Script.LuaUI.XXX(), but the value returned from this call is undefined if ASIM is enabled. Similarly, the result obtained when checking for the existence of a Script.LuaUI.XXX function can be unpredictable, instead the widget may send a LuaRules message to indicate that the function now exists or has ceased to exist. If the LUA-SYNC-CPU indicator appears in the upper right part of the window it usually indicates a performance problem

:'''3. Batching glitches''', applies to threading models 2 - 4
::For example, a widget that processes an UnitEnteredLOS event cannot safely make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this type of issue. Batch management is expensive, making it very difficult to solve this problem engine side.

[[Category:Lua]]

Spring Multithreaded Lua

2013-03-22T16:19:19Z

Zerver: Zerver moved page Spring Multithreaded Lua to Asynchronous Simulation: better name

#REDIRECT [[Asynchronous Simulation]]

Asynchronous Simulation

2013-03-22T16:19:19Z

Zerver: Zerver moved page Spring Multithreaded Lua to Asynchronous Simulation: better name

== Lua Compatibility for Asynchronous Simulation ==
Spring disables asynchronous simulation (ASIM) by default, unless a game has been specifically designed to support it. The reason is that ASIM gives rise to numerous side effects that can be a bit hard to understand, especially for a game designer who has little experience with threaded programming.

== Steps required to support ASIM in your game ==
:'''1.''' Choose a Lua Threading Model > 2 below
:'''2.''' Rewrite your lua code to conform with the rules imposed by that threading model
:'''3.''' Learn about the side effects of the model chosen and tweak your code to work around it

== Lua Threading Models==
These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better. A game that specifies <code>luaThreadingModel > 2</code> will be considered asynchronous simulation (ASIM) compatible, and will have the <code>simulation thread enabled by default.</code>

:'''<code>0</code>. No MT, single threaded'''
::For reference only, this mode should never be used in practice

:'''<code>1</code>. Single state'''
::This mode has a single Lua environment for everything. It will cause a significant slowdown because simulation and rendering threads block each other trying to access the shared Lua environment. Especially problematic is Lua rendering; being inherently time consuming (looping through large amounts of units etc.) it will force the simulation thread to wait. This gives rise to the classic phenomenon of having incredibly high FPS but still lagging behind (high ping) since simulation cannot keep up with the normal pace.

:'''<code>2</code>. Single state, batching of unsynced events <code>(default mode)</code>'''
::This mode is considerably better than mode(1) since it has a separate Lua environment for LuaUI.
::All simulation events sent to LuaUI are also batched/delayed to reduce the need for the threads to block each other. For instance, if simulation triggers UnitMoved(), the event will not reach LuaUI right away, but is put in a batch and handled as soon as possible by the rendering thread. The batching system is managed, i.e. if the unit that triggered UnitMoved is about to be deleted (and thus invalidated) the batch is forcefully run before deletion occurs. Because the forced batch run is performed by the simulation thread, locking is required and this can degrade simulation performance for the same reasons as in mode(1).
::The other means of unsynced communication, SendToUnsynced and Script.LuaUI.XXX() are also batched and managed to make sure any object ID or such sent are still valid once the message arrives. Note: Script.LuaUI.XXX() does because of the batching NOT have a return value.
::This mode unfortunately suffers the same problems as mode(1) for rendering gadgets, since simulation events must be sent to the gadgets directly (without batching) in order not to desync the game.
::With this mode, it is illegal to invoke LuaUI from another Lua environment (LuaGaia or LuaRules). This can happen depending on what features (call-ins) the game implements, and what widgets the user has activated. If such an attempt to invoke LuaUI is detected, it will be skipped to prevent a deadlock, and a warning will also be printed in the console. Unfortunately there is no other solution than to stop using the call-in that throws the error, or to use a higher threading model.

:'''<code>3</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via EXPORT table and SendToUnsynced'''
::Same as mode(2), but the gadgets have separate Lua environments depending on whether the simulation or rendering thread is invoking it. This alleviates the negative performance impact for rendering gadgets, but makes it impossible to directly share synced gadget data to the unsynced part via _G --> SYNCED. To work around this limitation, this mode introduces _G.EXPORT that is automatically copied to SYNCED.EXPORT. Only small amounts of data should be stored in the EXPORT table, because the copying is performed very frequently. Cyclical and/or very deeply nested tables are not allowed. Larger data can be stored temporarily, e.g.
::_G.EXPORT.myhugetable = huge_table
::SendToUnsynced("huge_table_available")
::_G.EXPORT.myhugetable = nil

:'''<code>4</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via SendToUnsynced only'''
::Same as mode(3) but with the EXPORT table disabled to increase the performance further. You don't need EXPORT, SendToUnsynced alone is sufficient.

:'''<code>5</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''via SendToUnsynced only'''
::Same as mode(4), but adds separate Lua environments for LuaUI depending on whether the simulation or rendering thread is invoking it. With dual LuaUI states, batching is no longer needed and therefore disabled. This makes it even faster, since batching overhead is eliminated and forced batch runs (see mode(2)) are not needed. However, this mode adds significant complexity for the programmer, since essentially two instances of the same widget are run, and only the calling thread determines which one is invoked. As a rule of thumb, all simulation events (GameFrame etc.) are invoked by the simulation thread. All UI and rendering events and Update() are invoked by the rendering thread. So, if a variable is modified in GameFrame(), that change cannot be seen in Update(). The widget must instead use SendToUnsynced to communicate any data from the simulation widget instance to the rendering widget instance. Design wise it may be suitable to write the widget similarly to a gadget, with clearly separated "synced" and "unsynced" parts, each with their own variables, functions and call-ins.

:'''<code>6</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''is unmanaged and via SendToUnsynced only'''
::Same as mode(5) but the SendToUnsynced and Script.LuaUI.XXX() communication is unmanaged. The Lua coder must manually check if object references sent are still valid when the message arrives.

== Common side effects ==
:'''1. Out-of-order execution''', applies to all threading models
::All rendering call-ins (Draw*, Update, Mouse/Keyboard) must be designed so that they work correctly even if objects are deleted (and possibly replaced by another object with same ID) in between the rendering call-ins. This means rendering code that stores lists of e.g. units in global variables must update these according to UnitCreated/UnitDestroyed events or re-check the units for validity before use. Keep in mind that if an object has been replaced, the operation that you intended to perform may no longer be valid for the new object.

:'''2. Performance hit for rendering call-ins in gadgets''', applies to threading models < 3
::Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget by calling Script.LuaUI.XXX(), but the value returned from this call is undefined if ASIM is enabled. Similarly, the result obtained when checking for the existence of a Script.LuaUI.XXX function can be unpredictable, instead the widget may send a LuaRules message to indicate that the function now exists or has ceased to exist. If the LUA-SYNC-CPU indicator appears in the upper right part of the window it usually indicates a performance problem

:'''3. Batching glitches''', applies to threading models 2 - 4
::For example, a widget that processes an UnitEnteredLOS event cannot safely make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this type of issue. Batch management is expensive, making it very difficult to solve this problem engine side.

[[Category:Lua]]

Asynchronous Simulation

2013-03-22T16:13:11Z

Zerver: /* Lua Threading Models */

Asynchronous Simulation

2013-03-22T02:22:07Z

Zerver: /* Common side effects */

== Lua Compatibility for Asynchronous Simulation ==
Spring disables asynchronous simulation (ASIM) by default, unless a game has been specifically designed to support it. The reason is that ASIM gives rise to numerous side effects that can be a bit hard to understand, especially for a game designer who has little experience with threaded programming.

== Steps required to support ASIM in your game ==
:'''1.''' Choose a Lua Threading Model > 2 below
:'''2.''' Rewrite your lua code to conform with the rules imposed by that threading model
:'''3.''' Learn about the side effects of the model chosen and tweak your code to work around it

== Lua Threading Models==
These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better. A game that specifies <code>luaThreadingModel > 2</code> will be considered asynchronous simulation (ASIM) compatible, and will have the <code>simulation thread enabled by default.</code>

:'''<code>0</code>. No MT, single threaded'''

:'''<code>1</code>. Single state'''
::This mode has a single Lua environment for everything. It will cause a significant slowdown because simulation and rendering threads block each other trying to access the shared Lua environment. Especially problematic is Lua rendering; being inherently time consuming (looping through large amounts of units etc.) it will force the simulation thread to wait. This gives rise to the classic phenomenon of having incredibly high FPS but still lagging behind (high ping) since simulation cannot keep up with the normal pace.

:'''<code>2</code>. Single state, batching of unsynced events <code>(default mode)</code>'''
::This mode is considerably better than mode(1) since it has a separate Lua environment for LuaUI.
::All simulation events sent to LuaUI are also batched/delayed to reduce the need for the threads to block each other. For instance, if simulation triggers UnitMoved(), the event will not reach LuaUI right away, but is put in a batch and handled as soon as possible by the rendering thread. The batching system is managed, i.e. if the unit that triggered UnitMoved is about to be deleted (and thus invalidated) the batch is forcefully run before deletion occurs. Because the forced batch run is performed by the simulation thread, locking is required and this can degrade simulation performance for the same reasons as in mode(1).
::The other means of unsynced communication, SendToUnsynced and Script.LuaUI.XXX() are also batched and managed to make sure any object ID or such sent are still valid once the message arrives. Note: Script.LuaUI.XXX() does because of the batching NOT have a return value.
::This mode unfortunately suffers the same problems as mode(1) for rendering gadgets, since simulation events must be sent to the gadgets directly (without batching) in order not to desync the game.
::With this mode, it is illegal to invoke LuaUI from another Lua environment (LuaGaia or LuaRules). This can happen depending on what features (call-ins) the game implements, and what widgets the user has activated. If such an attempt to invoke LuaUI is detected, it will be skipped to prevent a deadlock, and a warning will also be printed in the console. Unfortunately there is no other solution than to stop using the call-in that throws the error, or to use a higher threading model.

:'''<code>3</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via EXPORT table and SendToUnsynced'''
::Same as mode(2), but the gadgets have separate Lua environments depending on whether the simulation or rendering thread is invoking it. This alleviates the negative performance impact for rendering gadgets, but makes it impossible to directly share synced gadget data to the unsynced part via _G --> SYNCED. To work around this limitation, this mode introduces _G.EXPORT that is automatically copied to SYNCED.EXPORT. Only small amounts of data should be stored in the EXPORT table, because the copying is performed very frequently. Cyclical and/or very deeply nested tables are not allowed. Larger data can be stored temporarily, e.g.
::_G.EXPORT.myhugetable = huge_table
::SendToUnsynced("huge_table_available")
::_G.EXPORT.myhugetable = nil

:'''<code>4</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via SendToUnsynced only'''
::Same as mode(3) but with the EXPORT table disabled to increase the performance further. You don't need EXPORT, SendToUnsynced alone is sufficient.

:'''<code>5</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''via SendToUnsynced only'''
::Same as mode(4), but adds separate Lua environments for LuaUI depending on whether the simulation or rendering thread is invoking it. With dual LuaUI states, batching is no longer needed and therefore disabled. This makes it even faster, since batching overhead is eliminated and forced batch runs (see mode(2)) are not needed. However, this mode adds significant complexity for the programmer, since essentially two instances of the same widget are run, and only the calling thread determines which one is invoked. As a rule of thumb, all simulation events (GameFrame etc.) are invoked by the simulation thread. All UI and rendering events and Update() are invoked by the rendering thread. So, if a variable is modified in GameFrame(), that change cannot be seen in Update(). The widget must instead use SendToUnsynced to communicate any data from the simulation widget instance to the rendering widget instance. Design wise it may be suitable to write the widget similarly to a gadget, with clearly separated "synced" and "unsynced" parts, each with their own variables, functions and call-ins.

:'''<code>6</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''is unmanaged and via SendToUnsynced only'''
::Same as mode(5) but the SendToUnsynced and Script.LuaUI.XXX() communication is unmanaged. The Lua coder must manually check if object references sent are still valid when the message arrives.

== Common side effects ==
:'''1. Out-of-order execution''', applies to all threading models
::All rendering call-ins (Draw*, Update, Mouse/Keyboard) must be designed so that they work correctly even if objects are deleted (and possibly replaced by another object with same ID) in between the rendering call-ins. This means rendering code that stores lists of e.g. units in global variables must update these according to UnitCreated/UnitDestroyed events or re-check the units for validity before use. Keep in mind that if an object has been replaced, the operation that you intended to perform may no longer be valid for the new object.

:'''2. Performance hit for rendering call-ins in gadgets''', applies to threading models < 3
::Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget by calling Script.LuaUI.XXX(), but the value returned from this call is undefined if ASIM is enabled. Similarly, the result obtained when checking for the existence of a Script.LuaUI.XXX function can be unpredictable, instead the widget may send a LuaRules message to indicate that the function now exists or has ceased to exist. If the LUA-SYNC-CPU indicator appears in the upper right part of the window it usually indicates a performance problem

:'''3. Batching glitches''', applies to threading models 2 - 4
::For example, a widget that processes an UnitEnteredLOS event cannot safely make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this type of issue. Batch management is expensive, making it very difficult to solve this problem engine side.

[[Category:Lua]]

Asynchronous Simulation

2013-03-22T02:07:35Z

Zerver: /* Lua Threading Models */

== Lua Compatibility for Asynchronous Simulation ==
Spring disables asynchronous simulation (ASIM) by default, unless a game has been specifically designed to support it. The reason is that ASIM gives rise to numerous side effects that can be a bit hard to understand, especially for a game designer who has little experience with threaded programming.

== Steps required to support ASIM in your game ==
:'''1.''' Choose a Lua Threading Model > 2 below
:'''2.''' Rewrite your lua code to conform with the rules imposed by that threading model
:'''3.''' Learn about the side effects of the model chosen and tweak your code to work around it

== Lua Threading Models==
These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better. A game that specifies <code>luaThreadingModel > 2</code> will be considered asynchronous simulation (ASIM) compatible, and will have the <code>simulation thread enabled by default.</code>

:'''<code>0</code>. No MT, single threaded'''

:'''<code>1</code>. Single state'''
::This mode has a single Lua environment for everything. It will cause a significant slowdown because simulation and rendering threads block each other trying to access the shared Lua environment. Especially problematic is Lua rendering; being inherently time consuming (looping through large amounts of units etc.) it will force the simulation thread to wait. This gives rise to the classic phenomenon of having incredibly high FPS but still lagging behind (high ping) since simulation cannot keep up with the normal pace.

:'''<code>2</code>. Single state, batching of unsynced events <code>(default mode)</code>'''
::This mode is considerably better than mode(1) since it has a separate Lua environment for LuaUI.
::All simulation events sent to LuaUI are also batched/delayed to reduce the need for the threads to block each other. For instance, if simulation triggers UnitMoved(), the event will not reach LuaUI right away, but is put in a batch and handled as soon as possible by the rendering thread. The batching system is managed, i.e. if the unit that triggered UnitMoved is about to be deleted (and thus invalidated) the batch is forcefully run before deletion occurs. Because the forced batch run is performed by the simulation thread, locking is required and this can degrade simulation performance for the same reasons as in mode(1).
::The other means of unsynced communication, SendToUnsynced and Script.LuaUI.XXX() are also batched and managed to make sure any object ID or such sent are still valid once the message arrives. Note: Script.LuaUI.XXX() does because of the batching NOT have a return value.
::This mode unfortunately suffers the same problems as mode(1) for rendering gadgets, since simulation events must be sent to the gadgets directly (without batching) in order not to desync the game.
::With this mode, it is illegal to invoke LuaUI from another Lua environment (LuaGaia or LuaRules). This can happen depending on what features (call-ins) the game implements, and what widgets the user has activated. If such an attempt to invoke LuaUI is detected, it will be skipped to prevent a deadlock, and a warning will also be printed in the console. Unfortunately there is no other solution than to stop using the call-in that throws the error, or to use a higher threading model.

:'''<code>3</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via EXPORT table and SendToUnsynced'''
::Same as mode(2), but the gadgets have separate Lua environments depending on whether the simulation or rendering thread is invoking it. This alleviates the negative performance impact for rendering gadgets, but makes it impossible to directly share synced gadget data to the unsynced part via _G --> SYNCED. To work around this limitation, this mode introduces _G.EXPORT that is automatically copied to SYNCED.EXPORT. Only small amounts of data should be stored in the EXPORT table, because the copying is performed very frequently. Cyclical and/or very deeply nested tables are not allowed. Larger data can be stored temporarily, e.g.
::_G.EXPORT.myhugetable = huge_table
::SendToUnsynced("huge_table_available")
::_G.EXPORT.myhugetable = nil

:'''<code>4</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via SendToUnsynced only'''
::Same as mode(3) but with the EXPORT table disabled to increase the performance further. You don't need EXPORT, SendToUnsynced alone is sufficient.

:'''<code>5</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''via SendToUnsynced only'''
::Same as mode(4), but adds separate Lua environments for LuaUI depending on whether the simulation or rendering thread is invoking it. With dual LuaUI states, batching is no longer needed and therefore disabled. This makes it even faster, since batching overhead is eliminated and forced batch runs (see mode(2)) are not needed. However, this mode adds significant complexity for the programmer, since essentially two instances of the same widget are run, and only the calling thread determines which one is invoked. As a rule of thumb, all simulation events (GameFrame etc.) are invoked by the simulation thread. All UI and rendering events and Update() are invoked by the rendering thread. So, if a variable is modified in GameFrame(), that change cannot be seen in Update(). The widget must instead use SendToUnsynced to communicate any data from the simulation widget instance to the rendering widget instance. Design wise it may be suitable to write the widget similarly to a gadget, with clearly separated "synced" and "unsynced" parts, each with their own variables, functions and call-ins.

:'''<code>6</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''is unmanaged and via SendToUnsynced only'''
::Same as mode(5) but the SendToUnsynced and Script.LuaUI.XXX() communication is unmanaged. The Lua coder must manually check if object references sent are still valid when the message arrives.

== Common side effects ==
:'''1. Out-of-order execution''', applies to all threading models
::All rendering call-ins (Draw*, Update, Mouse/Keyboard) must be designed so that they work correctly even if objects are deleted (and possibly replaced by another object with same ID) in between the rendering call-ins. This means rendering code that stores lists of e.g. units in global variables must update these according to UnitCreated/UnitDestroyed events or re-check the units for validity before use. Keep in mind that if an object has been replaced, the operation that you intended to perform may no longer be valid for the new object.

:'''2. Performance hit for rendering call-ins in gadgets''', applies to threading models < 3
::Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget by calling Script.LuaUI.XXX(), but the value returned from this call is undefined in MT Spring. Similarly, the result obtained when checking for the existence of a Script.LuaUI.XXX function can be unpredictable, instead the widget may send a LuaRules message to indicate that the function now exists or has ceased to exist. If the LUA-SYNC-CPU indicator appears in the upper right part of the window it usually indicates a performance problem

:'''3. Batching glitches''', applies to threading models 2 - 4
::For example, a widget that processes an UnitEnteredLOS event cannot safely make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this type of issue. Batch management is expensive, making it very difficult to solve this problem engine side.

[[Category:Lua]]

Asynchronous Simulation

2013-03-22T02:00:45Z

Zerver: major rewrite for ASIM

== Lua Compatibility for Asynchronous Simulation ==
Spring disables asynchronous simulation (ASIM) by default, unless a game has been specifically designed to support it. The reason is that ASIM gives rise to numerous side effects that can be a bit hard to understand, especially for a game designer who has little experience with threaded programming.

== Steps required to support ASIM in your game ==
:'''1.''' Choose a Lua Threading Model > 2 below
:'''2.''' Rewrite your lua code to conform with the rules imposed by that threading model
:'''3.''' Learn about the side effects of the model chosen and tweak your code to work around it

== Lua Threading Models==
These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better with Spring MT. A game that specifies <code>luaThreadingModel > 2</code> will be considered asynchronous simulation (ASIM) compatible, and will have the <code>simulation thread enabled by default.</code>

:'''<code>0</code>. No MT, single threaded'''

:'''<code>1</code>. Single state'''
::This mode has a single Lua environment for everything. It will cause a significant slowdown because simulation and rendering threads block each other trying to access the shared Lua environment. Especially problematic is Lua rendering; being inherently time consuming (looping through large amounts of units etc.) it will force the simulation thread to wait. This gives rise to the classic phenomenon of having incredibly high FPS but still lagging behind (high ping) since simulation cannot keep up with the normal pace.

:'''<code>2</code>. Single state, batching of unsynced events <code>(default mode)</code>'''
::This mode is considerably better than mode(1) since it has a separate Lua environment for LuaUI.
::All simulation events sent to LuaUI are also batched/delayed to reduce the need for the threads to block each other. For instance, if simulation triggers UnitMoved(), the event will not reach LuaUI right away, but is put in a batch and handled as soon as possible by the rendering thread. The batching system is managed, i.e. if the unit that triggered UnitMoved is about to be deleted (and thus invalidated) the batch is forcefully run before deletion occurs. Because the forced batch run is performed by the simulation thread, locking is required and this can degrade simulation performance for the same reasons as in mode(1).
::The other means of unsynced communication, SendToUnsynced and Script.LuaUI.XXX() are also batched and managed to make sure any object ID or such sent are still valid once the message arrives. Note: Script.LuaUI.XXX() does because of the batching NOT have a return value.
::This mode unfortunately suffers the same problems as mode(1) for rendering gadgets, since simulation events must be sent to the gadgets directly (without batching) in order not to desync the game.
::With this mode, it is illegal to invoke LuaUI from another Lua environment (LuaGaia or LuaRules). This can happen depending on what features (call-ins) the game implements, and what widgets the user has activated. If such an attempt to invoke LuaUI is detected, it will be skipped to prevent a deadlock, and a warning will also be printed in the console. Unfortunately there is no other solution than to stop using the call-in that throws the error, or to use a higher threading model.

:'''<code>3</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via EXPORT table and SendToUnsynced'''
::Same as mode(2), but the gadgets have separate Lua environments depending on whether the simulation or rendering thread is invoking it. This alleviates the negative performance impact for rendering gadgets, but makes it impossible to directly share synced gadget data to the unsynced part via _G --> SYNCED. To work around this limitation, this mode introduces _G.EXPORT that is automatically copied to SYNCED.EXPORT. Only small amounts of data should be stored in the EXPORT table, because the copying is performed very frequently. Cyclical and/or very deeply nested tables are not allowed. Larger data can be stored temporarily, e.g.
::_G.EXPORT.myhugetable = huge_table
::SendToUnsynced("huge_table_available")
::_G.EXPORT.myhugetable = nil

:'''<code>4</code>. Dual states for synced, batching of unsynced events, synced/unsynced communication'''
::'''via SendToUnsynced only'''
::Same as mode(3) but with the EXPORT table disabled to increase the performance further. You don't need EXPORT, SendToUnsynced alone is sufficient.

:'''<code>5</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''via SendToUnsynced only'''
::Same as mode(4), but adds separate Lua environments for LuaUI depending on whether the simulation or rendering thread is invoking it. With dual LuaUI states, batching is no longer needed and therefore disabled. This makes it even faster, since batching overhead is eliminated and forced batch runs (see mode(2)) are not needed. However, this mode adds significant complexity for the programmer, since essentially two instances of the same widget are run, and only the calling thread determines which one is invoked. As a rule of thumb, all simulation events (GameFrame etc.) are invoked by the simulation thread. All UI and rendering events and Update() are invoked by the rendering thread. So, if a variable is modified in GameFrame(), that change cannot be seen in Update(). The widget must instead use SendToUnsynced to communicate any data from the simulation widget instance to the rendering widget instance. Design wise it may be suitable to write the widget similarly to a gadget, with clearly separated "synced" and "unsynced" parts, each with their own variables, functions and call-ins.

:'''<code>6</code>. Dual states for all, all synced/unsynced communication (widgets included)'''
::'''is unmanaged and via SendToUnsynced only'''
::Same as mode(5) but the SendToUnsynced and Script.LuaUI.XXX() communication is unmanaged. The Lua coder must manually check if object references sent are still valid when the message arrives.

== Common side effects ==
:'''1. Out-of-order execution''', applies to all threading models
::All rendering call-ins (Draw*, Update, Mouse/Keyboard) must be designed so that they work correctly even if objects are deleted (and possibly replaced by another object with same ID) in between the rendering call-ins. This means rendering code that stores lists of e.g. units in global variables must update these according to UnitCreated/UnitDestroyed events or re-check the units for validity before use. Keep in mind that if an object has been replaced, the operation that you intended to perform may no longer be valid for the new object.

:'''2. Performance hit for rendering call-ins in gadgets''', applies to threading models < 3
::Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget by calling Script.LuaUI.XXX(), but the value returned from this call is undefined in MT Spring. Similarly, the result obtained when checking for the existence of a Script.LuaUI.XXX function can be unpredictable, instead the widget may send a LuaRules message to indicate that the function now exists or has ceased to exist. If the LUA-SYNC-CPU indicator appears in the upper right part of the window it usually indicates a performance problem

:'''3. Batching glitches''', applies to threading models 2 - 4
::For example, a widget that processes an UnitEnteredLOS event cannot safely make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this type of issue. Batch management is expensive, making it very difficult to solve this problem engine side.

[[Category:Lua]]

Asynchronous Simulation

2013-03-22T00:48:58Z

Zerver: /* Lua Threading Models */

== Spring Multithreaded Lua Compatibility ==
In order to make your Lua code compatible with asynchronous simulation (ASIM), you need to follow certain rules. The rules apply to any code run by a rendering thread, which means all DrawXXX call-ins plus the Update call-in. UI call-ins (mouse/keyboard etc) are also run by the rendering thread.

== All versions ==
Lua code must be designed so that it works even if objects are deleted (and possibly replaced by another object with same ID) in between '''any''' rendering call-ins. This means rendering code that stores lists of e.g. units in global variables must update these according to UnitCreated/UnitDestroyed events or re-check the units for validity before use. Keep in mind that if an object has been replaced, the operation that you intended to perform may no longer be valid for the new object.

== 0.82.X ==
Unfortunately, Spring MT has very limited Lua rendering support in this engine version, and it carries a huge negative performance impact. Especially time-consuming rendering such as looping through a set of units and drawing something for each one, must be avoided.

Only the rendering thread may use Lua OpenGL stuff, so you must be careful not to create e.g. display lists in the wrong call-ins.

There are also numerous related bugs in this version, that could turn your coding job into a trial-and-error nightmare. Deadlocks and crashes can be expected.

== 83.0+ ==
Rendering in a gadget can - depending on the threading model (see below) - negatively affect the performance, although the performance penalty is less severe compared to in the previous engine version. Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget by calling Script.LuaUI.XXX(), but the value returned from this call is undefined in MT Spring. Similarly, the result obtained when checking for the existence of a Script.LuaUI.XXX function can be unpredictable, instead the widget may send a LuaRules message to indicate that the function now exists or has ceased to exist.

Depending on the threading model (see below) - batching mechanisms can also produce some side effects. For example, a widget that processes an UnitEnteredLOS event cannot make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this issue. Batch management is expensive, making it very difficult to solve this problem engine side.

Finally, if the threading model (see below) is set to mode(2), it is illegal to invoke LuaUI from another Lua environment. This can happen depending on what features (call-ins) the game implements, and what widgets the user has activated. If such an attempt to invoke LuaUI is detected, it will be skipped to prevent a deadlock, and a warning will also be printed in the console. Update the game to use a threading model > 2 to resolve the issue.

== Lua Threading Models==
These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better with Spring MT. A game that specifies <code>luaThreadingModel > 2</code> will be considered asynchronous simulation (ASIM) compatible, and will have the <code>simulation thread enabled by default.</code>

:<code>0</code> - No MT, single threaded;
:<code>1</code> - Single state;
::''This mode has a single Lua environment for everything. It will cause a significant slowdown because simulation and rendering threads block each other trying to access the shared Lua environment. Especially problematic is Lua rendering; being inherently time consuming (looping through large amounts of units etc.) it will force the simulation thread to wait. This gives rise to the classic phenomenon of having incredibly high FPS but still lagging behind (high ping) since simulation cannot keep up with the normal pace.''
:<code>2</code> - Single state, batching of unsynced events; <code>(default mode)</code>
::''This mode is considerably better than mode(1) since it has a separate Lua environment for LuaUI.''
::''All simulation events sent to LuaUI are also batched/delayed to reduce the need for the threads to block each other. For instance, if simulation triggers UnitMoved(), the event will not reach LuaUI right away, but is put in a batch and handled as soon as possible by the rendering thread. The batching system is managed, i.e. if the unit that triggered UnitMoved is about to be deleted (and thus invalidated) the batch is forcefully run before deletion occurs. Because the forced batch run is performed by the simulation thread, locking is required and this can degrade simulation performance for the same reasons as in mode(1).''
::''The other means of unsynced communication, SendToUnsynced and Script.LuaUI.XXX() are also batched and managed to make sure any object ID or such sent are still valid once the message arrives. Note: Script.LuaUI.XXX() does because of the batching NOT have a return value.''
::''This mode unfortunately suffers the same problems as mode(1) for rendering gadgets, since simulation events must be sent to the gadgets directly (without batching) in order not to desync the game.''
:<code>3</code> - Dual states for synced, batching of unsynced events, synced/unsynced communication via EXPORT table and SendToUnsynced;
::''Same as mode(2), but the gadgets have separate Lua environments depending on whether the simulation or rendering thread is invoking it. This alleviates the negative performance impact for rendering gadgets, but makes it impossible to directly share synced gadget data to the unsynced part via _G --> SYNCED. To work around this limitation, this mode introduces _G.EXPORT that is automatically copied to SYNCED.EXPORT. Only small amounts of data should be stored in the EXPORT table, because the copying is performed very frequently. Cyclical and/or very deeply nested tables are not allowed. Larger data can be stored temporarily, e.g.
::_G.EXPORT.myhugetable = huge_table
::SendToUnsynced("huge_table_available")
::_G.EXPORT.myhugetable = nil''
:<code>4</code> - Dual states for synced, batching of unsynced events, synced/unsynced communication via SendToUnsynced only;
::''Same as mode(3) but with the EXPORT table disabled to increase the performance further. You don't need EXPORT, SendToUnsynced alone is sufficient.''
:<code>5</code> - Dual states for all, all synced/unsynced communication (widgets included) via SendToUnsynced only;
::''Same as mode(4), but adds separate Lua environments for LuaUI depending on whether the simulation or rendering thread is invoking it. With dual LuaUI states, batching is no longer needed and therefore disabled. This makes it even faster, since batching overhead is eliminated and forced batch runs (see mode(2)) are not needed. However, this mode adds significant complexity for the programmer, since essentially two instances of the same widget are run, and only the calling thread determines which one is invoked. As a rule of thumb, all simulation events (GameFrame etc.) are invoked by the simulation thread. All UI and rendering events and Update() are invoked by the rendering thread. So, if a variable is modified in GameFrame(), that change cannot be seen in Update(). The widget must instead use SendToUnsynced to communicate any data from the simulation widget instance to the rendering widget instance. Design wise it may be suitable to write the widget similarly to a gadget, with clearly separated "synced" and "unsynced" parts, each with their own variables, functions and call-ins.''
:<code>6</code> - Dual states for all, all synced/unsynced communication (widgets included) is unmanaged and via SendToUnsynced only.
::''Same as mode(5) but the SendToUnsynced and Script.LuaUI.XXX() communication is unmanaged. The Lua coder must manually check if object references sent are still valid when the message arrives.''

:'''Which mode to use?''' The default mode(2) is usually good enough unless you need rendering gadgets. Extreme lightweight rendering gadgets may be OK, but if the LUA-SYNC-CPU indicator appears in the upper right part of the window it usually indicates a performance problem, especially if the value displayed is higher than 1%. If you write a new widget/gadget, consider designing it to be compatible with a higher mode.

[[Category:Lua]]

Asynchronous Simulation

2013-03-22T00:42:26Z

Zerver: /* Lua Threading Models */

== Spring Multithreaded Lua Compatibility ==
In order to make your Lua code compatible with asynchronous simulation (ASIM), you need to follow certain rules. The rules apply to any code run by a rendering thread, which means all DrawXXX call-ins plus the Update call-in. UI call-ins (mouse/keyboard etc) are also run by the rendering thread.

== All versions ==
Lua code must be designed so that it works even if objects are deleted (and possibly replaced by another object with same ID) in between '''any''' rendering call-ins. This means rendering code that stores lists of e.g. units in global variables must update these according to UnitCreated/UnitDestroyed events or re-check the units for validity before use. Keep in mind that if an object has been replaced, the operation that you intended to perform may no longer be valid for the new object.

== 0.82.X ==
Unfortunately, Spring MT has very limited Lua rendering support in this engine version, and it carries a huge negative performance impact. Especially time-consuming rendering such as looping through a set of units and drawing something for each one, must be avoided.

Only the rendering thread may use Lua OpenGL stuff, so you must be careful not to create e.g. display lists in the wrong call-ins.

There are also numerous related bugs in this version, that could turn your coding job into a trial-and-error nightmare. Deadlocks and crashes can be expected.

== 83.0+ ==
Rendering in a gadget can - depending on the threading model (see below) - negatively affect the performance, although the performance penalty is less severe compared to in the previous engine version. Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget by calling Script.LuaUI.XXX(), but the value returned from this call is undefined in MT Spring. Similarly, the result obtained when checking for the existence of a Script.LuaUI.XXX function can be unpredictable, instead the widget may send a LuaRules message to indicate that the function now exists or has ceased to exist.

Depending on the threading model (see below) - batching mechanisms can also produce some side effects. For example, a widget that processes an UnitEnteredLOS event cannot make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this issue. Batch management is expensive, making it very difficult to solve this problem engine side.

Finally, if the threading model (see below) is set to mode(2), it is illegal to invoke LuaUI from another Lua environment. This can happen depending on what features (call-ins) the game implements, and what widgets the user has activated. If such an attempt to invoke LuaUI is detected, it will be skipped to prevent a deadlock, and a warning will also be printed in the console. Update the game to use a threading model > 2 to resolve the issue.

== Lua Threading Models==
These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better with Spring MT. A game that specifies <code>luaThreadingModel > 2</code> will be considered asynchronous simulation (ASIM) compatible, and will have the <code>simulation thread enabled by default.</code>

:<code>0</code> - No MT, single threaded;
:<code>1</code> - Single state;
::''This mode has a single Lua environment for everything. It will cause a significant slowdown because simulation and rendering threads block each other trying to access the shared Lua environment. Especially problematic is Lua rendering; being inherently time consuming (looping through large amounts of units etc.) it will force the simulation thread to wait. This gives rise to the classic phenomenon of having incredibly high FPS but still lagging behind (high ping) since simulation cannot keep up with the normal pace.''
:<code>2</code> - Single state, batching of unsynced events;
::''This mode is considerably better than mode(1) since it has a separate Lua environment for LuaUI.''
::''All simulation events sent to LuaUI are also batched/delayed to reduce the need for the threads to block each other. For instance, if simulation triggers UnitMoved(), the event will not reach LuaUI right away, but is put in a batch and handled as soon as possible by the rendering thread. The batching system is managed, i.e. if the unit that triggered UnitMoved is about to be deleted (and thus invalidated) the batch is forcefully run before deletion occurs. Because the forced batch run is performed by the simulation thread, locking is required and this can degrade simulation performance for the same reasons as in mode(1).''
::''The other means of unsynced communication, SendToUnsynced and Script.LuaUI.XXX() are also batched and managed to make sure any object ID or such sent are still valid once the message arrives. Note: Script.LuaUI.XXX() does because of the batching NOT have a return value.''
::''This mode unfortunately suffers the same problems as mode(1) for rendering gadgets, since simulation events must be sent to the gadgets directly (without batching) in order not to desync the game.''
:<code>3</code> - Dual states for synced, batching of unsynced events, synced/unsynced communication via EXPORT table and SendToUnsynced;
::''Same as mode(2), but the gadgets have separate Lua environments depending on whether the simulation or rendering thread is invoking it. This alleviates the negative performance impact for rendering gadgets, but makes it impossible to directly share synced gadget data to the unsynced part via _G --> SYNCED. To work around this limitation, this mode introduces _G.EXPORT that is automatically copied to SYNCED.EXPORT. Only small amounts of data should be stored in the EXPORT table, because the copying is performed very frequently. Cyclical and/or very deeply nested tables are not allowed. Larger data can be stored temporarily, e.g.
::_G.EXPORT.myhugetable = huge_table
::SendToUnsynced("huge_table_available")
::_G.EXPORT.myhugetable = nil''
:<code>4</code> - Dual states for synced, batching of unsynced events, synced/unsynced communication via SendToUnsynced only;
::''Same as mode(3) but with the EXPORT table disabled to increase the performance further. You don't need EXPORT, SendToUnsynced alone is sufficient.''
:<code>5</code> - Dual states for all, all synced/unsynced communication (widgets included) via SendToUnsynced only;
::''Same as mode(4), but adds separate Lua environments for LuaUI depending on whether the simulation or rendering thread is invoking it. With dual LuaUI states, batching is no longer needed and therefore disabled. This makes it even faster, since batching overhead is eliminated and forced batch runs (see mode(2)) are not needed. However, this mode adds significant complexity for the programmer, since essentially two instances of the same widget are run, and only the calling thread determines which one is invoked. As a rule of thumb, all simulation events (GameFrame etc.) are invoked by the simulation thread. All UI and rendering events and Update() are invoked by the rendering thread. So, if a variable is modified in GameFrame(), that change cannot be seen in Update(). The widget must instead use SendToUnsynced to communicate any data from the simulation widget instance to the rendering widget instance. Design wise it may be suitable to write the widget similarly to a gadget, with clearly separated "synced" and "unsynced" parts, each with their own variables, functions and call-ins.''
:<code>6</code> - Dual states for all, all synced/unsynced communication (widgets included) is unmanaged and via SendToUnsynced only.
::''Same as mode(5) but the SendToUnsynced and Script.LuaUI.XXX() communication is unmanaged. The Lua coder must manually check if object references sent are still valid when the message arrives.''

:'''Which mode to use?''' The default mode(2) is usually good enough unless you need rendering gadgets. Extreme lightweight rendering gadgets may be OK, but if the LUA-SYNC-CPU indicator appears in the upper right part of the window it usually indicates a performance problem, especially if the value displayed is higher than 1%. If you write a new widget/gadget, consider designing it to be compatible with a higher mode.

[[Category:Lua]]

Asynchronous Simulation

2013-03-22T00:38:00Z

Zerver: /* Lua Threading Models */

== Spring Multithreaded Lua Compatibility ==
In order to make your Lua code compatible with asynchronous simulation (ASIM), you need to follow certain rules. The rules apply to any code run by a rendering thread, which means all DrawXXX call-ins plus the Update call-in. UI call-ins (mouse/keyboard etc) are also run by the rendering thread.

== All versions ==
Lua code must be designed so that it works even if objects are deleted (and possibly replaced by another object with same ID) in between '''any''' rendering call-ins. This means rendering code that stores lists of e.g. units in global variables must update these according to UnitCreated/UnitDestroyed events or re-check the units for validity before use. Keep in mind that if an object has been replaced, the operation that you intended to perform may no longer be valid for the new object.

== 0.82.X ==
Unfortunately, Spring MT has very limited Lua rendering support in this engine version, and it carries a huge negative performance impact. Especially time-consuming rendering such as looping through a set of units and drawing something for each one, must be avoided.

Only the rendering thread may use Lua OpenGL stuff, so you must be careful not to create e.g. display lists in the wrong call-ins.

There are also numerous related bugs in this version, that could turn your coding job into a trial-and-error nightmare. Deadlocks and crashes can be expected.

== 83.0+ ==
Rendering in a gadget can - depending on the threading model (see below) - negatively affect the performance, although the performance penalty is less severe compared to in the previous engine version. Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget by calling Script.LuaUI.XXX(), but the value returned from this call is undefined in MT Spring. Similarly, the result obtained when checking for the existence of a Script.LuaUI.XXX function can be unpredictable, instead the widget may send a LuaRules message to indicate that the function now exists or has ceased to exist.

Depending on the threading model (see below) - batching mechanisms can also produce some side effects. For example, a widget that processes an UnitEnteredLOS event cannot make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this issue. Batch management is expensive, making it very difficult to solve this problem engine side.

Finally, if the threading model (see below) is set to mode(2), it is illegal to invoke LuaUI from another Lua environment. This can happen depending on what features (call-ins) the game implements, and what widgets the user has activated. If such an attempt to invoke LuaUI is detected, it will be skipped to prevent a deadlock, and a warning will also be printed in the console. Update the game to use a threading model > 2 to resolve the issue.

== Lua Threading Models==
These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better with Spring MT. <code>A game that specifies luaThreadingModel > 2 will be considered asynchronous simulation (ASIM) compatible, and will have the simulation thread enabled by default.</code>

:<code>0</code> - No MT, single threaded;
:<code>1</code> - Single state;
::''This mode has a single Lua environment for everything. It will cause a significant slowdown because simulation and rendering threads block each other trying to access the shared Lua environment. Especially problematic is Lua rendering; being inherently time consuming (looping through large amounts of units etc.) it will force the simulation thread to wait. This gives rise to the classic phenomenon of having incredibly high FPS but still lagging behind (high ping) since simulation cannot keep up with the normal pace.''
:<code>2</code> - Single state, batching of unsynced events;
::''This mode is considerably better than mode(1) since it has a separate Lua environment for LuaUI.''
::''All simulation events sent to LuaUI are also batched/delayed to reduce the need for the threads to block each other. For instance, if simulation triggers UnitMoved(), the event will not reach LuaUI right away, but is put in a batch and handled as soon as possible by the rendering thread. The batching system is managed, i.e. if the unit that triggered UnitMoved is about to be deleted (and thus invalidated) the batch is forcefully run before deletion occurs. Because the forced batch run is performed by the simulation thread, locking is required and this can degrade simulation performance for the same reasons as in mode(1).''
::''The other means of unsynced communication, SendToUnsynced and Script.LuaUI.XXX() are also batched and managed to make sure any object ID or such sent are still valid once the message arrives. Note: Script.LuaUI.XXX() does because of the batching NOT have a return value.''
::''This mode unfortunately suffers the same problems as mode(1) for rendering gadgets, since simulation events must be sent to the gadgets directly (without batching) in order not to desync the game.''
:<code>3</code> - Dual states for synced, batching of unsynced events, synced/unsynced communication via EXPORT table and SendToUnsynced;
::''Same as mode(2), but the gadgets have separate Lua environments depending on whether the simulation or rendering thread is invoking it. This alleviates the negative performance impact for rendering gadgets, but makes it impossible to directly share synced gadget data to the unsynced part via _G --> SYNCED. To work around this limitation, this mode introduces _G.EXPORT that is automatically copied to SYNCED.EXPORT. Only small amounts of data should be stored in the EXPORT table, because the copying is performed very frequently. Cyclical and/or very deeply nested tables are not allowed. Larger data can be stored temporarily, e.g.
::_G.EXPORT.myhugetable = huge_table
::SendToUnsynced("huge_table_available")
::_G.EXPORT.myhugetable = nil''
:<code>4</code> - Dual states for synced, batching of unsynced events, synced/unsynced communication via SendToUnsynced only;
::''Same as mode(3) but with the EXPORT table disabled to increase the performance further. You don't need EXPORT, SendToUnsynced alone is sufficient.''
:<code>5</code> - Dual states for all, all synced/unsynced communication (widgets included) via SendToUnsynced only;
::''Same as mode(4), but adds separate Lua environments for LuaUI depending on whether the simulation or rendering thread is invoking it. With dual LuaUI states, batching is no longer needed and therefore disabled. This makes it even faster, since batching overhead is eliminated and forced batch runs (see mode(2)) are not needed. However, this mode adds significant complexity for the programmer, since essentially two instances of the same widget are run, and only the calling thread determines which one is invoked. As a rule of thumb, all simulation events (GameFrame etc.) are invoked by the simulation thread. All UI and rendering events and Update() are invoked by the rendering thread. So, if a variable is modified in GameFrame(), that change cannot be seen in Update(). The widget must instead use SendToUnsynced to communicate any data from the simulation widget instance to the rendering widget instance. Design wise it may be suitable to write the widget similarly to a gadget, with clearly separated "synced" and "unsynced" parts, each with their own variables, functions and call-ins.''
:<code>6</code> - Dual states for all, all synced/unsynced communication (widgets included) is unmanaged and via SendToUnsynced only.
::''Same as mode(5) but the SendToUnsynced and Script.LuaUI.XXX() communication is unmanaged. The Lua coder must manually check if object references sent are still valid when the message arrives.''

:'''Which mode to use?''' The default mode(2) is usually good enough unless you need rendering gadgets. Extreme lightweight rendering gadgets may be OK, but if the LUA-SYNC-CPU indicator appears in the upper right part of the window it usually indicates a performance problem, especially if the value displayed is higher than 1%. If you write a new widget/gadget, consider designing it to be compatible with a higher mode.

[[Category:Lua]]

Asynchronous Simulation

2013-03-21T23:52:58Z

Zerver: /* Lua Threading Models */

== Spring Multithreaded Lua Compatibility ==
In order to make your Lua code compatible with asynchronous simulation (ASIM), you need to follow certain rules. The rules apply to any code run by a rendering thread, which means all DrawXXX call-ins plus the Update call-in. UI call-ins (mouse/keyboard etc) are also run by the rendering thread.

== All versions ==
Lua code must be designed so that it works even if objects are deleted (and possibly replaced by another object with same ID) in between '''any''' rendering call-ins. This means rendering code that stores lists of e.g. units in global variables must update these according to UnitCreated/UnitDestroyed events or re-check the units for validity before use. Keep in mind that if an object has been replaced, the operation that you intended to perform may no longer be valid for the new object.

== 0.82.X ==
Unfortunately, Spring MT has very limited Lua rendering support in this engine version, and it carries a huge negative performance impact. Especially time-consuming rendering such as looping through a set of units and drawing something for each one, must be avoided.

Only the rendering thread may use Lua OpenGL stuff, so you must be careful not to create e.g. display lists in the wrong call-ins.

There are also numerous related bugs in this version, that could turn your coding job into a trial-and-error nightmare. Deadlocks and crashes can be expected.

== 83.0+ ==
Rendering in a gadget can - depending on the threading model (see below) - negatively affect the performance, although the performance penalty is less severe compared to in the previous engine version. Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget by calling Script.LuaUI.XXX(), but the value returned from this call is undefined in MT Spring. Similarly, the result obtained when checking for the existence of a Script.LuaUI.XXX function can be unpredictable, instead the widget may send a LuaRules message to indicate that the function now exists or has ceased to exist.

Depending on the threading model (see below) - batching mechanisms can also produce some side effects. For example, a widget that processes an UnitEnteredLOS event cannot make any assumptions about the unit actually being in LOS. Because of batching delay, it may have left LOS already when the message is processed, and an attempt to get further info about the unit may therefore fail, since access to out-of-LOS units is restricted. Numerous events are more or less affected by this issue. Batch management is expensive, making it very difficult to solve this problem engine side.

Finally, if the threading model (see below) is set to mode(2), it is illegal to invoke LuaUI from another Lua environment. This can happen depending on what features (call-ins) the game implements, and what widgets the user has activated. If such an attempt to invoke LuaUI is detected, it will be skipped to prevent a deadlock, and a warning will also be printed in the console. Update the game to use a threading model > 2 to resolve the issue.

== Lua Threading Models==
These modes can be set for a game using <code>luaThreadingModel</code> in [[Modrules.lua#system|Modrules.lua]]. The engine can override with the setting <code>MultiThreadLua</code>. A higher mode generally means that the game will perform better with Spring MT. ''A game that specifies luaThreadingModel > 2 will be considered asynchronous simulation (ASIM) compatible, and will have the ASIM enabled by default.''

:<code>0</code> - No MT, single threaded;
:<code>1</code> - Single state;
::''This mode has a single Lua environment for everything. It will cause a significant slowdown because simulation and rendering threads block each other trying to access the shared Lua environment. Especially problematic is Lua rendering; being inherently time consuming (looping through large amounts of units etc.) it will force the simulation thread to wait. This gives rise to the classic phenomenon of having incredibly high FPS but still lagging behind (high ping) since simulation cannot keep up with the normal pace.''
:<code>2</code> - Single state, batching of unsynced events;
::''This mode is considerably better than mode(1) since it has a separate Lua environment for LuaUI.''
::''All simulation events sent to LuaUI are also batched/delayed to reduce the need for the threads to block each other. For instance, if simulation triggers UnitMoved(), the event will not reach LuaUI right away, but is put in a batch and handled as soon as possible by the rendering thread. The batching system is managed, i.e. if the unit that triggered UnitMoved is about to be deleted (and thus invalidated) the batch is forcefully run before deletion occurs. Because the forced batch run is performed by the simulation thread, locking is required and this can degrade simulation performance for the same reasons as in mode(1).''
::''The other means of unsynced communication, SendToUnsynced and Script.LuaUI.XXX() are also batched and managed to make sure any object ID or such sent are still valid once the message arrives. Note: Script.LuaUI.XXX() does because of the batching NOT have a return value.''
::''This mode unfortunately suffers the same problems as mode(1) for rendering gadgets, since simulation events must be sent to the gadgets directly (without batching) in order not to desync the game.''
:<code>3</code> - Dual states for synced, batching of unsynced events, synced/unsynced communication via EXPORT table and SendToUnsynced;
::''Same as mode(2), but the gadgets have separate Lua environments depending on whether the simulation or rendering thread is invoking it. This alleviates the negative performance impact for rendering gadgets, but makes it impossible to directly share synced gadget data to the unsynced part via _G --> SYNCED. To work around this limitation, this mode introduces _G.EXPORT that is automatically copied to SYNCED.EXPORT. Only small amounts of data should be stored in the EXPORT table, because the copying is performed very frequently. Cyclical and/or very deeply nested tables are not allowed. Larger data can be stored temporarily, e.g.
::_G.EXPORT.myhugetable = huge_table
::SendToUnsynced("huge_table_available")
::_G.EXPORT.myhugetable = nil''
:<code>4</code> - Dual states for synced, batching of unsynced events, synced/unsynced communication via SendToUnsynced only;
::''Same as mode(3) but with the EXPORT table disabled to increase the performance further. You don't need EXPORT, SendToUnsynced alone is sufficient.''
:<code>5</code> - Dual states for all, all synced/unsynced communication (widgets included) via SendToUnsynced only;
::''Same as mode(4), but adds separate Lua environments for LuaUI depending on whether the simulation or rendering thread is invoking it. With dual LuaUI states, batching is no longer needed and therefore disabled. This makes it even faster, since batching overhead is eliminated and forced batch runs (see mode(2)) are not needed. However, this mode adds significant complexity for the programmer, since essentially two instances of the same widget are run, and only the calling thread determines which one is invoked. As a rule of thumb, all simulation events (GameFrame etc.) are invoked by the simulation thread. All UI and rendering events and Update() are invoked by the rendering thread. So, if a variable is modified in GameFrame(), that change cannot be seen in Update(). The widget must instead use SendToUnsynced to communicate any data from the simulation widget instance to the rendering widget instance. Design wise it may be suitable to write the widget similarly to a gadget, with clearly separated "synced" and "unsynced" parts, each with their own variables, functions and call-ins.''
:<code>6</code> - Dual states for all, all synced/unsynced communication (widgets included) is unmanaged and via SendToUnsynced only.
::''Same as mode(5) but the SendToUnsynced and Script.LuaUI.XXX() communication is unmanaged. The Lua coder must manually check if object references sent are still valid when the message arrives.''

:'''Which mode to use?''' The default mode(2) is usually good enough unless you need rendering gadgets. Extreme lightweight rendering gadgets may be OK, but if the LUA-SYNC-CPU indicator appears in the upper right part of the window it usually indicates a performance problem, especially if the value displayed is higher than 1%. If you write a new widget/gadget, consider designing it to be compatible with a higher mode.

[[Category:Lua]]