免责声明：本人以下内容为云评测，如与游戏内容存在出入还请原谅
科普一点常识：戴森球计划存档大的主要原因就是戴森球和太阳帆，官方曾经对戴森球和太阳帆的占用硬盘空间做出了多次优化，但是现在随随便便搓几个球都会让存档爆炸到几百mb甚至gb级别，这不仅占用硬盘空间更严重的是会导致自动保存时卡顿时间高达数秒，取消自动保存如果发生意外断电或闪退那一天白干又得不偿失，所以我在想能不能一定程度的牺牲戴森球和太阳帆的外观来做到只保存最少的数据来还原戴森球和太阳帆的外貌以及数据
先说一下核心思路：牺牲一部分戴森球和太阳帆的位置数据，把尽量多的工作交给加载过程 进 行 现 场 即 时 演 算 和 生 成，这样理论上可以大幅度的节约存档占用大小和大幅度加快保存速度，当然这也可能会导致加载过程变长
现在来看一下要保存一个太阳帆或戴森球要有什么数据
一个由轨道炮打出的太阳帆的数据有所在轨道的半径、倾角、升交点经度，以及本身在轨道上所在点与升交点的夹角再加上一个发射时带来的随机偏差数值，是否正在被节点吸收和被节点吸收的过程完成了多少或是否刚被发射还未进入轨道的过程完成了多少，若是在轨太阳帆则还需要记录其剩余寿命数据
另一种产生太阳帆的方式是拆除现有戴森球，那么这时候每个太阳帆都需要单独的记录其轨道数据和其寿命数据，我认为这可能会导致存档大小激增（虽然基本没人会在正常情况下拆戴森球就是了），我建议拆除戴森球后的太阳帆先行判断是否有需要太阳帆的戴森球节点让戴森球节点优先吸附，或者让太阳帆自行归位到一号轨道来节约空间
我的想法是放弃存储太阳帆所在点和升交点夹角与随机偏差值，只记录某条轨道上有多少太阳帆，太阳帆所在位置和随机偏差则在加载存档时现场计算，理论上这样存档大小只会由有多少个太阳帆轨道决定而不是每个太阳帆都会导致存档大小增加
每个太阳帆的寿命问题我猜测是官方选择记录每个太阳帆详细信息的原因之一，我认为整个太阳帆群的寿命可以被简化为一个总值，每个太阳帆入轨时为整个太阳帆群加入其寿命时间单位个寿命，每物理帧减去太阳帆群总寿命/太阳帆数量的寿命值，1/太阳帆初始寿命的物理帧就是此物理帧应当从太阳帆群中删去的太阳帆数量，并对其结果的小数位进行累计加入到下一个物理帧减去的帆数中去，这样也无需记录每个太阳帆的寿命了，更多的太阳帆也不会导致存档大小增加了
正在被吸收的太阳帆则也放弃存储他们的位置，只记录吸收太阳帆的节点吸收过程吸收了哪一个轨道的太阳帆并将其排序，每次加载存档现场按照吸收顺序生成
发射中的太阳帆我暂时没有想到怎么去压缩他们而且由于其数量相对在轨太阳帆和吸收中的帆较少所以应该也不会对存档造成多大影响
目前我能想到的问题是这会导致的问题是如果有一个存档在发展阶段正在大量发射太阳帆那么每次重启的现场随机生成都会导致太阳帆被“抹匀了”这就会导致多次保存重加载可能会让太阳帆轨道密度出现不平衡的情况，但是在后期戴森球建设开始后太阳帆发射入轨后就将会几乎立刻被吸附，这时在轨太阳帆数量本身就少所以也不会出现太阳帆轨道密度不均的情况
戴森球简化思路稍后更新