Reversing to Orion - project 1oom

[Juffos]

ignatius, you forgot to link the file. I'd love to have access to those features of yours, stat

[LordKane773]

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:

In uiexplore.c line 48 replace

   

Code:

d->gfx_colony = lbxfile_item_get(LBXFILE_COLONIES, d->g->planet[d->planet].type * 2);

with
   

Code:

const planet_t *p = &(d->g->planet[d->planet]);
d->gfx_colony = lbxfile_item_get(LBXFILE_COLONIES, p->type * 2 + (p->owner != PLAYER_NONE));

I have implemented some new features:

• 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.

cu

ignatius

Man if you already have your own binaries, post em, Tapani/MFS or whoever hasnt even put up binaries for their version and I am not programmer nor a linux user, so if you got em post em, having your own seperate version is pretty cool too.

[RFS-81]

Hi Ignatius,

thanks for the bug report! I also like the changes on the list. As for guidance with git, neatly split each feature into its own commit and make a merge request! If you have any more specific questions, I'd be glad to help.

The current status of the project is that I'm busy with exterminating unchecked string operations. No one's going to write malicious 1oom mods to pwn your computer, but I'd feel dirty putting out a program that reads strings from an external source and then copies them around without checking if it's going to write past the end of a buffer. Making changes that you're not supposed to notice during normal use is not very motivating though, and I have a hard time understanding some bits of code, so I've been very slow.

I haven't heard from Tapani, but I'm still using his repo. It's unfortunate that development has split into so many different forks. It also raises the question of how to name the program. Calling it 1oom seems to suggest that it's the official continuation. Calling it something else also seems wrong because the vast majority of the code is the same as 1oom 1.0. Situations like this must have happened many times in the free software world, but I have no idea what the proper etiquette is in such a case...

[LordKane773]

Hi Ignatius,

thanks for the bug report! I also like the changes on the list. As for guidance with git, neatly split each feature into its own commit and make a merge request! If you have any more specific questions, I'd be glad to help.

The current status of the project is that I'm busy with exterminating unchecked string operations. No one's going to write malicious 1oom mods to pwn your computer, but I'd feel dirty putting out a program that reads strings from an external source and then copies them around without checking if it's going to write past the end of a buffer. Making changes that you're not supposed to notice during normal use is not very motivating though, and I have a hard time understanding some bits of code, so I've been very slow.

I haven't heard from Tapani, but I'm still using his repo. It's unfortunate that development has split into so many different forks. It also raises the question of how to name the program. Calling it 1oom seems to suggest that it's the official continuation. Calling it something else also seems wrong because the vast majority of the code is the same as 1oom 1.0. Situations like this must have happened many times in the free software world, but I have no idea what the proper etiquette is in such a case...

call it zmoo1 or just 1oom 2.0 or something, could you at least put out a couple of test versions soon?

[RFS-81]

I can try. I've never compiled software for Windows, actually. If anyone has experience with cross-compiling or using autotools on Windows and wants to give it a shot, that would be very welcome. I worry that this is going to be a learning experience...

[ignatius]

thanks for the bug report! I also like the changes on the list. As for guidance with git, neatly split each feature into its own commit and make a merge request! If you have any more specific questions, I'd be glad to help.

Thanks for your answer. About neatly splitting features - I fear that boat has passed: I already had the codebase and had not been a git user until yesterday, so it's too late to do the right thing now. :-(

I have, however, already merged my version with your latest commit (18e8754a) from 6th Oct. and it was much easier than expected. This gitk is a real power tool. The only non trivial conflict was the soil enrichment issue, as you decided for another carry-over solution than me (you kept the spent BCs after soil enr. in bc_to_ecoproj, whiIe I decided to charge less for adv. soil if the planet is already fertile). Also I did away with the original rounding bug while you decided to keep it in for compatibility. I solved this by introducing yet another game_num (game_num_soil_enrichment_rounding_fix).

I have the merge itself in a separate commit and am currently busy doing some code cleanups.

I already updated my game_planet_get_slider_text version to reflect the above soil issue, as well as a new governor helper function I use to decide when to reserve-pump a planet in economic buildup mode. As the above also affects the fertile event and fertile planets at game setup, I intend to move your game_turn_soil_enrich to game_misc.c and use it everywhere where planets are made fertile (resetting mappop1 to maxpop2 in the latter case) to avoid duplicating the game logic (and having to deal with two game_nums) even further. I hope, this is ok with you.

I will finish the code cleanups, not add any more features and try to come up with something not too embarrassing to send you for a first look. Maybe you can give it a look and tell me what I need to rip out again.

If necessary, it should be possible, with reasonable effort, to separate my patch into 4 more or less orthogonal feature sets:

1. The mouse handling stuff (mostly in src/hw/sdl)
   
2. The Starmap and Planets stuff (mostly new governor features, the biggest of the 4)
   
3. The Tech stuff (mostly about optimal tech allocation)
   
4. The new game options
   

However, ripping this apart and then putting it back together might introduce more problems than it solves.

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?).

I haven't heard from Tapani, but I'm still using his repo. It's unfortunate that development has split into so many different forks. It also raises the question of how to name the program. Calling it 1oom seems to suggest that it's the official continuation. Calling it something else also seems wrong because the vast majority of the code is the same as 1oom 1.0. Situations like this must have happened many times in the free software world, but I have no idea what the proper etiquette is in such a case...

Me neither, but my take is this: as long as neither aaron nor Tapani object or come up with new versions, there is no conflict. The development has been linear and each developer has pushed the cart a bit further. The current 18e8754a commit can be rightfully seen as a common effort. There are no major other active forks, and thus no need to declare one of the versions "official". No need to get into politics just yet.

Also, feature-wise, there is hardly enough there to warrant a new major number, let alone a new name. So let's cross this bridge when we get there.

@Juffos & Kane

Thanks for your interest. It was actually during writing my post above when I found out that the other gitlab versions even existed. I've just done the merge and the new post-merge version is so far completely untested, I still have some code cleanups to do and then actually play the thing.

When I'm so far as to start the merge process with RFS, I will post a tarball here.

@Kane

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

ignatius

[ignatius]

@RFS

I see you've already put in the scout fix. Here's another glitch (wrong order of arguments) I found when updating my fixbugs.pbx. While you're at it: Maybe fixbugs.pbx should be created automatically by make (until we have something better than doom-style patches for game-options). I have zero experience with autoconf so I didn't dare mess with your Makefile.am.

Code:

diff --git a/src/pbxmake.c b/src/pbxmake.c
index 4fb4ddf..dbb7112 100644
--- a/src/pbxmake.c
+++ b/src/pbxmake.c
@@ -377,7 +377,7 @@ static int make_pbx(const char *filename_in, const char *filename_out)
             SET_LE_32(&buf[PBX_OFFS_ITEM_LEN], tlen);
             SET_LE_16(&buf[PBX_OFFS_ITEM_TYPE], p->itemtype);
             SET_LE_16(&buf[PBX_OFFS_ITEM_INDEX], p->itemindex);
-            lib_strcpy((char *)&buf[PBX_OFFS_ITEM_ID], sizeof(buf) - PBX_OFFS_ITEM_ID, p->itemid);
+            lib_strcpy((char *)&buf[PBX_OFFS_ITEM_ID], p->itemid, sizeof(buf) - PBX_OFFS_ITEM_ID);
             if (0
               || (fwrite(buf, hlen, 1, fd) != 1)
               || ((p->param_type == PARAM_FILENAME) && (!copy_file(p->fullname, p->len, fd)))

cu

ignatius

[LordKane773]

@Juffos & Kane

Thanks for your interest. It was actually during writing my post above when I found out that the other gitlab versions even existed. I've just done the merge and the new post-merge version is so far completely untested, I still have some code cleanups to do and then actually play the thing.

When I'm so far as to start the merge process with RFS, I will post a tarball here.

@Kane

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

ignatius

ah, ok, well hopefully a new release of 1oom happens soon, so for the mean time I am going to use 1.40m

[shallow_thought]

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.

[LordKane773]

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.

ha ha one can only dream.