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

(September 14th, 2018, 06:08)1oom_aaron Wrote: The project coder replies:

(September 13th, 2018, 23:12)Jeff Graw Wrote: 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.

A three way toggle between "1.3" "1.4" and, whatever you want to name all bug fixes enabled ("1.5?"), could be nice.

I'm still fairly skeptical of anyone really caring about vanilla accuracy when it comes to unintended bugs though. I can see that being the case in, say, Doom, where any change may have a visceral albeit intangible impact on the overall feel of things because of the tight relationship between game behaviour and input, or may be an ingrained aspect to speed running. Not so much for 4X games. Though, if the extent of the philosophy towards vanilla behaviour has little to do with what you expect users want, and more with your own personal preference, I'll stop talking. Your project, your rules smile
Reply

The project coder replies:

(September 14th, 2018, 17:59)Jeff Graw Wrote: A three way toggle between "1.3" "1.4" and, whatever you want to name all bug fixes enabled ("1.5?"), could be nice.

This sounds good but has a few drawbacks. Is being able to redirect back after retreat a bug? That's enshrined in OSG, and you can't fight dead trees (except by writing errata). Same question applies to the other bug/cheat things. The option (as presented) seems to imply UI and AI changes as well; I do not want to conflate them.

I do agree that asking for the players to write their own PBXIN files is ridiculous. But pbxin_fixbugs.txt is provided. If expecting the user to run one simple command in unreasonable then this was a bad week to stop drinking.

I've pondered and decided to not add the UI option yet. The amount of work is not trivial due to the defaults not being remembered. Maybe in the post-v1.0 world.

(September 14th, 2018, 17:59)Jeff Graw Wrote: I'm still fairly skeptical of anyone really caring about vanilla accuracy when it comes to unintended bugs though.

Yeah, this is a hard question. The fresh negative/32000 doom stack fix is a good example. It's obviously an unintended bug, but I'm willing to bet that there's a player somewhere who considers dealing with doom stacks an interesting challenge and integral part of the experience. Make it an option? I'm torn.

(September 14th, 2018, 17:59)Jeff Graw Wrote: I can see that being the case in, say, Doom, where any change may have a visceral albeit intangible impact on the overall feel of things because of the tight relationship between game behaviour and input, or may be an ingrained aspect to speed running.

Yep. Demo compatibility is certainly a thing.

(September 14th, 2018, 17:59)Jeff Graw Wrote: Though, if the extent of the philosophy towards vanilla behaviour has little to do with what you expect users want, and more with your own personal preference, I'll stop talking.

My personal preference is neither the defaults nor having a million little options. The current mess is a result of trying to preserve vanilla behaviour and optionally have nicer things.

I do appreciate your input. Your points are valid and it's better that they are aired out.

(September 14th, 2018, 17:59)Jeff Graw Wrote: Your project, your rules

And that is the beauty of Free Software. Don't like how the project is lead? Fork! Too much work? Make a PBX file, add 1oom_but_better.bat that loads it, wrap it up and sell for 5 BC.

I do expect someone to fork and yank out all the old bug support at some point. Honestly, I'd love to see a fork or two.
Support Free Software projects!
Reply

v0.8-14win32

Recapturing rebelled colonies leaves the planet with 0 population after capture, even though the surviving imperial troops are supposed to resettle the planet. Save provided.

The AI is now better with the ship designs - apparently the armor II was hogging up all space, leaving little for anything else.


Attached Files
.zip   1oom_save6.zip (Size: 8.58 KB / Downloads: 1)
Reply

(September 15th, 2018, 03:47)1oom_aaron Wrote: This sounds good but has a few drawbacks. Is being able to redirect back after retreat a bug? That's enshrined in OSG, and you can't fight dead trees (except by writing errata).

The retreat "bug" seems to me to be the one special case, assuming you count it as a bug that is. Being enshrined in the OSG raises the question of whether it's a bug at all, or just a very, very poor design choice, but I'd say that a thing merely being mentioned in the OSG in and of itself isn't all that compelling. The OSG is already full of issues, and I believe that the super fans that read the OSG are exactly the kind of people who disdain things like the redirect issue. What does make this such a significant case is that so many players use (abuse?) this behaviour that it's become ingrained to the way they interact with the game. Contrasted with, say, additional special usage by pressing wait, the later isn't ingrained and is obviously unintentional.

Or to put it another way, it's unlikely that anyone here would mind the removal of either the infinite special bug or retreat redirect "bug", while a more casual user is unlikely to mind the removal of additional special activations, or even have heard of it, but could conceivably have a negative reaction to fixing the redirect issue.

I suppose that the redirect issue could be separated from all the other fixes in some way, or could fall under the aegis of a "1.5" label. It seems more fitting that something that is arguably a design issue should be fixed in a different ruleset rather than stealth patched.

(September 15th, 2018, 03:47)1oom_aaron Wrote: I do agree that asking for the players to write their own PBXIN files is ridiculous. But pbxin_fixbugs.txt is provided. If expecting the user to run one simple command in unreasonable then this was a bad week to stop drinking.

It's not unreasonable, but it is very atypical, and therefore fundamentally less intuitive. Barring giant flashing instructions when you start the game, or something similarly obvious, you can't expect more than a tiny minority to figure out that such fixes are even possible, even if they would otherwise be willing to put in the effort.

Some suggestions, that might help grow that minority by an order of magnitude or more, would be to provide the instructions in the main readme file instead of or in addition to the docs folder. Better yet, provide batch files, executable, or shortcuts that automatically create or remove the fixes since the need to enter command prompt to pass in arguments already reduces the number of players who might interact with the system by ~99%.
Reply

The project coder replies:

(September 15th, 2018, 05:28)Juffos Wrote: Recapturing rebelled colonies leaves the planet with 0 population after capture, even though the surviving imperial troops are supposed to resettle the planet. Save provided.

Thanks, fixing...

EDIT:

This bug has always existed in 1oom. Took a while for anyone to notice (or report). Fixed in v0.8-17.

This was an another translation error. What do I mean with that? A peek behind the curtain for the terminally curious...

Code in v1.3 starmap.exe at 0x81847:
Code:
mov     ax, temp_landing_planet
mov     dx, size struc_planet
imul    dx
les     bx, planet_data_segoffs
add     bx, ax
pop     ax
sub     ax, es:[bx+struc_planet.rebels]
add     ax, temp_ground_pop_s1
push    ax
mov     ax, temp_landing_planet
mov     dx, size struc_planet
imul    dx
les     bx, planet_data_segoffs
add     bx, ax
pop     ax
mov     es:[bx+struc_planet.pop], ax

Old 1oom code: "p->pop = p->pop - p->rebels". Spot the error? (answer at the bottom)

Looking at the private pre-v0.1 repository, that day (2018-03-13) I spend disassembling and translating over 3100 bytes of starmap.exe to 273 lines of C. That must be over my limit of staying focused enough. Or maybe I was drunk. The worst part? That was a relatively calm day in terms of changed code amount.

Have I mentioned that this project needs help with testing? smile

(September 15th, 2018, 05:28)Juffos Wrote: The AI is now better with the ship designs - apparently the armor II was hogging up all space, leaving little for anything else.

Good to hear. Being a casual player at best, I would never have noticed these things. Keep 'em coming!

(September 15th, 2018, 16:15)Jeff Graw Wrote: I suppose that the redirect issue could be separated from all the other fixes in some way, or could fall under the aegis of a "1.5" label. It seems more fitting that something that is arguably a design issue should be fixed in a different ruleset rather than stealth patched.

Ah, pbxin_fixquestionabledesignissues.txt and yet another UI element.

All of *_redir_fix (and arguably waste_{calc,adjust}_fix) disable cheats. pbxin_removecheats.txt with overlap with the previous txt?

One example related to defaults: the starting ship costs. There's plenty of advice about scrapping and redesigning to make them cheaper. I do not want to invalidate all that by default.

I assume the Guardian damage control fixes make it a lot harder to beat on Impossible. Is noticeably increased difficulty acceptable? (Well, it does say Impossible on the tin...)

One fix in 1.40m that is currently not in pbxin_fixbugs.txt is guaranteed planetary shields (see the errata). Is the occasional extra challenge unwelcome?

The bikeshed has many, many walls. I maintain that "be like 1.3" is one of the two sane defaults, the other being "fix everything and ignore the purists/cheaters/etc".

(September 15th, 2018, 16:15)Jeff Graw Wrote: It's not unreasonable, but it is very atypical, and therefore fundamentally less intuitive.

You keep using that word and I can't resist anymore:

Bruce Ediger Wrote:The only “intuitive” interface is the nipple. After that it’s all learned.

Not that atypical for 1993.

(September 15th, 2018, 16:15)Jeff Graw Wrote: Barring giant flashing instructions when you start the game, or something similarly obvious, you can't expect more than a tiny minority to figure out that such fixes are even possible, even if they would otherwise be willing to put in the effort.

A fair estimate, assuming total player base. That may grow somewhat if we limit that to those who would actually play a remake of a 25 year old game.

Adding a big flashing "RTFM" to the intro is a tempting idea.

I'd like to see the Venn diagram of people who can get the PBX file built and those who bother to report bugs.

(September 15th, 2018, 16:15)Jeff Graw Wrote: Some suggestions, that might help grow that minority by an order of magnitude or more, would be to provide the instructions in the main readme file instead of or in addition to the docs folder.

Not a bad idea, but I like the current text division. I'll think about pointing to the docs better in the readme and homepage.

(September 15th, 2018, 16:15)Jeff Graw Wrote: Better yet, provide batch files, executable, or shortcuts that automatically create or remove the fixes since the need to enter command prompt to pass in arguments already reduces the number of players who might interact with the system by ~99%.

I'd drop that to ~90% given that this is originally a DOS game. For the suggestion itself, I'll take another book from the Doom world and leave that to (external) launchers and/or enterprising individuals with .bat writing skills.

One aspect of portability (see PHILOSOPHY) is minimizing the amount of things to port. Adding bat files or shortcuts is counterproductive from that perspective as similar would be expected from the other ports.

As a sidenote, adding fix toggles to PBX files was an afterthought. v1.0 was supposed to be a v1.3 clone but the inevitable feature creep happened.

EDIT:

On retreat redirect:

readme.txt from v1.3 Wrote:6. Ships that have been given orders but are still in orbit (on the
  left side of the planet) can now be selected and have their
  orders changed. They can also be ordered to stay at the home
  planet by selecting the planet as destination.

The same piece of code allows the return to retreated planet (or even redirecting when flying directly over a planet). I'm not convinced me that "given orders" intentionally includes retreat. My bet is on "unplanned extra feature from UI improvement".

--

A: Fixed code: "p->pop = p->pop - p->rebels + gr->s[0].pop1". Clearly I glazed over the "add ax, temp_ground_pop_s1".
Support Free Software projects!
Reply

(September 15th, 2018, 21:02)1oom_aaron Wrote: One example related to defaults: the starting ship costs. There's plenty of advice about scrapping and redesigning to make them cheaper. I do not want to invalidate all that by default.

I assume the Guardian damage control fixes make it a lot harder to beat on Impossible. Is noticeably increased difficulty acceptable? (Well, it does say Impossible on the tin...)

One fix in 1.40m that is currently not in pbxin_fixbugs.txt is guaranteed planetary shields (see the errata). Is the occasional extra challenge unwelcome?

The bikeshed has many, many walls. I maintain that "be like 1.3" is one of the two sane defaults, the other being "fix everything and ignore the purists/cheaters/etc".

I see these as more or less non-issues compared to redirect behavior.

With starting ship costs the rub there is that anyone who is invested enough into the game to do the whole scrap and redesign thing is going prefer the bug fixed anyway -- and are exactly the people who would notice that the costs became correct.

Likewise, anyone playing on impossible is the kind of person who would prefer damage control to function properly on the Guardian.

The guaranteed planetary shield tech thing, distinct from the prior two examples, and whether intentional or not, affects design rather than presenting to the player as an obvious bug. And it's so close to being irrelevant in the grand scheme of things that you could go either way with no real impact on the end user.

Fixing waste issues is admittedly closer to the redirect issue than the others, but I don't see much in the way of tension here either. The issue with "fixing" redirection is that you're taking away a player convenience, a crutch that many have grown accustomed to, and that can engender a distinctly negative reaction if snatched away. But as far as I can tell, all the waste bugs in MoO 1 just create confusion and annoyance.

(September 15th, 2018, 21:02)1oom_aaron Wrote:
(September 15th, 2018, 16:15)Jeff Graw Wrote: It's not unreasonable, but it is very atypical, and therefore fundamentally less intuitive.

You keep using that word and I can't resist anymore:

Bruce Ediger Wrote:The only “intuitive” interface is the nipple. After that it’s all learned.

Not that atypical for 1993.

But very much so for 2018 wink

(September 15th, 2018, 21:02)1oom_aaron Wrote: I'd drop that to ~90% given that this is originally a DOS game. For the suggestion itself, I'll take another book from the Doom world and leave that to (external) launchers and/or enterprising individuals with .bat writing skills.

I thought 99% was actually rounding down a bit  lol

I wouldn't expect that the skills implied by navigating DOS back in the day are necessarily are retained or transfer in in any meaningful way to the present situation. 

I've met quite a few MoO 1 fans in random, real world, encounters -- thanks in large part to talking about my work. It's somewhat anecdotal, sure, but I'd guesstimate that the average fan is 40-55, male, not that tech savvy and very difficult to reach online, but not a Luddite either, and I think there are probably far more of them out there than one might reasonably expect.

Retrogaming and finding new old games to play is certainly a thing as well. And MoO has a lot of name recognition.  

(September 15th, 2018, 21:02)1oom_aaron Wrote: One aspect of portability (see PHILOSOPHY) is minimizing the amount of things to port. Adding bat files or shortcuts is counterproductive from that perspective as similar would be expected from the other ports.

As a sidenote, adding fix toggles to PBX files was an afterthought. v1.0 was supposed to be a v1.3 clone but the inevitable feature creep happened.

I know that feeling smile

I think ideally though, there would be a number of PBX files included with the package, which could then be toggled with a super simple GUI inside the game. I mean, yeah, it's more work, but it probably pales in comparison to finding and fixing all of these bugs in the first place. And if the alternative is that basically no-one plays with the fixes enabled, even if majority of players would prefer them to be enabled if only they knew, is it not worth it a cost-benefit point of view to find some way to make these features more accessible? Or maybe that's the sunk cost fallacy speaking and most users won't care much either way so long as the end result is stable.
Reply

The project coder replies:

(September 16th, 2018, 22:37)Jeff Graw Wrote: I see these as more or less non-issues compared to redirect behavior.

Given that the main goal is to recreate v1.3, having (by default) old gameplay advice not apply anymore is an issue.

I agree on the waste issues. I'm also happy that the current defaults seem to match v1.3 exactly.

Quote:The issue with "fixing" redirection is that you're taking away a player convenience, a crutch that many have grown accustomed to, and that can engender a distinctly negative reaction if snatched away.

Precisely. The option exists to enforce the rule in multiplayer games. It's not enabled in pbxin_fixbugs.txt (but exists as a commented out entry).

Since I've made it pretty clear that v1.3 is the default, we must be arguing about pbxin_fixbugs.txt (or "v1.5") contents. I'll enable more in it.

Quote:But very much so for 2018

Here's 1oom_modern_sdl2! All UI UX text has been replaced with incomprehensible icons, the UX has been made "responsive" by adding the circle-of-circles wait animation between each transition and 20% of the screen is wasted on empty space to let the design breathe. Also, Facebook and Twitter integration!

(Shouldn't jest about empty space with VGA vs. widescreen and aspect ratio defaults ...)

Quote:I thought 99% was actually rounding down a bit

... bitten by optimism again. Where's that bottle?

Having met 0 MOO1 fans, I'll take your word. Interesting (if expected) stats.

Quote:I think ideally though, there would be a number of PBX files included with the package, which could then be toggled with a super simple GUI inside the game. I mean, yeah, it's more work, but it probably pales in comparison to finding and fixing all of these bugs in the first place.

PHILOSOPHY strikes again: "1oom does not need to be installed. The only required data files are the LBX files from the original game."

Again, external launcher (or bat) can do this. Having it inside the game is problematic also because PBX files can replace LBX data and by the time the UI is running, those have (mostly) been load already.

Adding a ruleset (3-way?) toggle would require remembering the defaults. This would require more than 1000 lines to be changed. I estimate it taking 20 hours. Adding the UI element is trivial in comparison. The good (?) news is that this may have to be done later anyway for multiplayer PBX support. I will not do it before v1.0. Speaking of which...

So how about them missing 1.40m fixes?
Support Free Software projects!
Reply

(September 17th, 2018, 03:22)1oom_aaron Wrote: Again, external launcher (or bat) can do this. Having it inside the game is problematic also because PBX files can replace LBX data and by the time the UI is running, those have (mostly) been load already.

Adding a ruleset (3-way?) toggle would require remembering the defaults. This would require more than 1000 lines to be changed. I estimate it taking 20 hours. Adding the UI element is trivial in comparison. The good (?) news is that this may have to be done later anyway for multiplayer PBX support. I will not do it before v1.0. Speaking of which...

Fair enough. A compromise could be having the .pbx selection occur before anything else is processed, which would of course necessitate a restart of the application to make any changes. But if you're likely to come up with a better solution for networked multiplayer anyway, then I can see how that might make an ad-hoc solution before that time fairly redundant in the grand scheme of things.
Reply

The project coder replies:

(September 17th, 2018, 17:04)Jeff Graw Wrote: Fair enough. A compromise could be having the .pbx selection occur before anything else is processed, which would of course necessitate a restart of the application to make any changes.

I suppose batch files can be used to make a simple menu. I'm having some horrible "if errorlevel =" flashbacks...

Quote:But if you're likely to come up with a better solution for networked multiplayer anyway, then I can see how that might make an ad-hoc solution before that time fairly redundant in the grand scheme of things.

Plan A is to allow both server and client to set PBX files, with the server sending its PBX files to the client and the client resetting any PBX numbers and functional LBX files (firing, research) to default (requiring that 1000 line / 20 hour work) before applying them, allowing the client to do cosmetic patches. Plan B is to simply disallow client PBX files on network multiplayer.

No UI elements in either plan, but A allows for the run-time toggling of rulesets on a single player / hotseat game.

... but all of this is post-v1.0. The project is starving for bug reports.
Support Free Software projects!
Reply

error: patch file 'fixbugs.pbx' item 21 numid 'waste_calc_fix' (0) invalid!

Windows 10, 0.8-21
Reply



Forum Jump: