Messages

Which version of xMOn@D do you have? I have 0.18.0.

0.18.0 here as well.

Anyway, I found a reasonable workaround for me on the XMonad side: remove the borders of Simcar windows upon window creation. If I were to insist on having the borders, it would also have been possible to fix it by growing the window to account for the border, along the lines of what's described in this issue tracker comment.

It will be an impressive feat if McLaren manages to fumble the driver's title -- it's surely not beyond them!

"McLaren apologise to Norris, Piastri and fans for Las Vegas GP disqualification" 👀

It's time for the ZCT292 update of the rankings!

Before we get to the update proper, I should note the rankings have been revised to account for the scoreboard changes triggered by the replay cloning incident. You can gauge what changed by looking at the before and after of the ranking at ZCT291. The changes have revealed a few individual achievements from the past several races: Frieshansen reached the 2000 points milestone at ZCT285, Zapper got a personal best of 1855 points at ZCT287, and KyLiE had a joint personal best of 2076 points at ZCT291.

As for ZCT292, it saw HerrNove, KyLiE, MiDiaN and Spoonboy reaching personal best ratings, as well as stanceboyCZ joining the rankings. Below is the updated (and revised!) evolution graph:

@Argammon That is a reasonable test; in particular, it follows the precedent we set at ZCT280: a dual-way switch is a line that wouldn't work without the dual-way bug. For doing such a test on this track, I'd suggest breaking the path you aren't using removing a single element at the beginning the track, near the split.

I am not aware of the current car (bonus) rules, but it seems to be a perfect Audi Quattro circuit.

The Audi is not far off, though I guess it is a couple bonus points away from really fighting at the top -- the margins are narrow these days!

Btw: please suggest optimal DOSBox settings for Win11!

The basics remain the same, I think. 20k cycles keeps being a sensible default, though a relatively recent computer should handle cycles well about that with no problems. While preferred DOSBox version these days is DOSBox Staging, plain old vanilla DOSBox 0.74 is still good enough. For vanilla DOSBox 0.74 on Windows, I'd use something like this as a base for dosbox.conf (some of these are not necessary with Staging due to better defaults. Also, I prefer windowed to full screen, but YMMV of course):

Code Select Expand

[cpu]
cpu_cycles=20000
core=dynamic

[render]
aspect=true

[sdl]
output=overlay
fullscreen=false
windowresolution=960x720
priority=higher

Alternatively, for a ready-made setup on Windows you can try the R4K Stunts installer.

Quite a dilemma... shall I come back for "only one race"?

Only you can answer that... but you don't liking your earlier goals means there's a window to change or reframe them

Starting with a poll! And with an amusing tidbit from Wednesday's PTB update 

The PTB tables now have been recalculated. There have been some changes to them starting from ZCT288 (cf. the page as it was yesterday). Overall, 127:03 of PTB time has been redistributed. No one got additional points from those hours as of now (it might still happen in ZCT293), though some half-points have been earned earlier than we thought: Alan Rotoi on ZCT292 rather than ZCT293; KyLiE on ZCT289 rather than ZCT292; Zapper on ZCT290 rather than ZCT292.

Thanks for trying it with XMonad, and sorry for the truckload of dependencies 😅 Installing XMonad pulls the Haskell toolchain because it is configured through Haskell code (much like, say, dwm is configured through C code), so it is mostly used by people who already have the Haskell toolchain on their system for independent reasons.

I had no problems with SDL 3 or SDL 1, with which the game worked perfectly with fullscr=0 and fullscr=1

Interesting that it worked for you on SDL 3 plus (I presume) the default configuration of XMonad (as opposed to the customised one I have here). Another reason for me to examine my setup, I guess.

Possible workaround for "XMonad". Add 2 pixels to the width and height of the created window, file graphics/forsdl3/graph2d.c, line 139:

Code Select Expand

RGLOB_window = SDL_CreateWindow(title,width+2,height+2,0);

This workaround did work here on my current XMonad setup: no segfaults and 800x600 reported size on both the SDL2 and SDL3 builds. I don't think you'd want to make that change in your code, though, as it has side effects on other environments where everything has been working normally -- see e.g. the black lines at the right and bottom of the window in this screenshot taken in Xfce, where the window size becomes 802x602:



The share of Simcar users that have XMonad as their window manager is vanishingly small (i.e. probably just me), so it wouldn't be reasonable to expect Simcar to incorporate messy workarounds just to cater for that. Besides, I'm reasonably confident about finding a way to deal with this through XMonad configuration, by adding some kind of special rule for the handling of window borders. (And worst case, if nothing else works, I can just start a Xfce session when I want to play Simcar.)

This is really not cool, but from what I can tell, the rules page only talks about this under the Team section, where it says you can't use teammates' replays.

"You must drive your own replays" is such a self-evident principle that we do expect people to follow it even in the absence of an explicit bullet point in the rules -- though it probably wouldn't hurt to add another nod to it besides the one currently in the teams section.

Good catch; I wonder if my environment is somehow interfering with the window size (will try to find out later).

Yes, it is my environment. I normally use XMonad (a tiling window manager) on this computer; switching to a Xfce session I get no segfaults, and the expected 800x600 size is reported. Maybe the two pixels taken by the window borders are somehow being deduced from the available window size (but if so, why just from the width and not the height?). It's mostly academical now, but if I find a workaround for XMonad (and I guess there must be one) I'll post it here.

Good catch; I wonder if my environment is somehow interfering with the window size (will try to find out later). Trying with the 6.2.0 from your site, both the SDL3 build and full screen always segfaults. The provided binary (which is the SDL2 one, I believe) segfaults some of the time (if I retry enough times it works somehow), and the size reported on the console for it is 798x600x32.

Nice, I'll try it out soon.

I tried running it, but couldn't make it work while using sdl3 from the Arch Linux repo, and didn't manage investigate further so far. Running the binary from the attachment initially gives the following error:

Code Select Expand

$ ./simcar
SDL_FRAMEBUFFER_ACCELERATION 0
>> Set BITSPERPIXEL to 24 and recompile.<<

After changing BITSPERPIXEL in graphics/grconfig.h and recompiling, the executable segfaults:

Code Select Expand

$ ./simcar
SDL_FRAMEBUFFER_ACCELERATION 0
Set 1064x600x24
Segmentation fault         (core dumped) ./simcar


As a member of Cork's Crew, as well as the one who flagged the problem at the end of ZCT292, I fully accept the findings and regret that this has come to pass for as long as it did. I'll answer any questions you might have about this incident to the best of my knowledge about the facts.

Wait, the Plus races did counted in the championship! They had an average point so the three races counts as one.

Indeed; it's just that incorporating them into the season scoreboard like that nowadays could get a little awkward, or at least I feel like that (and of course I could be wrong about it!).

Either separate special race (like Plus 1-2-3 in 2002) or ZCT300, I suggest to restrict the car choice to LM002 - back to classics.

It would be cool to have non-championship "Plus" rounds in that vein, though we'd have to build the support for that on the site. I like the idea of doing it on ZCT300 as a LM002 race, too!

To ensure a LM002 race we wouldn't even need to suspend the bonus system; liberal adjustment of the coefficients for that specific race should suffice. I guess we'd also want to keep the LM002 out of the rotation between ZCT294 and ZCT299, to avoid having a spoiler race earlier in the season (that, too, can be achieved through scheduled usage of admin coefficient adjustments).