在trainsim论坛用E文发了点对OpenRails的期望，木有回应

前几天才知道，2011年的最后一天下载了0.7版试了下，觉得还可以，就花了半天多时间写了些期望，不过等了几天也无回应，估计我的期望太高了。E文好的不妨看看，帮顶就不必了，有什么想法中文讨论好了。

http://www.trainsim.com/vbts/showthread.php?305813-Some-wish-to-OpenRails-or-a-train-simulator

谢谢你的支持。论坛管理员会联系你。

子非鱼，

好久没见了。

我现在在OR的开发团队里。现在OR的主要问题是信号系统不完善，另外需要兼容MSTS也限制了OR。

另外，TSSO中的大量机车的贴图无法在OR中显示，是用了非DXT1压缩的缘故。不知能不能修改这些贴图。

tang，我很佩服你十年如一日的还在为MSTS贡献，我是说那个换车程序，我自己是差不多5年多基本不摸火车游戏了。

非DXT1压缩的贴图我还真没听说过，原生的MSTS应该是不支持的，难道是BIN版本提供的支持，也许你可以发点样本给我？

兼容MSTS既是局限，也是为了充分利用现有MSTS资源必要的一步，实际上我认为MSTS开始开发的时候是雄心勃勃的，只是限于商业的需求而限制了发展，大的框架是没有问题的。当然看过EU07就会发现和波兰人那种纯模拟的定位还是有所不同的。

我看过EU07，觉得这才是理想的火车模拟道路，全真实的操作步骤，火车毕竟简单，有辅助提示全仿真还是能做到的，不象飞机，如果喷气客机也要全仿真，玩家数估计十不能一。但是MSTS那种尽量兼容的思路也是有道理的，为了照顾尽量多的玩家，可以分三种级别：一种Arcade Game式的简易模式，甚至不求物理上的完全仿真；一种是物理上全仿真，但AI自动提示并在必要时替你做些步骤，这种比如货列缓解时间长是无法缩短的，但AI有可能在前方降速而你又没及时减速时替你刹车；最后就是全仿真了。全仿真最好能将各种设备尽量独立开来，分别模拟，这种只能靠功能强大的脚本支持，让玩家去编DLL如BVE那样是没有生命力的。

说到信号，正如我所说，sigscr.dat脚本不是个真正的编程语言，支持这个脚本难度大，又不太适合未来的发展，似乎有点不上算，不支持，兼容性就无法完成。其实我觉得虽然线路很多，信号系统种类还是有限的，如果能有好的规划，不支持这个脚本，专门针对线路编几种也许也是一种方案（不过工作量恐怕也不小）。

还是具体来说信号，我认为信号和调度应该分开。MSTS所用的调度算法实际上是很简单的，就是火车向前行进时预占前方若干的区块，如果有冲突，以先占为准，没有可控的调度功能。信号脚本的两个文件看起来内容很多，其实基本都是重复拷贝再略加修改的，这是由于脚本本身的功能不够强大造成的，如果是个真正的程序设计语言，要实现现有功能的脚本代码量是不大的，但这样的架构显然不能适应未来的发展。

我认为未来的调度和多人连线仍然应该是以预占为基础的，在预占外有冲突的地方程序互相协商申请，通过脚本基于时间表可以无人调度，也可人工通过控制台程序网络干预。以预占为基础也可把多人联线对网络的要求降到最低，我认为开发小组忽视玩家对多人连线的热切需求是不正确的。

至于信号，我觉得最理想的境界是可以一国的机车到另一国的铁路上显示正确的车内信号。我觉得信号可以包括3类属性：

自定义信号
    信号类型（国别或公司）
    大小版本号（不兼容后换一个版本），生效的年代范围
    自定义信号名称
    辅助参数？
标准信号属性
    基本类型
      CLEAR APPROACH RESTRICTING STOP_AND_PROCEED STOP 无信号 调车信号
    前方闭塞区段数量
    正线、侧线、分岔角度
    信号限速
    调车信号含义？ 不了解
物理信号属性（以双频为例）
    信号系统名
    频率1
    频率2
    。。。。

车内信号机对不兼容的信号，可通过标准信号属性进行翻译匹配（无法匹配则降级或脚本控制匹配），对物理上半兼容的信号，则可通过物理特性用脚本进行匹配（比如滤波器接收的频率范围等，没有深入研究，这里只是提个想法），或者用表格方式对照翻译。当然还有非信号外的如监控设备一类的信息交互，总之应该充分考虑信息沟通的多样性，在框架上设计为可扩展，避免以后大改。

我正在OR的基础上尝试联网版本，有些进展。具体QQ聊，我的号1798608838。

关于非DXT1的问题，你试试TSSO的DF5就知道了。我用tgatools也打不开这些贴图，但好像MSTS没问题。

tang 发表于 2012-1-4 23:18

                               
登录/注册后可看大图

我正在OR的基础上尝试联网版本，有些进展。具体QQ聊，我的号1798608838。

关于非DXT1的问题，你试试TSSO ...

我是外行....随便发表点意见..
关于你打不开DF5贴图...不知道是什么格式的....是否能联系到这个车当初的作者...或许有可能知道用的是神马格式的贴图哦...

是dxt3格式的。

我很少来这里，但很关注OR，今天忽发现几位大佬似乎来这玩~~TGATool打开ACE呈油彩纹的格式是因为使用了DXT3的压缩方式，这种方式原生MSTS也是支持的，与BIN无关，可自行实验确定。因为据我所知BIN只是加入了一些新的功能参数，对原有的画面没有调整过。当然为什么MSTS支持DXT3不得而知，这只是我们在进行TSSO时为了提高MSTS的贴图质量（PS：也为了防篡改，因为这种转换似乎是不可逆的）。大家知道，大部分的MSTS中国机车都使用1024*1024的格式，当使用zlib无损压缩去处理这么大的图像，在MSTS里使用会有色块现象出现，为了弥补这一缺陷，于是我们发现了使用DXT3这种方式去处理，当然灵感来源于一款为RW制作ACE格式贴图的工具，这款工具提供从DXT1-5的格式压缩图像，于是就有了TANG您说的TGATool打开无法查看的问题，因为TGATOOL似乎只能打开DXT1压缩的，当然由于不可逆，我们会保留转换之前的贴图作为备用，如果以后MSTS转移OR阵地需要，可以还原，当然并无要求MSTS支持的OR一定要支持，因为OR使用XNA的D3D已经在很大程度上提高了画面质量和FPS，相当不错。
另外我比较支持子非鱼的一个观点就是“开发小组忽视玩家对多人连线的热切需求是不正确的。”据我所知模拟火车类游戏里面支持多人连线的一个都没有，只有去年AURAN的TS12才勉勉强强得弄了个出来测试，但是也有诸多限制不理想，如果OR能实现这一功能并大幅降低玩家对网络的要求并能实实在在得运行得起来，那将是一个伟大的突破，当然模式可以不一样，人数可以不多，有没有局域网那更没关系。但是如果没有那只能是一款平庸的作品，即使画面再出色，与MSTS兼容性再好，也不过是MSTS的影子，画面上当然更不可能敌过商业运作的作品，诸如TRAINZ亦或RW，纯属个人意见，一如既往的支持OR！

花时间看了一下子非鱼TRAINSIM的回复，里面提到了一个running monitor，我估计就是LKJ，这个也是我对OR的一个建议，并非愿望，如果能整合到游戏里当然最好，但我觉得老外估摸着不一定有这玩意，而且这个东西各个国家差异也太大了，无法形成有机的统一去整合到游戏里，如果不行的话也没关系，就用现在这个办法也挺好的：找地址从外部获取数据，到时候只能花些时间和功夫再一次去找内存地址了，哈哈~~~

我也开始留意OR了.虽然知道了很久,但没玩MSTS也就没怎么玩OR.

确实如此,连网功能是游戏最大的吸引力了.

关于信号

1,信号应该是对前方可通行区域状态的显示.所以我觉得除了出站信号,可以因为发车时刻问题,在前方区域空闲的情况依然显示红色,其他信号都应该事实反映前方通信区域的状态,也即除出站信号外,其他信号都应该不可以由调度手动控制改变,而需要游戏自己根据条件计算.

2,信号显示的计算应该先判断前一个区段的信号状态,然后决定本区段的信号.我不认为信号机需要计算参考前面若干的信号的显示来决定自己的显示色灯,只要每个信号都判断好自己前方的一个信号显示,联动下来就可以显示多种多个信号的关联信号.

3,对于进站信号需要在判断前一个信号显示前增加一个判断内容,那就是前一个信号是哪一个,因为大家都知道车站有道岔,一个进站信号根据进路的不同,下一个信号机可能不一样,而判断下一个进站信号的最好方法就是判断检索道岔.

4,由第三点我想调度可以控制的除了出站信号机以外,还可以控制的就应该是道岔,在道岔的控制上,道岔应该有自己的游戏互锁控制,即一组产生冲突道岔在调度模块里视为一个整体控制.N种道岔在游戏里应以模块的形式打包

5,调车信号和行车信号的判断应该由机车的操作模式来选择,也就是对于线路同时显示两种信号,机车根据不同的模式选择,由于道岔的存在,保证了完整的区间必然包含一进一出连个信号机,检测不到两个信号的线路,意味者断开道岔或没路,也就保证了车不会冲过信号,因为有车行走的区段,必然路是通的.

总结一下信号显示的判断方式

本信号机先通过道岔查找前方的信号机,找不到,前方区间不完成,没路或道岔断开,一律显示红色,找的则区间正常,到先判断是否有车在区间,然后判断前一信号的颜色,然后就可以做出本信号颜色决定.

信号机的颜色,类型,区间的完整性都是决定信号颜色的因数,

关于连网

连网跑车,其实是和列车没什么关系的,列车只是按各自的信号跑,游戏只要根据各自的数据综合在游戏里显示就可以了,联网真的关联就是信号,解决了两个独立跑车系统联街后信号的关联问题就可以.

也就是从上文信号显示判断过程中,修正了各车位置的综合判断,感觉其实就是各自在跑车,将各自的位置统一提交参考,反馈信号给各自,并同步将自己的位置画面动作镜象给其他玩家.

上传的是 位置 编组 列车开关灯 鸣镝等独立属性,综合计算的是联动信号,下传的是计算后的信号结果和其他人的景象数据.将其他人理解为AI 但这个AI不是电脑内部计算,而是由其他玩家发上来的参数,联网不是控行车,行车由各自电脑独立控,联网只是综合控制整合信号

调度统一控制了手动部分的信号和道岔.

看见你们的讨论,我也来发表一下我的看法.文中的"应该"其实也没什么应该的.只是一种思路.不妥之处欢迎指正.