Bulletins not working

[rickparrish]

I am running Usurper 0.24 compiled on 7/31/15. I've noticed the USCORES bulletin is not updating correctly. The game does create a new bulletin every time the game is run but it is not showing any users characters and is showing two NPC's for some reason.

Here is what it looks like:

Characters of Usurper

Name Level Race Class Experience Status

Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?Ã?

1. Llwellyn.................16 Human Paladin 358,732 Alive*
2. De Mandeville............14 Half-Elf Warrior 266,282 Alive*
3. Sony.....................10 Mutant Assassin 106,919 Alive*
4. Ugluk....................10 Orc Sage 90,166 Alive*
5. Ugluk....................10 Orc Sage 90,166 Alive*
6. Zara......................8 Elf Ranger 56,290 Alive*

(* indicates computer player) (arried, ing, ueen)

[codefenix-ConChaos]

Just in case there are any signs of life here, I decided to tinker with the source code myself, and I've made a promising discovery.

I took advice from a Reddit user named jdavidramsey and re-compiled the Usurper .24 source code in Lazarus, making sure to use an earlier version of the SORTPL.PAS file. I went all the way back to the one from version .20e.

I've been playing this build locally for 10 days. My character's level has exceeded level 20, and has not yet been overwritten by duplicated computer players. This is the USCORES.ASC file from the current game in progress (the test character's name is simply "test"):

Characters of Usurper

###  Name                  Level  Race      Class      Experience  Status
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  1. test.....................21  Human     Warrior     1,091,967  Alive
  2. Llwellyn.................16  Human     Paladin       374,800  Alive*<K> 
  3. De Mandeville............14  Half-Elf  Warrior       253,843  Alive* 
  4. Ugluk....................11  Orc       Sage          135,547  Alive* 
  5. Sony.....................10  Mutant    Assassin      119,397  Alive* 
  6. Zara......................9  Elf       Ranger         61,652  Alive* 

(* indicates computer player)
(<M>arried, <K>ing, <Q>ueen)

So for anyone interested, my initial impression is this does indeed seem to correct the problem.

Comparing the SORTPL.PAS file in .24 to the one in .20e, there are definitely some code changes, most of them stylistic (indenting, spacing, etc). The most obvious logic change is a while-loop within the Sort_Players procedure. It's unclear what the reason for the change was, but it's safe to assume that it broke the sort logic.

I'm hoping someone picks the project up, and can use this information to solve the problem permanently.

[dan1982code]

Thank you for this! I'm interested partly because I'm very likely the one who broke it. I was having trouble with the original sort routines in games with many players (a failed attempt to support thousands of players that I never finished), so I tried to fix it. I'm betting that what I did in 0.23f has something to do with this.

I figure we should just go back to the original file. Regardless, I'm curious how I broke it and will take a look.

Not sure if Rick is monitoring, and I haven't been active here for years. Perhaps someone can jump in to keep this going?

[dan1982code]

Yep, the while-loop at line 295 is flawed. It assumes that the current element is smaller than some earlier element in the array. If that's never true, which is what would happen when you exceed the level of all of the NPCs, then we get the overwriting behaviour.

We should go back to the original code here. (It works because it performs explicit swaps.)

[codefenix-ConChaos]

Glad you were able to confirm! Thanks for jumping on this so quickly.

[rickparrish]

Thanks for identifying the issue. I've just reverted the changes in SORTPL and committed new Windows binaries, although I didn't have time to setup a game and test them, so hopefully I didn't miss anything while reverting.

[dan1982code]

Thanks, Rick! Looks good, but I'll do some testing, too.

[codefenix-ConChaos]

Appears to be resolved in the latest binary here.

[xbit44]

A little late to the party, but i'm having the score issue on my 16bit Spitfire BBS. Downloaded the latest .exe's but now when i access the game its local mode.

[rickparrish]

A little late to the party, but i'm having the score issue on my 16bit Spitfire BBS. Downloaded the latest .exe's but now when i access the game its local mode.

Sorry for the late reply, I filed this email away awhile ago and haven't been on my computer too much lately, so forgot about it!

So there could be two possible reasons for this. One is that the newer binaries are using RMDoor instead of DDPlus, which has its own way of accepting command-line parameters. At some point I'll need to update it to be compatible (for example I don't think it's possible to use /HMAINT with it), but for now you'll have to pass the dropfile path using the /D parameter. So for example with Synchronet I use:

USURPER.EXE /D%f which expands to USURPER.EXE /Dc:\sbbs\node1\door.sys

On the upside, the CTL files for each node aren't needed anymore!

The other reason is there was a bug in the DOS/GO32V2 version, which I've just fixed. The bug would have allowed the initial splash screen to display remotely, but then the pause prompt would cause an exception that effectively disabled remote I/O, making it appear like it was running in local mode.

Hopefully one of those two things will get it working for you!

Thanks, Rick

[codefenix-ConChaos]

Nice to see the DOS/GO32V2 build in the mix! Never noticed it before (not to go off topic, but it looks like it requires CWSDPMI for anyone who wants to run it).

The actual issue in this thread (Bulletins not working) has been fixed (see #13 and #15 ), so it's probably safe to close this. I plan on testing this build over the next few days and will see how it goes.

Exciting times to be a sysop!

[xbit44]

The /D worked like a champ! Thank you Rick.

Question, when in the Dungeon i need to type the number of the monster rather than just hitting enter like older versions. Is this a known issue? Or do we have a config setting that can change this in/out of game?

Next I'll be testing the score rankings to see if the bug has been removed when [L]isting Players as somewhere around level 8-10 the game will no longer list human players.

On Tue, Aug 3, 2021 at 1:29 PM rickparrish @.***> wrote:

A little late to the party, but i'm having the score issue on my 16bit Spitfire BBS. Downloaded the latest .exe's but now when i access the game its local mode.

Sorry for the late reply, I filed this email away awhile ago and haven't been on my computer too much lately, so forgot about it!

So there could be two possible reasons for this. One is that the newer binaries are using RMDoor instead of DDPlus, which has its own way of accepting command-line parameters. At some point I'll need to update it to be compatible (for example I don't think it's possible to use /HMAINT with it), but for now you'll have to pass the dropfile path using the /D parameter. So for example with Synchronet I use:

USURPER.EXE /D%f which expands to USURPER.EXE /Dc:\sbbs\node1\door.sys

On the upside, the CTL files for each node aren't needed anymore!

The other reason is there was a bug in the DOS/GO32V2 version, which I've just fixed. The bug would have allowed the initial splash screen to display remotely, but then the pause prompt would cause an exception that effectively disabled remote I/O, making it appear like it was running in local mode.

Hopefully one of those two things will get it working for you!

Thanks, Rick

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rickparrish/Usurper/issues/6#issuecomment-892144300, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB2TW5NBNGRQWBABJ35BCP3T3BGTZANCNFSM4CC3BUJA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

--

... BBS'ing is Terminal

[codefenix-ConChaos]

Question, when in the Dungeon i need to type the number of the monster rather than just hitting enter like older versions. Is this a known issue? Or do we have a config setting that can change this in/out of game?

See issue #14.

[rickparrish]

This is because the RMDoor "line input" method doesn't allow blank strings. I've just committed a change that allows blank strings, but I probably won't be able to compile binaries for the various platforms until later tonight.

[codefenix-ConChaos]

I've just committed a change that allows blank strings, but I probably won't be able to compile binaries for the various platforms until later tonight.

I know I'm probably nitpicking, but when you do, can we also update the compiled date (ucomp)? https://github.com/rickparrish/Usurper/blob/eec17959b7f1faa8d76a6c0e5b3768c0459b8348/SOURCE/COMMON/VERSION.PAS#L30

Players have gotten used to expecting certain quirks from version .24 compiled on 7/31/15. When they see a new compiled date (and maybe even an alpha suffix on .24), that will be a clear signal they're playing something new with fixes.

[rickparrish]

Catching up on some of the replies:

Nice to see the DOS/GO32V2 build in the mix! Never noticed it before (not to go off topic, but it looks like it requires CWSDPMI for anyone who wants to run it).

I'm not sure if I've ever worked with GO32 before -- when is CWSPMI needed? I didn't seem to need to do anything extra to run them here, and from the bit of reading I've done maybe that's because I'm running it in a Windows console, which provides it's own DPMI host?

The actual issue in this thread (Bulletins not working) has been fixed (see #13 and #15 ), so it's probably safe to close this. I plan on testing this build over the next few days and will see how it goes.

Thanks for testing! I didn't have time to do much testing at all with the latest binaries, so hopefully they work but no promises!

Next I'll be testing the score rankings to see if the bug has been removed when [L]isting Players as somewhere around level 8-10 the game will no longer list human players.

I believe Dan fixed this a while ago, so hopefully this works correctly now. Let us know if not.

I know I'm probably nitpicking, but when you do, can we also update the compiled date (ucomp)?

Not nitpicking at all, that's a great idea to update the compiled date when a new build is released. I've also bumped it up to 0.25 since that'll be the next release once everything is tested and confirmed to work.

And I'm going to close this and a couple of the other issues, and then open a new one for discussing 0.25.

[codefenix-ConChaos]

when is CWSPMI needed? I didn't seem to need to do anything extra to run them here,

Ah, please disregard that. It only gives the CWSPMI message in DOSBox. On my Win32 system, it runs just fine.

[xbit44]

v0.25 (dos) fixed the issue on my 32bit win10 Spitfire BBS. Will test win32 version on Sync tomorrow. Thanks Rick!