Reversing to Orion - project 1oom

[Jeff Graw]

Questions still stand. What would make the scrolling more tolerable? You could try if this helps:

I think the scrolling is totally bearable, if a bit antiquated, for a keyboard and mouse interface. But click-to-center is going to be totally hellish on a small touchscreen if the project is ever ported to mobile. In fact, attempting to play MoO in DosBox on a mobile phone demonstrates this already.

Ideally for a mobile interface you would move the viewport as your drag your finger/cursor across it, and clicking/tapping on an empty space would then not do anything. Probably simple enough in terms of adding basic support in there, but the ratio of finger-to-viewport movement and other intangibles, such as discriminating between scrolling and selection inputs by looking at things like click speed or the amount of cursor movement between down and up mouse button events, can greatly influence reception. 

From a UX perspective, I think drag-to-move is pretty close ideal, but can sometimes be deceptively difficult to get "just right" when there's overloading of selection and scrolling inputs, as is the case in MoO 1... assuming everything stays on the left mouse button.

For a keyboard and mouse interface, panning with arrow keys or WASD is also a nice addition. Some people like the viewport to pan when the cursor is near to one of its edges, although personally I'm not very fond of that (which may have something to do with using multiple monitors).

[1oom_aaron]

The project coder replies:

I think the scrolling is totally bearable, if a bit antiquated, for a keyboard and mouse interface.

I was mostly asking the person with the motion sickness issues, but your input is appreciated.

You bring up good points on issues with a mobile port. I'll take the opportunity to state that I have no HW to run such a port and thus won't attempt one. A patch implementing such a port would be great. (Same goes for gamepad/joystick support which could be useful for GBA/PSP-style HW.)

From a UX perspective, I think drag-to-move is pretty close ideal

From an ergonomic perspective, I think drag-to-move is a blight upon humanity. Can't think of a more RSI-inducing human-computer interaction. Of course, things differ between mouse and touchscreen. Also consider the amount of mouse movement required to move from one corner of the galaxy to another.

MOO1 also does strange things like acting on release (try dragging ECO to 0 and releasing over the ECO text: the lock toggles).

I won't attempt to implement drag-to-move. I won't shoot down a patch implementing it as an option.

For a keyboard and mouse interface, panning with arrow keys or WASD is also a nice addition.

MOO1 kind of has this with Ctrl-KeypadDirection. WASD would make a lot more sense. I'll play with the idea of using that in uiextra.

[Jeff Graw]

From an ergonomic perspective, I think drag-to-move is a blight upon humanity. Can't think of a more RSI-inducing human-computer interaction. Of course, things differ between mouse and touchscreen. Also consider the amount of mouse movement required to move from one corner of the galaxy to another.

You think that's bad? Consider the amount of mouse movement required to move from Toronto to Tokyo in Google Earth!

Yeah, I already feel bad about being snarky since, in my eyes, you're doing God's work. Bless you. The point though is that implementation matters a lot. You don't necessarily need 1:1 movement between the drag and the viewport, you don't need the same behavior on every zoom level, you can exploit things like "zoom in relative to my cursor location" to quickly move from one end of an image to another, etc, etc, etc. UX is as much about how a magnitude of tiny intangible variables all come together as much as it is anything big picture.

But yes, a naive implementation of drag-to-move on an otherwise stock version of MoO would probably not be the best, at least on PC, for sure.

[Juffos]

Here is a save showcasing the enemy's inability to design new, better ships. Bulrathis are attacking in 2475 with retro engine laser ships, even though they have access to antimatter engines and weapons of similar level.

v0.8-6win32

[pebaha]

The project coder replies:

re-centering

First let's agree on the terms: to "center" to a planet means to instantaneously jump the map view so that the planet is at the center of it (or near enough given the map borders) and to "scroll" is to slowly pan the map to a given position when clicking on an empty spot.

I'm fairly certain that v1.3 centers to a clicked (or F2'd) planet. I'll check again and come back to eat these words if it's not the case.

The scrolling animation is a lot smoother in 1oom. What would help? Make that optionally instantaneous/slower/faster? Drag to move?

When is centering acceptable?

How would you ideally move to a different part of the map?

I'm wary of adding a plethora of UI options, but am willing to consider some for issues that prevent playing.

EDIT:

You were right. v1.3 does not center. Words eaten, bug fixed in v0.8-3 (available now/soon? in the resurrected devbuild page). Sorry about that.

Questions still stand. What would make the scrolling more tolerable? You could try if this helps:

Code:

# This is a PBXIN file.
# It removes the two layers of stars in the starmap.
# Use "1oom_pbxmake nostars.txt nostars.pbx" to make the PBX file.
# Then "1oom_classic_sdl1 -file nostars.pbx" to use it.

0,"Remove parallax scrolling"
1,"Removes the background stars used for starmap parallax scrolling."

# The next three lines remove the closer stars.
# Add a '#' in front of all 3 lines to keep them.
5,starmap.lbx,1,0,"\x01\x00\x01"
5,starmap.lbx,1,0x16,"\x1c\x00"
5,starmap.lbx,1,0x1a,"\x01\xff"

# The next three lines remove the farther stars.
# Add a '#' in front of all 3 lines to keep them.
5,starmap.lbx,2,0,"\x01\x00\x01"
5,starmap.lbx,2,0x16,"\x1c\x00"
5,starmap.lbx,2,0x1a,"\x01\xff"

Yes, we're in agreement with respect to the definitions regarding re-centering and scrolling. Nice to see that it will be possible to click on a planet without shifting the map view in a future build, just like classic MoO!

I tried using your pbx file, but removing background stars doesn't really make a difference for me. It seems that the combination of a slight delay after clicking to pan the map and the following smooth animation is what's causing motion sickness. If clicking an empty area on the map instantly re-centered the map, I don't think it would be an issue.

For whatever reason, the sluggish panning in classic MoO doesn't give me motion sickness.

[1oom_aaron]

The project coder replies:

Yeah, I already feel bad about being snarky since, in my eyes, you're doing God's work.

No worries. Snark livens up the discussion. I'll continue to wiggle my noodly appendages.

The point though is that implementation matters a lot.

Good point and musings.

But yes, a naive implementation of drag-to-move on an otherwise stock version of MoO would probably not be the best, at least on PC, for sure.

As it could be an option, being the best is not that important. Anyone interested in implementing this, see ui/classic/uiobj.c type 0xb. Patches welcome.

Somewhat related, I added WAcceptShipsDesign UHJK in v0.8-8. Breaking MOO1 hotkeys vs. modern conventions... the answer is probably "make the keys configurable" but I'm not too keen on that either.

Here is a save showcasing the enemy's inability to design new, better ships. Bulrathis are attacking in 2475 with retro engine laser ships, even though they have access to antimatter engines and weapons of similar level.

Thanks! Next step is for me to check with 1oom_saveconv -o t which years the AI designed the ships and ask for the 1oom_save_2xxx.bin files, hoping that you enabled -yearsave.

EDIT:

The save pointed out that the AI had built only/mostly the oldest ships. I found a bug after some digging. The AI redesigns ships and reassigns what ships to build every 12..20 years (ai_p2_countdown). The code selecting which ships to build sorts the ships by year; there was a bug in the sorting (stupid mistake on my part) which lead the AI to ignore the latest ships. Bug fixed in v0.8-10. Thanks for reporting! Please test if it helps.

The latest AI design is from 2468, so if you have 1oom_save_2468.bin then continuing from that should show the AI building newer ships.

It seems that the combination of a slight delay after clicking to pan the map and the following smooth animation is what's causing motion sickness. If clicking an empty area on the map instantly re-centered the map, I don't think it would be an issue.

Removing the delay could be rather tricky. I'll add an option for instant jump and/or scroll speed. EDIT: Option added in v0.8-10, available now in git and by the time you read this in the devbuilds page.

[Juffos]

v0.8-10win32

The AI is designing and using new ships as it should now, though it seems it doesn't prioritize speed enough and most ships have II armor - I'm not sure if this is vanilla behavior or not.

In this save you can see the white Sakkra fleet move towards Phantos - the uninhabited green star - and upon arrival in 2 turns the fleet becomes 65535 huges and 65535 larges. They depart as 32000 both the turn after. I don't believe the 32000 mediums either were built the normal way.

[1oom_aaron]

The project coder replies:

The AI is designing and using new ships as it should now, though it seems it doesn't prioritize speed enough and most ships have II armor - I'm not sure if this is vanilla behavior or not.

Good to hear. I'll peek at the speed and armor selection code.

EDIT: Good eye! The II armor is not vanilla behavior but a translation bug. Fixed in v0.8-14.

Speed as in engine type or combat speed? I can't spot a bug in either selection code, which does not rule it out yet.

Also, if you haven't yet, please set game.yearsave = true in your config file and take a backup of all the 1oom_save_2*.bin when encountering a bug that may span many turns, such as these design quirks.

In this save you can see the white Sakkra fleet move towards Phantos - the uninhabited green star - and upon arrival in 2 turns the fleet becomes 65535 huges and 65535 larges. They depart as 32000 both the turn after. I don't believe the 32000 mediums either were built the normal way.

Heh, I was waiting for this to pop up!

EDIT: Fixed in v0.8-14. It was negative overflow in AI-AI battles due to intermediate result not fitting in 32 bits (fixed by using 64 bit math).
It's a MOO1 bug; those 65k stacks show as negative amounts in v1.3.

If you wish to salvage the save:

1. 1oom_saveconv -o t 1oom_save1.bin foo.txt
   
2. Open foo.txt, search for "enroute[", change any 32000 to something realistic, save.
   
3. 1oom_saveconv foo.txt 1oom_save2.bin
   

Thanks for the reports!

--

The code block below describes 1.40m features in 1oom v0.8-38 and consists of lines from the 1.40m readme with added comments before the '-':

• a = always fixed
  
• e = enabled by default
  
• x = enabled with uiextra
  
• o = enabled with other option
  
• p = PBX num available
  
• + = fixed in Classic+ AI
  
• i = irrelevant
  
• r = rejected
  
• w = not understood
  
• m = maybe if there is interest
  

Code:

i - no more eternal alliances for AIs (reverted back to the vanilla version)
p - the missiles now use correct to hit bonus against ships with high missile defence
m - at least 5% of missile will always hit (was 6%)
+ - AI huge, armored ships now cannot cause a negative overflow (prevention taken, maybe not a bug)
p (str can be changed) - the game now uses "Controlled Barren" on the Race report screen instead of strange "Control Barren ENVIRON"
+ - 4th colony ship curse removed
a - nebula speed and nebula ETA should work correctly when launching, with transports and ships having the same speed
+ - [bug fixed] AIs now actually take their treaties in consideration, when asked to declare war on their allies
a - annoying bug / cheat when a fleet with bioweapons automatically bombed an enemy planet while orbiting is gone for good
p - during strategic bombing, the game now actually checks whether you have your latest researched battle computer on board of at least one orbiting ship before giving the bonus
p - the 'Wait' button allowing to fire unlimited number of rounds with unique weapons (pulsars, projectors etc.) during the combat - fixed
p - the 'Wait' button triggering the repeated auto-repair function of a ship during the combat - fixed
+ - AI clears his spies' missions when succesfully threatened
a - entering the general "threaten / break treaty" dialogue no more equals to a penalty of -100 to all temporary diplomatic (see OSG; is reserved for the concrete threats)
p - the Meklars now can build up to # 2700 factories on a planet [credit to Lydon]
p - the tech tree generation routine now checks for presence of at least one planetary shields tech for every race (see OSG)
p - the Silicoids don't have the planetology techs useless to them in their researchable tech tree
+? (overflow?) - NEW: fixed an important bug preventing the right distribution of the AI big fleets in the mid-late game
p - the annoying Scout II redesign feature lives no more [credit to Lydon]
a - the discovery percentages on tech screen are no more only 1/2 of the true probability of a tech hit
a - AI sabotage message continue = space
a - Psilon Leader "Zygot__" Name Correction: (removed empty spaces after name) [credit to Lydon]
i - reenabled the cursor over the star
e (slot 8) o (yearly) - the game autosaves every turn after the 7th turn into your folder
a - the races now have the appropriate choice of objective at the beginning of a game
a - the AI now uses the right race and the right objective when it takes decision about where to allocate the research points
a - the spies you educate on the same turn against different races are no more overpriced
a - breaking a NAP / alliance no more positively contributes to your rellations with the AIs (-10, -20 respectively)
+ - the player (AI or Human) who commits an oath breaker is not taken as a victim anymore, but as the tresspasser
p - combat transporters now work, subspace interdictor works against them
a - 8th stargate bug corrected (no ship maintenance overflow)
p - bombing damage with torps halved, normal damage with missiles (was the contrary)
r (reverted by the first item) - AI-AI positive diplomacy problem corrected
+ - the AI now correctly uses the radius of action during its decision making
+? (overflow?) - the AI intentionally aggressive fleet positioning during the final war now actually works
+ - a small issue concerning the change in AI defence and ship production when too many MBases on a planet, has been corrected
p - the Guardian now gets on impossible Adv.dam.control, hard gets Adv.rep.system, others none (was Adv. dam.control only on hard )
p - the research BC now get no 90% discount when starting new technology project
p - Silicoids do not have unusable techs in their tech tree: they now always get the Cloning tech
p - Bulrathis bombing decision when they are orbiting a planet and have transports incoming corrected to reflect their race gropo bonus
+ - Alkaris and Mrrshans bonus for AI-AI combat corrected to reflect their race bonus
w - early tech decisions corrected to include a fourth decision point for all AI races
m - all diplomatic temporary modifiers are now really capped at 100 (was 109)
i ("starmap s" always worked) - you may 'continue' a game directly by running starmap.exe
e (slot 8) - the game autosaves every turn in save9.gam (for the purpose of bug reports)
a - "SPACE bar" = continue, process to the next / works now on many screens
r (use space) - hotkey "A" = accept dispatching of a fleet, transport etc.
r (breaks kbd navigation) - side cursor works for a single slider on a screen
a (keys) x (diode) - rehaul of TECH screen, TAB runs through tech fields, hotkeys, the diodes lit under the tech level show when you reach max research bonus
a - rehaul of RACES screen, hotkeys, clickable portraits bring REPORT page
x - REPORT screen shows name of AI leaders, MAP screen shows current year
x - after running through the Next turn phase + extra messages (shield build, max pop reached...), the game always recenters on your last planet of choice

Please elaborate if you know what those 'w' fixes are exactly. Many of them have accompanying dead links in the patch thread OP. If you want to see the 'm' fixes, say so. If you want (optional) 1.40m hotkey support, list all the new/changed hotkeys. (Or, y'know, send a patch.)

v1.0 is approaching. If you want more 1.40m in it, now's the time to speak up.

[Jeff Graw]

v1.0 is approaching. If you want more 1.40m in it, now's the time to speak up.

I just skimmed the list, but if you're looking for opinions I'd suggest that you elevate a lot of the optional bug fixes to either always fixed, or enabled by default. The overwhelmingly vast majority of your users aren't going to want bugs to be left in just because they appear in some old version of the game. And the vast majority of those aren't going to figure out something as complicated as making their own PBX files. If these options are exposed in-game, then most players will interact with them given time. In a configuration file, a sizable minority will. With the current PBX workflow, maybe one in a thousand, if that, sorry to say it. For 99.9% of your players, you may as well have not fixed those bugs at all. And that's a really big waste.

On the other hand, the percentage of users who care so much about being true to vanilla that they prefer for obvious bugs like infinite special activations to stay unfixed, but not so much that they don't just play 1.3 in DOSBox (or a DOS gaming PC), has to be so comparatively minuscule as to be virtually non-existent. And the ones who care so much are also massively more likely to seek out the process to enable 1.3 behavior via making PBX files versus the other way around.

Given the absence of an intuitive way for players to toggle fixes, I'd recommend erring towards fixing obvious bugs as the default behavior rather than leaving those bugs active.

[1oom_aaron]

The project coder replies:

Given the absence of an intuitive way for players to toggle fixes, I'd recommend erring towards fixing obvious bugs as the default behavior rather than leaving those bugs active.

Good points. Vanilla by default as outlined in PHILOSOPHY stays. Perhaps a "Fix old bugs" toggle in the new New Game screen that would do what doc/pbxin_fixbugs.txt does unless the variables have been changed, which brings up the need to remember the defaults... I'll think about it. I place vanilla preservation over CLI-ignorant user comfort.