My progress so far, if you want to call it that, was to remove or hide some stubs of things that I'm not going to continue working on, like improved AI. I've copied over Tapani_'s issues to my fork of his repo. Feel free to report bugs here in the forum or open an issue over there.
Quote:ETA reporting through nebulae has resisted many attempts to correct it if it's still in 1oom at this point. (I haven't explored that lately.) I like your suggested updates but also lack a Mac on which to run tests.
If I'm reading the issue correctly, it's not that the calculation is off, but that the slowdown is not implemented at all in 1oom. Calculation seems to be the easy part to me: You could just simulate the flight path of the fleet when selecting destinations. Once it's launched, you just count down the number every turn.
Maybe some of the old hands can help me with another issue: The OSG claims that the Industrial Accident event can only hit planets that have at least 30 factories. Is that true for the vanilla 1.3 version?
About the nebula speed issue: I thought that 1 parsec per turn didn't fit with what I've been seeing in-game, but I haven't played in a while, so I wasn't sure. I loaded up an older save and sure enough, I had ships moving faster. The manual and strategy guide are both wrong here.
1oom effectively halves the speed of ships inside nebulas. The fleet movement animation takes 20 frames, and the position of ships inside nebulas is only updated every other frame. From the looks of the animation, this seems to be what's happening in MOO1 as well. That's one issue down without even writing any code!
Another thing: Can someone help me make sense of this post by sargon0? I don't understand the parts about "diagonal boost" and "slipstream". It's hard to follow with the screenshots gone.
EDIT: Another fun fact I learned is that nebulas are always rectangles with horizontal and vertical edges, no matter what they look like on the map.
It is a bit difficult to understand with the broken attachments, but the best I can make out is that he's saying that MoO 1 places objects (planets and fleets) on a grid with a resolution of 1/10th of a parsec. Therefore, there's usually a bit of rounding involved in fleet movement so that everything snaps to the grid. So when he says "distance 9.849" that means travelling 0.9849 parsecs in a straight line.
Diagonal boost section describes conditions in which, while travelling diagonally, you can gain an extra 1/10th parsec in the lesser axis of movement.
Slipstream section describes that movement over only one axis (eg. all x or y movement) gains an extra tenth of a parsec. Eg. a warp 1 fleet moves at a rate of warp 1.1. Therefore, it's actually faster to travel to a destination that is 88 points distant on one axis and 0 on the other than to a destination that is 75 points distant on one axis and 1 on the other. He also notices that the later can rarely move 11 points too, I'm guessing thanks to some kind of rounding which would make the movement vector appear as if it takes place on a single axis given a sufficiently large distance.
I learned about a funny movement bug in MOO1 from reading the source of 1oom: fleet movement in nebulas can sometimes be stopped prematurely if no other ships are still moving. That's because the game aborts the fleet movement phase if nothing moves during one frame of animation. But as I said above, fleets inside nebulas only move every other frame. It's difficult to actually trigger the bug in a noticeable way because there are probably tons of other ships flying around. You can try it out with the attached save: that transport from Thrax isn't going anywhere. Except if you also send a ship somewhere. The ship can even start from a nebula because transports and ships move on alternating frames inside nebulas. That's honestly more about MOO1 fleet movements than I ever wanted to know
This bug is still present in kyrub's patch, but it was fixed in 1oom.
I learned about a funny movement bug in MOO1 from reading the source of 1oom: fleet movement in nebulas can sometimes be stopped prematurely if no other ships are still moving. That's because the game aborts the fleet movement phase if nothing moves during one frame of animation. But as I said above, fleets inside nebulas only move every other frame. It's difficult to actually trigger the bug in a noticeable way because there are probably tons of other ships flying around. You can try it out with the attached save: that transport from Thrax isn't going anywhere. Except if you also send a ship somewhere. The ship can even start from a nebula because transports and ships move on alternating frames inside nebulas. That's honestly more about MOO1 fleet movements than I ever wanted to know
This bug is still present in kyrub's patch, but it was fixed in 1oom.
So you're saying that if every single race started in a nebula, ships would literally never be able to go anywhere until the Amoeba or Space Crystal shows up?
Or does this not happen because the ships move in the 1st frame, so they'll move one frame per turn until someone actually gets somewhere?
I don't know for sure. If this works as the 1oom code indicates, the basics of movement are as follows: there are up to 20 frames, numbered 0 to 19. Normally, ships move for ~0.5 parsecs on every frame while the frame number is lower than 2 * their warp speed. Normal ships in nebulas can only move on frame 0, frame 1 and then every odd-numbered frame. That means warp-1 ships should move at their normal speed inside nebulas. Transports supposedly move on every even-numbered frame (including 0) inside nebulas, but that can't be completely right because how can the transport get stuck then? It should move at 0.5 parsecs per turn.
(May 5th, 2019, 18:51)Jeff Graw Wrote: Slipstream section describes that movement over only one axis (eg. all x or y movement) gains an extra tenth of a parsec. Eg. a warp 1 fleet moves at a rate of warp 1.1. Therefore, it's actually faster to travel to a destination that is 88 points distant on one axis and 0 on the other than to a destination that is 75 points distant on one axis and 1 on the other. He also notices that the later can rarely move 11 points too, I'm guessing thanks to some kind of rounding which would make the movement vector appear as if it takes place on a single axis given a sufficiently large distance.
This rabbithole is deeper than you want to know :-)
There seems to be several ways to calculate distances, mutually inconsistent and sometimes buggy. For example: in rare cases you get a start with no star within 3 pc. This is a result from the galaxy generator using one distance function and ship movement another.
Also for movement trigonometric tables are used. But for some angles the values in the tables are quite incorrect. Currently 1oom does not copy the erronous tables (perhaps Kilgore Trout Replicant did not notice, but let a very small script generate the tables, correctly). This is the kind of bugs where at least I wonder if 1oom should even attempt to emulate original behaviour.
Quote:I've submitted a bug report together with an easy fix and it's been sitting ignored for over a month now.
No, not ignored. Unnoticed. :-(
Gitlab is very eager to update you, by email, about minor things (like comments about issues) ... but when someone actually submits code - they send nothing.
In my last 1oom playthrough, I got the "caught sabotaging (you were framed)" message from a race I was at war with. Has that ever happened to anyone in MOO1, or is it a bug in 1oom?
To be fair, I was sabotaging missile bases with my anti-matter bombs
(January 15th, 2019, 10:30)eMeM Wrote: Regarding scouts battle my proposition is: simple, easy & average difficulty = AI runs away. Hard & impossible difficulty = human player runs away. Question is what should happen when you have AI vs AI scouts battle. Defending player wins or both stay is also good.
I just wanted to add that the best solution to me would be to just treat no weapons present as no combat until weapons are present. A NAP effect or such. Ships would co-exist, discover, and be able to colonize if they wanted with a scout in orbit.
Looks like I missed the boat on 1oom. Once I stumbled across it and read that aaron no longer maintains it, I immediately started hacking away to implement my pet features and do some bug fixes. Only today I found out that there are 12(!) 1oom projects on gitlab, the most active of which seem to be the forks from RFS and Tapani.
So guys, if you are reading this, could you give us a short update on the status of the project? From the commits its looks like Tapani took over from aaron, then RFS from Tapani and then the both of you joined forces.
I haven't had time to playtest the new version, but it looks like most bugs I spotted already got fixed - esp. the soil enrichment issue which had show-stopper potential (my own fix was slightly different but should only make a difference for adv. soil enr. on planets created or captured fertile).
The scout bug (no colonies shown on scout reports) seem to have survived so far but has a trivial fix:
altered the sdl mouse code to give dosbox-like behaviour (mouse no longer jumps when moves in and out of the window in noncaptured mode)
governor supports reserve boosting buildup (in 3 modes: economic [to 1/2 capacity], military [till bases are up] and complete) or all production (useful on UR and Artifact planets)
made planetary governor-targets (bases, production and reserve-mode) accessible from starmap
uiplanets gives more information (reserve status, nebula); dock and reserve transfer are clickable. Reserves can be taken away again from planets (to allow to undo the governor production boost if the funds are needed elsewhere)
uitech shows bonus amount as a background bar within slider, uses the tech-level display to set to and indicate bonus (great minds think alike) and has additional buttons to equalize spending, set to minimum for bonus and for optimum allocation along the lines of this post for all fields. An auto function does the latter at the beginning of each turn.
in uistarmap, hovering over a planet draws a ruler with the distance in parsec from the currently selected planet.
the message filter allows to filter "finished ..." messages only for governed planets.
when transfering pop, the eco slider gets adjusted automatically
some cheesy game options: select AI (Classic, Classic+), Events (all, good, none), Council (2/3, 3/4, Orion, none), Guardian (normal, weak), Galaxy (normal, wide, high, sparse). The latter will probably have to go again or be done differently, as it does not fit with the nebulas on the galaxy map. The options can be set on the race selection screen and checked in the game-menu.
some minor cosmetic changes and fixes
all new options are squeezed into unused bytes or boolvec-bits in the savefile and default to zero, so should not break savefile compatibility.
If either of you is willing to integrate this stuff into the current git version, please let me know and I will try to merge this into your fork - and also do some code cleanups and maybe make some stuff optional. I have no experience with git, so I would appreciate some recommendations on how to proceed.
