魔龙拽根🐴 86661568
关注数: 18 粉丝数: 72 发帖数: 16,612 关注贴吧数: 157
记一次抢救已“损坏”存档 这个惨剧发生在我的一个单机创造模式的存档上。 事情的起因是我因故在“返回标题画面”并保存的过程中强行关机。当我再次开机并启动游戏、选择“读取游戏”后,突然弹出错误提示:“一个世界/存档的文件已经损坏,无法加载。详细信息请查看日志。”;再一看,那个存档已经从列表当中消失了,想读取备份都不行。心里顿时凉了半截。 静下心来,我首先google了一下恢复损坏存档的办法。前几个搜索结果都建议试试SE ToolBox这个工具,但当时我时间比较紧迫,又不确定这个工具目前游戏版本是否还能用,再加上懒,所以想再找找别的办法,最好能利用存档自带备份来恢复。 于是我打开SE的存档目录,找到该损坏存档对应的文件夹。首先手动复制了一份来备份防止手残;然后用文本工具打开SANDBOX_0_0_0_.sbs,发现其内容变成了乱码(正常情况下是xml格式的文本),推测损坏的应该就是Sandbox.sbc、SANDBOX_0_0_0_.sbs和SANDBOX_0_0_0_.sbsB1三个文件中的至少一个。再打开该存档文件夹内的Backup(备份)文件夹,找到最近的一个备份,打开其SANDBOX_0_0_0_.sbs,还是乱码;又打开上一个备份里的SANDBOX_0_0_0_.sbs,总算是正常的了。于是将这个备份中的三个sandbox文件复制到损坏存档的文件夹,覆盖掉损坏的文件。启动游戏,成功读取存档。好在这个备份时间离强关时很接近,没有什么损失。 学到的教训: 确保存档的备份功能开启(编辑设定-高级),并且养成随手存档的习惯。
(试作,有Mod)旋转座椅或机身焊接切割两用大气内工作船 因受到一张不知名人士在上古版本制作的、通过旋转船身侧面连有焊接器和切割器的悬臂而实现切换功能的工作船的GIF图启发,我尝试性地做了这艘工作船OvO 实际上并没有用,因为船体太重,需要很多推进器,导致体积和能耗都很大(目前形态是之前计算错误的结果,这点推进器数量无法达到设计性能),同时这种双功能切换的设计实际上比较多余 全船主要分为座舱部分和主体部分,二者之间以转子相连,使用隔转子推进器脚本从座舱控制主体的推进器。装有测距脚本,通过定时块连续向其发送指令实现“实时”测距,显示在左侧的透明LCD上,辅助驾驶者判断工具和作业对象的距离,减小碰撞受损的可能。由于工作过程需要,以及隔转子推进器脚本本身缺陷导致轻微平移,故装有姿态和速度显示脚本,显示在右侧的透明LCD上,帮助驾驶者更好地获知当前飞船的姿态和速度方向。 由于不会C#,因此用8个定时块来实现船体固定旋转座舱和座舱固定旋转船体,原理依靠转子的共用惯性张量的开关。 因为切割器和焊接器自带不小的物品栏,因此没有装备箱子。实际上本来在船体下方应有一个连接器用来对接基地、大船,但由于隔转子推进器脚本“忽略隔连接器的推进器”特性的一个缺陷,启用此特性时只要检测到连接器就会罢工,故暂时没有安装(实际上有将不利影响最小化的方法,但尚未测试)。 另外,这个设计稍加改动可去除Mod,可以将上部Mod控制座椅换成原版小船座舱(虽然会重不少)或者乘客座椅+遥控,视野要求不高的话小船玻璃可以用方块代替,透明LCD也可用原版文本面板来代替(但最后移动到视野左下、右下位置,否则遮挡太多)。座舱视角转换中(座舱固定旋转船体)(不会录动图,找到合适工具以后也许会补一张) 使用的Mod和脚本列表 姿态和速度显示脚本:Whip's Artificial Horizon Script 隔转子推进器脚本:Whip's Rotor Thruster Manager 测距脚本:Blarg's Fancy Ruler 控制座椅Mod:Azimuth Passenger Seat & Open Cockpit 小船玻璃Mod:Small Ship Window Pack 透明LCD Mod:Transparent Displays - See-through LCDs!
【不水】关于帖子《数据党揭秘3.0发布时间》(简称)的看法 本文确实挺长,不过诸位大可不必跳过,倒杯热水慢慢看即可 客观的态度、大量的数据、准确的分析,“数据党”可以说是令人信服的代名词。然而,有时候数据党也会有意无意地玩弄不明真相的围观群众。 事情的起因是吧里的一篇帖子《真实的3.0发布时间到底是什么?数据党给你揭秘》。 https://tieba.baidu.com/p/5156460653 看标题,终于有大佬坐不住要给吧友预测3.0的放出时间了,虽然结论八成是又要继续跳票到某日,不过有理有据的预测总比我们天天瞎JB猜要好得多,何况还是有名的(过气)奸商普罗的帖子就这样满怀期待地点进去,发现竟然是毫无解说的一图流。在一张图表里囊括所有的要素并让人看懂就更有意思了。普罗大佬表示“你们应该能看懂”,然而恕我驽钝,对着这图表抓耳挠腮半天才是一知半解:图(1) 同比,是指在相邻时段中的某一相同时间点进行比较,这里的同比是指每7天更新3.0的时间表时里的预期时间与上一次相比的延期;x轴前9项是自3.0时间表公布(4月14日)以来的各次时间表更新,最后一项Total Delay(总延期时间)则大致是前几项之和(实际上按图表来加是1484,这个的原因我在楼下会说明);而y轴是同比延期的时长——然而这个时长没有标注单位,我向下翻到楼主回复4楼的楼中楼才知道单位应该是是“天”。从表中可以看出,从第三次开始,每次更新时间表的同比跳票时间都达到了数百天,最后加总的Total Delay(总延期时间)竟有惊人的1480天!图(2) 辣鸡萝卜,1480天......你TM在逗我?照这样说岂不是2021年才能和3.0见面,那时候4楼的孩子就真的会走路了(花一年找对象结婚,啪完怀胎10月,2岁左右发育到能走路的水平。最后一个是我百度的)。SC有史以来最大的跳票也不过一年(虽然也有可能被刷新,不过那时候估计CIG要惨遭集体诉讼就是了),而且据我所知3.0时间表最多也是十几天几十天的跳,单次跳数百天真是闻所未闻。 仔细想想,这时间绝不可能,太夸张了,很可能是我理解错了楼主的意思,或者楼主处理数据的方式有问题。好在楼主给出了原帖和文档的链接,于是我前往原帖观摩了一番并下载了文档。原帖是StarCitizen Reddit上的一篇纯数据整理帖《3.0.0 and global progress watch》,大致是依据CIG每次更新的版本时间表追踪记录最终底线乃至各个子目标的延期情况并整理成表格。我通过一定的算法处理了该表格的数据,终于得出了原帖楼主的结论。此时我不得不佩服原帖楼主强大的分析力,竟能一矢中的,用如此简洁的方式就预测出3.0可能的跳票时间——图(3) 这是什么鬼......相信在坐用过Office/WPS表格的人应该都认识SUM。也就是说,原帖楼主只是简单地把每次更新的时间表及最后的Total Delay各列从各个子目标到Live这样的最终底线的延期天数简单相加,从而得出了几百上千天惊人的延期天数。而这样的统计方式显然是有问题的。从图5可以看出,除Edvocati、PTU、Live和最终完成是严格的串行关系外,SC版本各个子目标的开发工作是可以有一定的并行关系的,具体并行情况可能是与CIG对各工作室等开发单位在各个任务之间转移的计划有关,也就是说,至少决不能按照串行关系简单加和各个子目标的延期天数来得出3.0的延期时间;而就算是PTU、Live这样有着串行关系的工作,原表格给出的延期时间(图6)也是与分别上一次的公布的PTU、live等时间相比的延期时间,给出的后一项的延期时间与前一项的延期时间之间有包含关系,简单相加重复加了被包含的时间长度,显然是不正确的。图(4)图(5) 综上所述,原帖在“揭秘3.0跳票时间”方面毫无作用,加上普罗自己在原帖4楼的回复中称“如果是串行工作”(表明很可能他自己也清楚自己在做什么),很可能只是一篇不负责任的、博人眼球的玩笑帖,可以山前留名了。按CIG自己说的,各种各样的延期是由于实际开发中遇到的各种难以预测的问题,解决问题的耗时也不易确定。3.0的跳票时间也许连CIG自己都不知道,我们局外人可能就更难预测了,归纳一下以往子目标具有相似特征的版本的跳票时间也许对预测更有帮助,就连根据印象瞎JB猜都比原帖的“分析”靠谱。 也许有人会说,你误解了普罗的意思,人家这个图表并不是想预测3.0的具体跳票时间,而是想侧面说明点别的什么。那还真不好意思,人家普罗的帖子标题就是“真实的3.0发布时间到底是什么?数据党给你揭秘”,而且在帖子里面也没有一点补充说明,咱围观群众还真不觉得他有别的用意,如果有的话那也太委婉了,智商检测器藏得都没这么高深(笑)。当然,如果普罗大大真的只是手抽打错了标题的话,还请站出来说明,我必洗耳恭听。 还有的人会说,普罗只是贴了个高级的智商检测器而已,SC不需要无脑ZZ来破坏游戏环境。那更不好意思,咱们智商普遍一般,我昨晚花了一个半小时才搞明白整件事的逻辑,一个上午才写完理顺这篇文章。智商检测器不是滥用的,也不是多高的门槛都可以设的,毕竟百虑必有一失,一个人偶尔脑子停转犯错不足以说明他是ZZ,SC也不是只需要小部分铁粉的核心向游戏。 这件事说轻些是一本正经的胡说八道,开玩笑钓鱼做得有些过度,说严重些则有可能造成不亚于“腾讯收购”事件的影响,毕竟“数据党”的大名和看似严谨的图表及参考数据链接对我等围观群众来说是很有分量的存在。好在(据我所知)这篇帖子尚未造成影响(不过原帖的4楼好像被吓到了......),所以也没必要强行不让人下台阶,我只希望普罗大大能自己去帖子下面回复说明此为玩笑,不要继续误导更多没有时间去详细思考和求证的围观群众了。 也希望诸位吧友能引起注意,开玩笑的时候要留明显的线索、加滑稽或者补充说明,开具有很大误导性的玩笑之前要三思。如果打算认真处理数据的话不能想当然,你自己的逻辑要能说得通才行,当然也要给吧友们解释清楚。顺便在这里催一下普罗的另一篇关于高端显卡带SC时的帧率的帖子的原数据链接,到现在还没发出来——毕竟未知来源的图片还是很缺乏说服力的。 《星际公民购买显卡参数对比(以下测试在2.6.3版本制作)》 https://tieba.baidu.com/p/5155852591 最后祝“数据党”帖的4楼吧友找个好老婆,早生贵子
首页 1 2 下一页