For a forum that prides itself on trying new things, for the love of all that is novel and interesting, please can we have a new QotM? - Krill

Create an account  

 
Reversing to Orion - project 1oom

You just need to extract the archive into a directory, copy all the .LBX files from (a supported version of) MoO 1 (can confirm that the Steam version works) into that directory, and run either "1oom_classic_sdl1.exe" or "1oom_classic_sdl2.exe"

You can also create a shortcut that passess in command line options. I'm using a shortcut that targets: "C:\games\1oom\1oom_classic_sdl2.exe -uiextra -uiscale 2"
Reply

My impressions so far (v0.5, using SDL2 executable, Win10):
  • This project is really awesome, and I still can't believe someone actually went and did it. Thank you x1000.
  • Hotseat multiplayer! Huge anticipation for the networked version.
  • Even with DG (my game) and RoTP out there, good old MoO 1 evokes a different feeling. That's good. Variety is good. Having a version of MoO 1 that plucks some of the low hanging fruit and fixes some of the remaining issues and annoyances while remaining more or less faithful to the original is something we can all get behind.
  • Being able to change galaxy zoom level is huge. With -uiextra flag enabled though, the zoom in/out bindings seem the reverse of what they should be. Mouse wheel forward should zoom in, and backwards should zoom out, as is standard across multiple industries.
  • Music often cuts out during scene changes, and then comes back in just prior to exiting that scene. Eg. GNN, Research.
  • Mouse pointer handling needs lots of work. I have to set my mouse to 200dpi on a 40" display(!) to make it not completely unusably oversensitive. -norelmouse seems to feel worse too. This should be at or near top priority to fix, since it influences usability to such a huge degree and sloppy cursor movement leaves a very poor first impression.
  • Maybe I just haven't played MoO 1 in too long, but the AI seems to be severely handicapped versus what I remember. Played a few games on hard, but the AI tended to get very stagnant and failed to expand much at all a lot of the time, even given obvious targets to colonise. What does the "classic+" AI do? Performance still seemed poor with that enabled.
  • No galactic council yet. I'm not a big fan of the galactic council, so I don't really mind this.
  • Overall, I don't think that 1oom is a replacement for regular old MoO 1 yet, but it's very close. The two things that get in the way are the AI regression and the sound bugs. After those are fixed, I don't see there being any reason to boot up the old DOS version.
Things I'd like to see moving forward:
  • A launcher. Needing to pass in command line arguments to customise the experience isn't ideal, and the majority of users are going to miss out on features that they would otherwise enjoy.
  • There's also the question of what to set as the default options. I'd argue that something akin to "classic+" makes the most sense here.
  • For example, being able to zoom the galaxy map in and out is a huge and obvious improvement to the original game with no real downside. 99.9% of users are going to want to play with that option. Therefore, it makes sense that it would be enabled by default. Someone who is a zealous enough purist, or is just curious about the vanilla experience, will have little trouble finding and disabling that option. But users who aren't going to go in and tweak all the various options will be better serviced by having map zoom available by default.
  • Something akin to "classic+" can then sit between "classic" and "enhanced." The general idea being that classic+ features could be very non-controversial, adding to or subtly improving the original experience rather than supplanting or replacing them. "Enhanced" features could probably be labelled as such when they lead to a highly tangible change in the overall experience, even if they appear to be obvious improvements to the formula.
  • Some quality of life features I'd like to see, regardless of whether they fit into classic+ or enhanced categories would include:
  • Combat Autoresolve. This is the big one. Whenever MoO 1 slows down to a crawl, it's because there are too many insignificant combat events each turn that take up a disproportionate amount of time. The ability to skip combat events that don't matter so much would improve pacing by leaps and bounds.
  • Better feedback on the galaxy screen regarding what is explored vs unexplored. SoTS 1 does this quite good where an unexplored system shows up as a star, while an explored system shows up as a planet.
  • Feedback regarding range, specifically which worlds are in or out of range, could also be a good thing to have. On the other hand, there is a risk of making the screen too busy. The range circles in RoTP always felt a bit too in-your-face for my taste (although admittedly they're probably still WIP). In any case, while I would like better visual feedback, I'd also prefer that the main screen looks like a view of space rather than a dispatching program.
  • Keeping a fleet selected after sending a portion of it rather than deselecting, as well as the ability to send ships by clicking on a star. It's always a bit of a hassle in MoO 1 to send, say, six different scouts out individually because you need to re-select the fleet each time and there's a lot of mouse travel involved.
  • Relative rather than absolute sliders (eg. sliders can be set independently of one another, where two sliders at 100% will split allocation evenly between them). In practice, this reduces UI fiddling to about a third of what it would be otherwise. This is what we do in Dominus Galaxia, so I may not be entirely unbiased... but I also haven't met any MoO 1 vets who still prefer absolute sliders after spending some time with relative.
  • Enforcing the "can't send a retreating fleet back to the system it just retreated from that same turn" rule. Seems obvious enough. This easily could have been a change in 1.4 or 1.5 if Simtex had kept patching the game.
  • A similar case can also be made for the ultra-rich reserve farming exploit (eg. give stimulus to an ultra rich world that is producing reserves). DG solves this one by not applying production modifiers to reserve infusion. That does, however, somewhat change the feel of things, which in a perfect world should be avoided. Any other fix would seemingly need to create an inconsistency in the game rules around ultra-rich planets and reserves though. It's a tough one, but with the prospect of competitive multiplayer I think it probably should be addressed in the default settings as the least evil course of action.
  • Better automatic adjustment of sliders to make sure that allocation isn't wasted on ecology. That you can sometimes have an extra tick or two in ecology than is needed to keep a colony clean seems more like a bug or an oversight than anything that could have been intended. I know that there's a "governor" that can be toggled with -uiextra, but I don't always want to use it. I do always want to be putting in the minimum required to keep my colonies clean though, unless I'm actively terraforming or cloning of course.
Reply

So I booted up the latest development build (v0.5-20-g929d1e1-2018-07-04-win32) and wow, it looks like a lot of my suggestions are being actively worked on. Thanks!

New impressions:
  • Uiscale doesn’t drive anything besides map scale and cursor scale, correct? The former should be divorced from the later now that mouse wheel zoom exists. As it stands, one can’t zoom out to see the entire screen on a huge galaxy unless they set a high scale factor, which also makes my cursor tiny. A somewhat odd relationship. Zoom should not be bounded by uiscale, and uiscale should just become cursorscale I think.
  • Zoom is sometimes snappy, sometimes laggy, and sometimes skips an input entirely.
  • From time to time the mouse cursor gets bounded to a rectangular subset of the screen. Can be gradually massaged back to the full area by tracing a path along the edge of the bounded rectangle. Not sure yet what triggers the issue. Seems to have something to do with changing screens. I've also noticed it sometimes when changing focus to a different window. Loading a game with uiscale 3 seems like a good way to reproduce.
  • Fix to ECO overshoot is great! But….
  • Variable slider granularity is pretty problematic, at least in my opinion, and the fix to ECO overshoot highlights this.  
  • In MoO 1, slider granularity is fixed. Regardless of whether you click and drag, or press one of the buttons on either side of a slider, you have the same number of “ticks” to allocate.
  • The ECO overshoot fix, clicking and dragging, and mouse wheel allocation seem to have a much finer granularity than is standard for MoO 1. Arguably this is bad because it creates inconsistency, but also hurts the spirit of the game. MoO 1 is supposed to be micro-light. But if one can, say, hunt for the exact spot that builds the last factory without shunting additional production to the reserve at a 50% penalty, or a similar scenario with missile bases or starships or whatever, then that introduces a significant amount of micro when one wishes to play optimally.
  • Yes, the waste that MoO 1’s default granularity unavoidably creates is a bit evil, but introducing the ability to eke out an extra little bit of production via time consuming and strategically empty micro management is much worse imho. Especially for a project with multiplayer ambitions.
  • Besides which, the increased granularity for mousewheel manipulation of sliders makes that form of control very slow.
  • And also, the systems that utilise increased granularity don’t seem to do so entirely consistently. For example, below is a save file where Hyades is producing 2.2 fact/yr (this is one turn after sending transports to Altair, which creates one turn of waste, which triggers an eco-readjustment where previously the game would overcompensate). Activating the governor reduces this to 2.1 fact/yr and it seems to be impossible to get it back up to 2.2 by using the existing UI tools, even those with greater granularity.
  • Mousewheel up -> more allocation is probably going to be more intuitive to most people than mousewheel up -> less allocation. I think I remember Ray also used the later same scheme in early versions of RoTP, but recent builds appear to use the former. DG also uses the former. On the other hand, I can kind of see an argument for the later since, iirc, if a webpage can be scrolled horizontally and not vertically, mousewheel down will move it rightways. 
  • Perhaps ECO readjustment should apply after sending transports drops a colony down from clean to waste instead of (or in addition to, to catch other possible triggers) sometime later during turn processing?
  • Combat autoresolve is very welcome. Needs to give a summary of both sides before and after combat to be useful though -- something as simple as the number of huge, large, etc. ships + missile bases would probably do it, but the more detail the better. I’m assuming this is already planned and just hasn’t been gotten around to yet.
  • In practice, double clicking to send a fleet doesn’t work very well with MoO 1’s “click to focus on this area” camera movement since the second click will typically end up in a different position. I can think of a few possible solutions here: In some situations you could wait a few frames for another input before moving the camera, but that might feel odd. You could change to a “drag to move” scheme, which I think is significantly superior (both RoTP and DG do this), but it’s a also huge change to the feel of the game so that's arguably a bit iffy. Or perhaps just use right click to move instead of double click?
  • Not deselecting the remaining ships seems to work OK when you know what to expect, and it’s definitely a time saver, but isn’t very intuitive with the current UI. As it stands, I'm not sure if it's up to snuff for inclusion, or at least maybe should have it's own command line option rather than being captured under the rather large umbrella of -uiextra. Yeah, I know I suggested the feature, but even I was taken aback a bit when I first encountered it! DG has a number of visual cues for fleet movement (including animating the sent ships moving from the right to left hand side of the planet, and then the targeting reticle thing zooming in to the still selected fleet) that help with this, but are most probably out of scope. It may be that it’s too difficult to make the feature intuitive... but maybe there are some things that could help. Selecting the remainder of the fleet rather than attempting to select the same number and type of ships that were sent previously is probably significantly more intuitive (even if it’s a bit less useful versus, for example, being able to rapidly send out single scouts). Showing both the number of ships that are selected *and* the number that exist in total in the fleet would certainly be a big help. Eg. Instead of “1” it could show “1/4”. Perhaps if the later is done, the former would be more intuitive...

Additional ideas/thoughts/requests:
  • I was going to mention this before but forgot to, and perhaps it goes without saying, but the value of auto resolve is directly linked to the ability of the AI to not do really dumb stuff in combat. Eg. Failure to deal with repulsors, retreating your huge doomstack from insignificant single missiles, etc. This would probably make the game a whole lot more fun in general as well.
  • At least to an extent. MoO 1's combat is probably simple enough that an AI could more or less "solve" it, but if that were to happen the combat system would most likely start to feel superfluous and meaningless.
  • Something that’s arguably more of a bugfix than an enhancement would be changing the fleet line from green to red when selecting an out of range destination for a fleet that is already departing.
  • A great enhancement would be better handling of overlapping fleets. One of the great annoyances in MoO 1 is trying to select something that is being blocked by other objects. In DG (I can't speak for RoTP, but my assumption is that Ray does the same) when a mouse click occurs that hits multiple objects each click cycles selection to the next object. Eg. if A, B, and C are overlapped and you click the same spot four times, instead of A -> A -> A -> A you get A -> B -> C -> A.
  • A somewhat related but less crucial enhancement would be to departing fleets so there's some ability to discriminate (besides clicking each instance of a departing fleet graphic multiple times) whether one or multiple fleets belonging to the same empire are departing from a system. RoTP draws each departing fleet separately even when they belong to the same empire. DG displays a number above a departing fleet graphic to denote multiple fleets departing. Eg. if three fleets of the same empire are departing a system, a small "3" is drawn just above and to the right of that fleet's icon.

https://www.dropbox.com/s/hgxk460m9l5mqo...6.bin?dl=0
Reply

The project coder replies:

(July 2nd, 2018, 22:49)Jeff Graw Wrote: Music often cuts out during scene changes, and then comes back in just prior to exiting that scene. Eg. GNN, Research.

I could not reproduce this (on Linux) but did some changes. Is this fixed now?

Quote:-norelmouse seems to feel worse too. [...] From time to time the mouse cursor gets bounded to a rectangular subset of the screen.

The problem is a result of -norelmouse. Do not use it.

Quote:Maybe I just haven't played MoO 1 in too long, but the AI seems to be severely handicapped versus what I remember.

Found a few AI bugs. Fixes appearing in v0.5-27 in a development build soon. More testing needed.

Quote:What does the "classic+" AI do?

See doc/list_gamediff.txt.

Quote:No galactic council yet.

Council is implemented. If it does not trigger even with the conditions met, send the save.

Quote:A launcher.

Out of project scope.

Quote:Needing to pass in command line arguments to customise the experience isn't ideal, and the majority of users are going to miss out on features that they would otherwise enjoy.

Most of what the command line arguments do can be accomplished by editing the config file. The notable exception is -file.

Quote:There's also the question of what to set as the default options.

That particular bikeshed will have the color of v1.3. The out-of-box experience is meant to be very close to what the DOS binary provides.

Quote:Uiscale doesn’t drive anything besides map scale and cursor scale, correct?

Sliders too.

Quote:Zoom should not be bounded by uiscale, and uiscale should just become cursorscale I think.

Here's how it works: -uiscale N the multiplies the internal resolution (320x200) and everything except map/cursor/sliders are draw with NxN blocks instead of 1x1 pixels. To implement map zooming any other way needs to address the issue of nebula graphics not having the correct size. The problem is not insurmountable but requires far more effort than I'm willing to put in it.

Quote:In MoO 1, slider granularity is fixed. Regardless of whether you click and drag, or press one of the buttons on either side of a slider, you have the same number of “ticks” to allocate. The ECO overshoot fix, clicking and dragging, and mouse wheel allocation seem to have a much finer granularity than is standard for MoO 1. Arguably this is bad because it creates inconsistency, but also hurts the spirit of the game. MoO 1 is supposed to be micro-light.

That number of ticks is 4. The number of ticks allocated by pressing the +/- keys is 5. This means that fine control is possible even in v1.3. Using the defaults gives the v1.3 experience for those who choose to ignore this fact.

Quote:Besides which, the increased granularity for mousewheel manipulation of sliders makes that form of control very slow.

This is intentional. The mouse wheel is for fine adjustments.

Quote:And also, the systems that utilise increased granularity don’t seem to do so entirely consistently. For example, below is a save file where Hyades is producing 2.2 fact/yr (this is one turn after sending transports to Altair, which creates one turn of waste, which triggers an eco-readjustment where previously the game would overcompensate).

Thanks, I will look into it.

Quote:Mousewheel up -> more allocation is probably going to be more intuitive to most people than mousewheel up -> less allocation.

Might as well add an option for this.

Quote:Perhaps ECO readjustment should apply after sending transports drops a colony down from clean to waste instead of (or in addition to, to catch other possible triggers) sometime later during turn processing?

If by this you mean triggering readjustment when clicking the Trans button: good idea.

Quote:Combat autoresolve is very welcome. Needs to give a summary of both sides before and after combat to be useful though -- something as simple as the number of huge, large, etc. ships + missile bases would probably do it, but the more detail the better. I’m assuming this is already planned and just hasn’t been gotten around to yet.

Was not planned. Will look into it.

Quote:In practice, double clicking to send a fleet doesn’t work very well with MoO 1’s “click to focus on this area” camera movement since the second click will typically end up in a different position.

This is why it's "clicking the destination again" instead of "double clicking".

Quote:Or perhaps just use right click to move instead of double click?

I'll try this.

Quote:Not deselecting the remaining ships seems to work OK when you know what to expect, and it’s definitely a time saver, but isn’t very intuitive with the current UI. As it stands, I'm not sure if it's up to snuff for inclusion, or at least maybe should have it's own command line option rather than being captured under the rather large umbrella of -uiextra.

The umbrella will only grow.

Quote:Selecting the remainder of the fleet rather than attempting to select the same number and type of ships that were sent previously is probably significantly more intuitive (even if it’s a bit less useful versus, for example, being able to rapidly send out single scouts).

I'll do this. It has the benefit of requiring less code.

Quote:Showing both the number of ships that are selected *and* the number that exist in total in the fleet would certainly be a big help. Eg. Instead of “1” it could show “1/4”.

"32000/32000" is a lot of pixels to cram in.

Quote:I was going to mention this before but forgot to, and perhaps it goes without saying, but the value of auto resolve is directly linked to the ability of the AI to not do really dumb stuff in combat. Eg. Failure to deal with repulsors, retreating your huge doomstack from insignificant single missiles, etc. This would probably make the game a whole lot more fun in general as well.

The combat AI can have some small fixes in the Classic+ AI, but significant improvements will go to "Modern" (or whatever) AI.

Quote:MoO 1's combat is probably simple enough that an AI could more or less "solve" it, but if that were to happen the combat system would most likely start to feel superfluous and meaningless.

Patches implementing this (outside Classic AI) are welcome.

Quote:
  • Better feedback on the galaxy screen regarding what is explored vs unexplored.
  • Feedback regarding range
  • Relative rather than absolute sliders

These likely won't happen. I'll look into the rest of your ideas.

Thanks for the feedback! This is very valuable input.
Support Free Software projects!
Reply

(July 5th, 2018, 22:46)1oom_aaron Wrote: I could not reproduce this (on Linux) but did some changes. Is this fixed now?

Haven't ran into again yet. I'll let you know if I do!

Quote:Council is impleCouncil is implemented. If it does not trigger even with the conditions met, send the save.mented. If it does not trigger even with the conditions met, send the save.

I haven't been looking specifically for conditions, but I haven't seen the council vote come up once. Maybe a byproduct of an AI bug that prevents the conditions from coming true? Or possibly just random chance. I'll keep an eye out.

Quote:That number of ticks is 4. The number of ticks allocated by pressing the +/- keys is 5. This means that fine control is possible even in v1.3. Using the defaults gives the v1.3 experience for those who choose to ignore this fact.

That's actually really interesting. I never realised that. I assume it's an oversight though. Imagine the amount of micro management that would be required to min-max every planet using this trick... doesn't seem like something Simtex would have intended given the design of the rest of the game.


Quote:Most of what the command line arguments do can be accomplished by editing the config file. The notable exception is -file.

Hmm... I just noticed that passed in command line options get written to the config file. Might not be an optimal behaviour, since the assumption tends to be that a command line option is no longer used when it's removed from a shortcut.


Quote:"32000/32000" is a lot of pixels to cram in.

Yeah. Absent a UI overhaul it would need to support writing the number on two lines. But if the remainder of the fleet gets selected then this probably isn't an issue. Regarding how intuitive fleet re-selection is or isn't, you'll probably want to find virgin testers since once one understands how it works it's difficult to provide objective feedback. 



Anyway, thanks again for all the hard work. Maybe when I'm less busy I'll look into adding some of those out of scope features that I think would be helpful (that's the beauty of open source projects) smile

In the meantime, found another issue. With -uiscale 3, load the game and zoom in. Observe garbled green text in the lower right corner. Tested with 0.5-27.

https://www.dropbox.com/s/hgxk460m9l5mqo...6.bin?dl=0
Reply

One idea for making re-selecting the remainder of fleets after sending a part of said fleet a bit more intuitive would be to deselect the star that had just been sent to. When the star stays selected, it almost feels like maybe nothing happened.

Tried out the latest auto resolve changes. They definitely make the feature usable now! 

Would probably be a small improvement to always have the player's forces displayed on the left side of readout.

Ideally, you would be able to differentiate retreated from destroyed ships in the outcome. As it stands, your entire fleet might have retreated even if it looks like they've been destroyed. There's certainly an issue of screen real estate to show both though. I suppose you could move the after action report to the right and present it like a situation report. Otherwise, I suppose you could change between retreated and destroyed readouts every x seconds.
Reply

The project coder replies:

(July 6th, 2018, 23:11)Jeff Graw Wrote: For example, below is a save file where Hyades is producing 2.2 fact/yr (this is one turn after sending transports to Altair, which creates one turn of waste, which triggers an eco-readjustment where previously the game would overcompensate).

Somehow the sum of sliders is 101. Fiddling with them fixes it to 100. Having the undo save (slot 8) would be helpful, but supposedly long gone now.

EDIT: This is a bug in v1.3. The function game_update_eco_on_waste is run on loading the game and on next turn (and possibly at other times). It adjusts the sliders incorrectly. Added an optional fix via PBX number waste_adjust_fix.

Quote:I haven't been looking specifically for conditions, but I haven't seen the council vote come up once.

If the galaxy is 2/3 colonized then a council vote should have come up. Saves proving otherwise would be interesting.

Quote:Imagine the amount of micro management that would be required to min-max every planet using this trick... doesn't seem like something Simtex would have intended given the design of the rest of the game.

I can picture an OCD eye-twitch or two happening somewhere. I won't reduce uiscaled slider granularity based on design speculation.

Quote:Hmm... I just noticed that passed in command line options get written to the config file. Might not be an optimal behaviour, since the assumption tends to be that a command line option is no longer used when it's removed from a shortcut.

That assumption is news to me. The current behavior stays but may get documented better at some point.

Quote:Absent a UI overhaul it would need to support writing the number on two lines.

I went with this and keeping the sent amounts. (v0.5-33)

Quote:Regarding how intuitive fleet re-selection is or isn't, you'll probably want to find virgin testers since once one understands how it works it's difficult to provide objective feedback.

At this stage of the project I really want to get rid of the remaining AI regression. Virgins are not very helpful in this endeavour; someone who ras ravaged the galaxy repeatedly has the insight to spot such irregularities.

While waiting for the bug reports, I'll dabble with your UI ideas. I doubt the MOO experts have trouble in grasping them; stomaching is an another matter.

Quote:In the meantime, found another issue. With -uiscale 3, load the game and zoom in. Observe garbled green text in the lower right corner. Tested with 0.5-27.

Thanks, I'll look into it.

Quote:One idea for making reelecting remainder of fleets after sending a part of said fleet a bit more intuitive would be to deselect the star that had just been sent to. When the star stays selected, it almost feels like maybe nothing happened.

Good idea.

Quote:Ideally, you would be able to differentiate retreated from destroyed ships in the outcome. As it stands, your entire fleet might have retreated even if it looks like they've been destroyed.

I'll see what I can do.
Support Free Software projects!
Reply

(July 6th, 2018, 23:33)1oom_aaron Wrote: I went with this and keeping the sent amounts. (v0.5-33)

Cool. Tested it out and I like it! I'd suggest changing the color of one of the lines of text to make them easier to differentiate (perhaps make the top white?) It's not much a problem when there are only one or two ship types being manipulated, but when you have a full fleet the bottom line in one icon kind of fades into the the top line of the next, and so forth.

Another idea would be some way to differentiate "everything is selected" from "some subset is selected". Eg. only display the top line when less than all of the ships belonging to that design are selected? Might need some play testing to see if that's intuitive or not.
Reply

The project coder replies:

(July 2nd, 2018, 17:56)Psillycyber Wrote: I would love to playtest this thing, but the installation instructions are not intuitive for a tech dummy like me.  Any chance there will be an installation wizard at some point to find the needed files from the original game on one's computer, extract/copy them to a new folder, and add in the new files?  Or am I fundamentally misunderstanding how this works?  

This had me stumped for a while. The Windows installation instructions in 1README.txt are only a few simple lines. Perhaps you downloaded the source code tarball (1oom-0.5.tar.gz) and were scared away by INSTALL? Fear not, that is for people who compile code and can be safely ignored by others.

For the benefit of the regular Windows-using players, the (simplest) installation process:
  1. Download the latest Windows release (1oom-v0.X-win32.zip) from the releases page.
  2. Extract the zip to somewhere, henceforth the "1oom directory".
  3. Find your MOO1 LBX files and copy them to the 1oom directory.
  4. Now you have 1oom_*.exe, various DLL files and the LBX files in the same directory.
  5. Click on 1oom_classic_sdl1.exe (or 1oom_classic_sdl2.exe) to play.

There will not be any sort of install wizard.

To enable the fancy new UI features:
  1. Run and exit 1oom_classic_sdl1.exe (or _sdl2.exe) at least once.
  2. Open 1oom_config_game_classic_sdl1.txt (or _sdl2.txt) in a text editor.
  3. Edit the "1" in the line "ui.uiscale = 1" to 2 or 3 for viewing more of the galaxy at once.
  4. Edit the "false" in the line "ui.uiextra = false" to "true" for the new UI improvements.

To update to latest development build:
  1. Download the newest file from the development buils page.
  2. Extract the 7z to somewhere.
  3. Copy the extracted files to the 1oom directory, overwriting the old EXE files.

I hope this helps.

someone, inevitably Wrote:Why are there both sdl1 and sdl2 versions? Which should I use?

1oom aims for portability. This means supporting platforms/operating systems for which SDL2 is not available but SDL1 is. One example is Windows 98 (not that 1oom has ever been tested to work on it). Use whichever works best for you.

(July 4th, 2018, 23:30)Jeff Graw Wrote: Fix to ECO overshoot is great!

Just to clarify: the eco_slider_slack option only kicks in when population is at max. ECO can still overshoot when sending transports from a developing planet. The adjustment back to minimum clean is problematic to automate as the player may have adjusted the slider to grow population faster. The governor can help here.

Quote:Eg. if three fleets of the same empire are departing a system, a small "3" is drawn just above and to the right of that fleet's icon.

Too few pixels to work with and too cluttery for my taste.

Quote:
  • Better feedback on the galaxy screen regarding what is explored vs unexplored.
  • Feedback regarding range

I tried out giving uncolonized stars in range the names "?"/"..." based on if it was explored and a darker color if it was in reserve fuel range. Couldn't find neutral colors that couldn't be mixed up with the white banner colors or the background stars. Gave up for now.
Support Free Software projects!
Reply

(July 10th, 2018, 01:45)1oom_aaron Wrote: Just to clarify: the eco_slider_slack option only kicks in when population is at max. ECO can still overshoot when sending transports from a developing planet. The adjustment back to minimum clean is problematic to automate as the player may have adjusted the slider to grow population faster. The governor can help here.


Ah, fair enough. In that case, doing the adjustment right after sending transports (only if the resulting ECO position would lead to waste) instead of during turn processing could be a better idea.

Alternatively, or more likely additionally, cloning could display to the tenth decimal place when <10 POP/Turn. This is assuming that values above minimum clean but below +1 POP give some unlisted benefit to POP growth, which admittedly isn't something I've thought about before but judging from your comment sounds like the case. Besides giving more information to the player, this way when one sees something like "+0.1 POP" it's a marker that some amount of overshoot has occurred, rather than needing to play around with the slider to tell.
Reply



Forum Jump: