Reversing to Orion - project 1oom

[RFS-81]

On another front: How do these merge requests work? I'm working with my local git repository. Is this a function of git or of gitlab? Do I need an account there and have to do my own fork first (which I would rather avoid) or could I e.g. mirror my local repository on a webserver and send you the link (which would be better) or could I simply upload my branch to your gitlab account (if so, how?).

Merge/pull requests are a feature of both git and Gitlab. Using Gitlab's version of this feature indeed requires an account and a fork of your own. The git version of the feature simply outputs a piece of text that summarizes the changes and says where to pull them from, which you could then e-mail to me. See the manpage for git-request-pull. That would bypass all the fancy code review features of Gitlab, but for a tiny project like this that's not much of a loss.

I could also go through the diffs by hand. I don't know if I can get git to list you as the author of the commits in that case, but I'll definitely mention you in the commit messgaes.

As for non-Linux binaries: Sorry, I'm exclusively using Linux myself and don't have a Windows install - let alone a compiler suite.

Judging from the documentation, neither did the original author. There are some high-level instructions for cross-compiling and then testing on Wine. I do have a Windows machine and I'd expect compiling natively to be easier. Turns out that autoconf and automake have been ported to Windows, but autoconf still outputs UNIX shell scripts. Those could still be used with Cygwin, it seems... oh well, wish me luck.

Thanks for that other bug, I'll look into it.

The current status of the project is that I'm busy with exterminating unchecked string operations.

Careful. If people proramming in their spare time start keeping themselves to this kind of standard as a matter of course professional developers might follow, and then  us "security specialists" will be out of work.

Well, I'm working for a security company too, though as developer and not pentester. I'm sure you could still find something after I'm done, I'm just going after low hanging fruits There's so much code in there that I haven't even begun to understand...

[Arnuz]

The current status of the project is that I'm busy with exterminating unchecked string operations.

Careful. If people proramming in their spare time start keeping themselves to this kind of standard as a matter of course professional developers might follow, and then us "security specialists" will be out of work.

This cracked me up

[ignatius]

@RFS

Just finished my first game since the merge and code cleanups. Fixed two minor issues (forgot to update production in uiplanets when reclaiming the unspent reserve of a planet, and stopped the governor from building shields when target_bases is set to zero) and found a big one: game_s.nebula_type is not saved to or loaded from the savefile. While the original bounding boxes are retained, the sprites of nebulas are reset. Amazing that nobody noticed that so far. Seems all veterans here play in iron man mode and never reload.

To reproduce the bug, simply create galaxy, check out the nebulas, save and reload.

While it is possible to determine the nebula type from the 4 bounding boxes, this would be a kludge. An elegant fix would break save-file compatibility, however. While we're at it we might as well think about making the format extendible by design to easier accommodate future features, as we might run out of those few precious unused bytes in the current format very soon. We can then also put those pesky game_nums where they belong, so that when 2 people get the same save, they also can be sure to play the same game (a prerequisite for OSGs and Imps).

Am even bolder move would be to switch to an incremental format, where yearly saves are appended and reloading (and hitting next turn) is truncating the file to the older state. This would allow replays (I loved this feature in the original civ), facilitate the creation of game reports and keep the .config/moo dir clean. Also, it would allow efficient compression via zlib or similar.

cu

ignatius

[RFS-81]

Heh, I do play iron-man style and usually only save before quitting, but I've reloaded enough save games while debugging that I should have noticed it. I guess I'm just not good at paying attention

Do you know if it's always possible to derive the type from the bounding box? I don't mind changing the file format, because we always can add it to the saveconv program. But before we do that, we need to think about what we want it to be like, and I'd like to get in a quick fix for the bug you discovered before that.

Incremental saves? Sounds interesting, but I don't know if I want to put in the work

[ignatius]

Heh, I do play iron-man style and usually only save before quitting, but I've reloaded enough save games while debugging that I should have noticed it. I guess I'm just not good at paying attention

Do you know if it's always possible to derive the type from the bounding box? I don't mind changing the file format, because we always can add it to the saveconv program. But before we do that, we need to think about what we want it to be like, and I'd like to get in a quick fix for the bug you discovered before that.

Next on my todo list and the last item to do before we can start the merge with my version. I've separated my patch into 3 orthogonal feature sets in separate branches (uifeatures, absmouse and gameopts) and nebulafix will be the 4th as I don't want to put a version out with known bugs in it.

All patches are against the current 9b9cf636 commit. I intend to clone my git repository onto a website, so that you can pull from it. I will then send you a PM with the merge requests today or tomorrow. If you prefer email, please send me a PM.

Incremental saves? Sounds interesting, but I don't know if I want to put in the work

I have some ideas on how to do it. It's not a pressing issue and there should be some discussion first. Mostly on how much of the legacy stuff, esp. the MOO v1.3 bug compatibility, we are prepared to drag along.

To give an example: My gameopts includes a game option intended to make the fixbugs.pbx more accessible. It was frustrating as hell to tend to each and every game_num and patchable table entry, just to get stuff to work that really should work out of the box - and all that only, so that some hypothetical sicko can play around with the negative fleet bug or take pride in his scout2 design. The whole --relmouse thing was also no fun to work around. It might have been necessary in 1993, to ensure that a game can be played keyboard only and the cursor can be moved by the keypad. But this requires the game to monopolize the mouse and renders your shiny new graphical desktop unusable.

cu

ignatius

[RFS-81]

Incremental saves? Sounds interesting, but I don't know if I want to put in the work

I have some ideas on how to do it. It's not a pressing issue and there should be some discussion first. Mostly on how much of the legacy stuff, esp. the MOO v1.3 bug compatibility, we are prepared to drag along.

To give an example: My gameopts includes a game option intended to make the fixbugs.pbx more accessible. It was frustrating as hell to tend to each and every game_num and patchable table entry, just to get stuff to work that really should work out of the box - and all that only, so that some hypothetical sicko can play around with the negative fleet bug or take pride in his scout2 design. The whole --relmouse thing was also no fun to work around. It might have been necessary in 1993, to ensure that a game can be played keyboard only and the cursor can be moved by the keypad. But this requires the game to monopolize the mouse and renders your shiny new graphical desktop unusable.

Cool, I was just about to start working on a command-line option for enabling the fixbugs fixes. Looking forward to your patches!

The default mode of 1oom already includes some fixes for some obvious programming errors (e.g., fleets inside nebulas don't stop moving when there are no fleets outside nebulas), but some of the choices by the original author do seem very arbitrary. I'd absolutely classify the scoutship cost as an obvious mistake and not a design choice by Simtex. We can consider moving some things from fixbugs to the main game. But how exactly is this related to incremental saves?

Side note, I do think that the whole PBX mod file stuff is overkill. If this had come out 20 years ago, maybe MOO1 could have become the DOOM of turn-based strategy. But now? Ripping out this system would be a lot of work, though. And there are some things that I'd like to keep optional, and making a command-line option for each would also be a mess.

[ignatius]

Cool, I was just about to start working on a command-line option for enabling the fixbugs fixes. Looking forward to your patches!

You should have them by now. Check your PM and/or gitlab page.

The default mode of 1oom already includes some fixes for some obvious programming errors (e.g., fleets inside nebulas don't stop moving when there are no fleets outside nebulas), but some of the choices by the original author do seem very arbitrary. I'd absolutely classify the scoutship cost as an obvious mistake and not a design choice by Simtex. We can consider moving some things from fixbugs to the main game. But how exactly is this related to incremental saves?

One goal of my in-game bugfix option is to assure that when two players have the same save, they get to play the same game (think OSG or Imperium). Not the case now. All gameplay related options need to be reflected in the save file. With incremental saves, you get to split the permanent from the mutable information and game options would reside in the former. Then, all user interface settings should be saved in the file (reenabling some governor options for 50+ planets is no fun at all).

And it's not just pbx-files. There are commandline options. And there is the config file, which develops a life of its own. And it makes a difference whether you set an option via cgf or switch: the former become available sooner in the startup process (cost me the better part of an hour to find out). And of course, there is the UI stuff. I e.g. would have liked to make my ruler feature switchable - but where to put the state in the savefile? No quick solution here, so the feature got postponed.

Also, the whole save-procedure is extremely clumsy. Every value needs to appear in several places and none must be forgotten (as happened with nebula_type). In a word, the saves are a glorified maintenance nightmare and a bottleneck which slows down development everywhere.

If I had my way, we would read/write whole structures like games_s with a length header and new variables come at the bottom and have to default to zero. Need a new variable for your features? Append it to the struct in the header and you've got it. One-stop shop. (How do they call #pragma pack nowadays?)

Side note, I do think that the whole PBX mod file stuff is overkill. If this had come out 20 years ago, maybe MOO1 could have become the DOOM of turn-based strategy. But now? Ripping out this system would be a lot of work, though. And there are some things that I'd like to keep optional, and making a command-line option for each would also be a mess.

It's not just the amount of options. That wouldn't be so bad, even though getting rid of some (most) of the game_nums would be a Good Thing as they clutter the code. The point is that currently, we have not one but 4 ways to set stuff (pbx, cfg, switch and save) and pbx is a lot harder than simply changing stuff in the code and typing "make". The config file would be the right place to put stuff like that - but alas, this is the only thing it cannot do which is why you need a start script anyway and the config turns from an asset into a liability. The command-line interface is fine if 1oom wouldn't treat it as a glorified ed to modify the config file. It's called a file for a reason. Config files shouldn't be changed without explicit user consent.

To end this rant with a more positive outlook: What about new features?

I already mentioned incremental saves with maybe a replay and/or report option and a read-only inspection mode. High on my personal TODO list are customizable galaxies. I generally think that the territorial aspect is not really a strong side of MOO and more variety would be welcome.

A first step would be to improve the galaxy map to handle arbitrary galaxy sizes. As Aaron has already pointed out, the issue here are the nebula sprites. If we rewrite the galaxy map to use higher resolutions, the maximum displayable size would be multiplied by uiscale. It also would look much nicer, even for the standard sizes.

Then, we would need to see where galaxy_size gets used in the code (often for tuning AI stuff) and rewrite those instances with maxx, maxy and galaxy_stars. And finally we would need some cool galaxy generation modes. Bonus points for an option to set the movement penalty in a nebual to warp 1 (OSG mode) and for doing nonstandard topologies (cylinder, torus).

As for UI stuff: With the governor being able to reasonably handle standard planetary development, the most urgent missing feature would be some improved/adv. scanner notification for attacked planets.

cu

ignatius

[ignatius]

@Juffos & Kane & everyone who is brave enough

As promised, here is a tarball of my latest experimental, pre-alpha, minimally tested, work-in-progress version of 1oom, which is based on RFS's current 9b9cf636 commit.

Features

• the -norelmouse switch gives dosbox-like behavior for SDL. When activated, the game starts with ungrabbed but active mouse. Forced mouse moves are disabled and in-game mouse settings are ignored.
  
• 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 (click right of the tech, ind and ship slider or on the bases and production field resp. For bases, the mousewheel can be used)
  
• uiplanets gives more information (reserve status, nebula, unfinished bases); 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 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 (click LEVEL button in the upper right corner) 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.
  
• New research target dialog highlights techs which advance the tree
  
• the message filter allows to filter "finished ..."  messages only for governed planets.
  
• when transfering pop, the eco slider gets adjusted automatically
  
• the New Game race selection screen provides some new game options (see below)
  
• a fix for the nebula type savefile bug
  
• all new options are squeezed into unused bytes or boolvec-bits in the savefile and default to zero, so should not break savefile compatibility.
  

Additional game options are settable with uiextra in the New Game screen. The options are tied to the save file, cannot be altered and can be inspected (even without uiextra) in the Game options screen:

• AI: Classic or Classic+
  
• Events: all, none, late (year 2400+), good (only Rich/Fertile/Merchant/Derelict)
  
• Council: 2/3, 3/4 (of planets settled; quorum is still 2/3), Orion (when Orion is settled), none (for those bored to play diplomatic games)
  
• Guardian: normal, weak (less weapons, less DEF, no ARS/ADC; the idea is to make settling Orion a viable mid-game option instead of an optional afterthought when the game is essentially won)
  
• Rules: pbx, fix bugs (as in fixbugs.pbx), MOO v1.3 (enjoy your doom stacks)
  

The settings override pbx patches and are put in effect at game creation/load time.
Old saves default to Classic, all, 2/3, normal, pbx (i.e. pbx patches get honored).
New games default to Classic+ and the "fix bugs" rules option unless a pbx patch was applied via the -file option (in which case "pbx" is default). So there is no more need to compile fixbugs.pbx yourself.


  1oom-ign-2019-10-17.tar.gz (Size: 752.6 KB / Downloads: 7)

[Jeff Graw]

Awesome work!

[Psillycyber]

Wow, I cannot get 1oom to work. I must be computer-illiterate. I've downloaded the 1oom files and the latest tarball and put all of them in a library, and then copied all of the LBX files from the original game into that library. I also downloaded the SDL2 libraries and put them in the same folder too since I read in the readme that this was also required, although it appears that some of the SDL files (but not all) were already present; when it doubt, I chose to not copy over already-existing files.

But when I try to open 1oom_classic_sdl2.exe, nothing happens.

Do I have to already have DOSBOX running and open 1oom_classic_sdl2.exe from there? I'm confused...