next »

[Thaumaturge]

Hmm... All very interesting. I might try loading that version of Linux at some stage, to see whether it's an issue specific to that that distribution (or those in its family, perhaps).

Yes, but only the once.  I ended up starting the game a good dozen times trying to solve this problem and I was not able to reproduce this, so it may have been a fluke.

That's my current guess: that it was correlation, not causation, so to speak.

Do my python versions matter or is everything compiled into byte-code?  I noticed a distinct lack of .py files.

Without double-checking with the engine-devs, I think that it's compiled into bytecode, and thus that it shouldn't be dependant on your version of Python.

A minor secret: there are some Python files secreted away within the downloadable version. However, they're just language-string files; nothing holding any real logic, as far as I recall.

• Sometimes I can pick up my first item, but then the game crashes when I try to pickup a second.  Viewing the item in my inventory works fine.

You say that viewing the item in the inventory works--but what happens if you click on an inventory item?

For example, if you were to start up the game, and then--trying a few times in order to avoid fluke behaviour--immediately open your inventory, and click on the sword-item?

It looks like this game is more GPU bound than CPU bound.  Could there be some weird logic ending up with 0-timedelta frames or input repeated across frames without proper context?

I'm not sure, but I doubt it. However, see my next response...

EDIT: two mouse clicks being registered in a single frame?  First click gets handled, second click tries to be handled but the referenced object is now gone or changed.  My mouse is being polled at a higher-than-standard rate IIRC.  I'll try again tomorrow with a different mouse.

I was thinking about this issue last night, and the above is the possibility that came to me, too.

You see, the way that the relevant logic works is something like this, if I recall correctly:

Once per frame, a ray is fired from the player's position to determine what, if anything, they're looking at. A reference to that object is stored (or "None" if no object was found).

Then, when you click the mouse-button and a mouse-event is called, the game checks the currently-viewed item. If it exists, and if it's an item that can be taken, the game triggers the cascade of methods that you saw in the log that you posted above. Towards the end of this, the item is destroyed--since it's no longer required.

Now, under normal circumstances this is fine: on the next frame the ray is fired again, no object is found (since the collectible object has been removed), and thus the "object being looked at" variable is cleared. (Or another object takes its place, if one happened to be in line of sight behind it.) Thus another click-event will not do anything untoward.

However, if a second click-event were to go through on the same frame, the "object being looked at" variable won't yet have been reset, and the game will attempt to run the same logic on it a second time. But at that point it will have been destroyed, and thus its data will no longer be valid--and hence the crash that you saw.

Quite why the system is generating two mouse-clicks in a single frame I don't know. Even if your mouse is being polled at a high rate, I would expect only one mouse-up event per mouse-release...

Would you be willing to run a small test-program for me, please? I'm thinking to put together such a program, which might show us whether we are indeed getting multiple mouse-events.

I do have some ideas as to how I might protect against this issue (such as only allowing one set of mouse-events per frame), but I'd like to check that it is indeed the problem.

[edit]
If you are willing, here's a small program (~18MB) that should hopefully test whether multiple mouse-events are being generated:
https://www.dropbox.com/s/flfe037dh8hsqpu/Mouse-Event%20Tester-0.1_manylinux1_x86_64.tar.gz?dl=1

It's quite simple: when a mouse-down event occurs, it increments a counter; when a mouse-up event occurs, it increments another one. The values of these counters are displayed on-screen.

So, the basic test would be to just run the program, then click the left mouse-button once. If only one event is being generated, each counter should then have a value of 1. However, if two events are being generated, then each counter should have a higher value.

In case the problem is related to the assigning of input-events, I've added a method to re-assign those events. Press "space" to call that method, then try the mouse-clicking test again and see by how much the counters increment.

I'm hoping that we'll find that in one or both cases the counters will indeed increment by more than one for a single click!

[Whales]

Test program

No double-counts occurring, before or after hitting space.  Quickly/lightly tapping the button or holding it has no effect (other than spacing the single-counts).  Running the game whilst using the tool also doesn't trigger any double-counts.

Using a different mouse

... completely fixes the problem.  Huh.

Thaumaturge, may I introduce you to your new Nemesis:



This is a decade or more old PS2 EDIT:USB Intellimouse in it's natural habitat.  It crashes your game.

I am polling it at 500Hz, most mice are lower (~100Hz?). To get it to this speed I am using an extra kernel option (usbhid.mousepoll=2).  I've had this option enabled for years with no issues elsewhere.

As a second mouse I tested a cheap wireless touchpad (USB).  It polls around 91Hz.  Using it to click I can successfully pick up objects in ADTTM with zero crashes, even with the other mouse still plugged in.

Most excellent.  

 

EDIT: Checking with xev

'xev' or the X event tool describes all input it sees.  I can't get it to show anything strange or interesting.

How does your engine interface with input?  Could it be opening the /dev/input/* devices directly?  SDL events?  X11?  This might be a configurable you have setup differently between your game and the tool you uploaded.

[Whales]

Whilst I'm here: I should mention that the mouse sensitivity in this game is very low (this could be related).  On the highest in-game sensitivity setting of 20 I still can't rotate more than 90 degrees without having to lift my mouse (almost 20cm of linear distance on the desk, depending on the velocity I use).  I run 3 monitors side-by-side and can move my mouse from one side to the other with about the same effort.

[Thaumaturge]

Test program

No double-counts occurring, before or after hitting space.  Quickly/lightly tapping the button or holding it has no effect (other than spacing the single-counts).  Running the game whilst using the tool also doesn't trigger any double-counts.

Argh, that's frustrating! I was really hoping that this would produce double-counts, as it would both indicate that the problem had been successfully identified and provide a fairly minimal test-case. :/

However! There is one more possibility: that testing-tool likely ran at a ridiculously high frame-rate, as it lacked anything to give the graphics card any serious work to do. Perhaps that's part of the problem: perhaps the issue only appears when the frame-rate is too low--something like a frame-rate less than the polling rate of your mouse, or some such thing.

For example, you say that your mouse is polled at 500Hz. Then, if I'm not much mistaken, if in the game the frame-rate were 250fps, the mouse would be polled twice per frame--but if in the testing-tool the frame-rate were 600fps, the mouse would be polled only once per frame.

Could I trouble you to run a new version of the testing-tool, please? The process of testing is the same as before--but this time, you can press "enter" to limit the frame-rate. To display this information, the frame-rate should now be visible at the top-right of the window.

[edit]
The engine devs have requested some additional output, so I've updated the test-program again. If you would, please run this new version from a terminal and copy-paste all output that it produces into this thread!

Specifically, it should now print out engine event-data, as well a some print-statements from the test-program itself so that we can see what the engine thinks is happening. If the frame-rate limitation does indeed produce the bug, then hopefully the additional information might help!

The new download link:
https://www.dropbox.com/s/wyfri7714d9qerf/Mouse-Event%20Tester-0.2.5_manylinux1_x86_64.tar.gz?dl=1
[/edit]

Using a different mouse

... completely fixes the problem.  Huh.

Thaumaturge, may I introduce you to your new Nemesis:
...

Argh, that is... weird and troubling!

I am glad, at least, that (A) we've somewhat isolated the problem, and (B) you've found a means by which you can potentially play the game!

How does your engine interface with input?  Could it be opening the /dev/input/* devices directly?  SDL events?  X11?  This might be a configurable you have setup differently between your game and the tool you uploaded.

It's a third-party engine (Panda3D), not one of my own construction, so I'm not that familiar with the internals, I'm afraid. :/

Indeed, I think that the next thing for me is to take this information to the engine-devs.

Whilst I'm here: I should mention that the mouse sensitivity in this game is very low (this could be related).  On the highest in-game sensitivity setting of 20 I still can't rotate more than 90 degrees without having to lift my mouse (almost 20cm of linear distance on the desk, depending on the velocity I use).  I run 3 monitors side-by-side and can move my mouse from one side to the other with about the same effort.

Hmm, that's interesting. I don't think that I've ever worked with so sensitive a mouse, myself, so the game is tuned to the sorts of values that I'm used to.

With the mouse-sensitivity at its default and using my own mouse, I can easily turn more than ninety degrees without lifting the mouse, I believe.

I can perhaps increase the maximum value of the sensitivity slider, of course! (Although this likely won't help with the mouse-clicking stuff.) What sort of value do you think might work for you, given the values of "10" for the default and "20" for the current maximum? (Noting that this operates as a scalar internally, if I recall correctly.)

[Ishi]

Whilst I'm here: I should mention that the mouse sensitivity in this game is very low (this could be related).  On the highest in-game sensitivity setting of 20 I still can't rotate more than 90 degrees without having to lift my mouse (almost 20cm of linear distance on the desk, depending on the velocity I use).  I run 3 monitors side-by-side and can move my mouse from one side to the other with about the same effort.

Hmm, that's interesting. I don't think that I've ever worked with so sensitive a mouse, myself, so the game is tuned to the sorts of values that I'm used to.

With the mouse-sensitivity at its default and using my own mouse, I can easily turn more than ninety degrees without lifting the mouse, I believe.

I can perhaps increase the maximum value of the sensitivity slider, of course! (Although this likely won't help with the mouse-clicking stuff.) What sort of value do you think might work for you, given the values of "10" for the default and "20" for the current maximum? (Noting that this operates as a scalar internally, if I recall correctly.)

I've been lurking and watching this bugfixing process with interest. I had a thought about this one. Is there any possibility that the mouse is generating multiple movement events per frame, but your game doesn't correctly respond to that? For example if it only used the movement delta from the most recent event? This could explain the mouse input feeling more sluggish than expected.

[Thaumaturge]

That's an interesting idea... If the mouse-polling rate works by doubling up mouse-movement inputs, and I'm only seeing the most-recent one, that might indeed account for mouse-movement not seeming to work as expected. Specifically, it would seem as though mouse-movement was half as quick as expected.

If so, then I'm not sure of whether this is an oversight on my part, or something that the engine isn't handling. It's something to perhaps bring up on the engine's forum!

Thank you for that suggestion! ^_^

(And I hope that you continue to enjoy the bug-fixing! )

[edit]
In response to a request for additional data from the engine devs, I've updated the test-program again. The link above has been replaced accordingly, but for the sake of convenience and reference, here it is again:
https://www.dropbox.com/s/wyfri7714d9qerf/Mouse-Event%20Tester-0.2.5_manylinux1_x86_64.tar.gz?dl=1

[Whales]

I'm getting a bit lost for words now.

N.B. a correction to a prior post: the pictured mouse is USB, not PS2.

Effects of different mice, polling rates and ports on item-pickup crashing

Mouse models tested:

Nickname	Full model	Details
ms5eye	Microsoft 5-Button Mouse with IntelliEye(TM) X06-25122	USB.  Pictured previously, my main mouse.
ms3eye	Microsoft 3-Button Mouse with IntelliEye(TM) X08-70400	USB
msbasic	Microsoft Basic Optical Mouse X800898	USB
mswireless	Microsoft Wireless Optical Mouse(R) 1.00 X806939	USB.  Will not poll above 125Hz, in practice appears to do about 123 (looks like occasional packets are being skipped)

Test results:

Nickname	Polling rate	Physical Port	Relevant kernel args	Crashes game?
ms5eye	500Hz	USB3	usbhid.mousepoll=2	yes
ms3eye	500Hz	USB2	usbhid.mousepoll=2	no
msbasic	500Hz	USB2	usbhid.mousepoll=2	no
mswireless	123~	USB2	usbhid.mousepoll=2	no
ms5eye	125Hz	USB3		yes
ms3eye	125Hz	USB2		no
msbasic	125Hz	USB2		no
mswireless	123~	USB2		no
ms5eye	125Hz	USB2		no
msbasic	125Hz	USB3		yes
ms3eye	125Hz	USB3		no
mswireless	123~	USB3		no
ms5eye	125Hz	USB3		no

Each test (row) in this table has been repeated a minimum of 3 times.

'USB2' and 'USB3' refer to the physical ports, not the actual speeds and protocols being used by the mice. According to 'lsusb' some of the mice are running at 1.1 when in 2.0 ports.


Analysis & Conclusions

Polling rate: seems irrelevant.
Exact model of mouse: seems irrelevant. EDIT: possibly important, cannot be ruled out yet.
Type of port (USB2/3): seems important.



My suspect mouse stopped crashing the game when I plugged it into a USB2 port.  Then a previously harmless mouse started crashing the game when plugged into a USB3 port.  Then all mice started working fine in the USB3 port and I have not been able to crash the game again -- more testing is needed.

Theory: it's still a timing problem, but somehow caused by using USB3 ports.


I will upload logs from your new test program ASAP.

[Whales]

Obligatory joke: you're a Linux user.  Don't you own any non-microsoft mice?

Actually... um... do D-sub serial mice count?  EDIT: just checked, no that one is MS too  

[Whales]

Rebooted, able to get the game to crash again.  However: my hypothesis regarding USB2/3 now seems to be untrue.

After moving a mouse from a usb3 port to a usb2 port the game still crashes upon item pickup; and after moving a mouse from a usb2 to usb3 port the game continues to work fine.

Question: do you want me to keep posting all of this information here in this thread, or take it somewhere else?  I would love to be able to attach files here, but either I am not allowed or the forum does not support it.

Mouse event tester logs across both crashing and non-crashing mice

Software: mouse event tester 0.2.5
Test pattern: 5 quick clicks, 5 held clicks, spacebar, 5 quick clicks, 5 held clicks, escape
Framerate: 2800-3000FPS (top-right corner of mouse tester)

ADTTM is run before each test to confirm whether or not the mouse crashes the game on item pickup or not.  Item pickup attempted 3 times (inc having to restart game where neccesary) to confirm reliability of the problem.


test1_ms5eye_bad_usb3.txt

Crashes game on item pickup: yes
Physical port on computer: rear USB3
Mouse: ms5eye
Polling: 125Hz (default, no extra kernal opts)

Code:

Bus 002 Device 002: ID 045e:0039 Microsoft Corp. IntelliMouse Optical
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x045e Microsoft Corp.
  idProduct          0x0039 IntelliMouse Optical
  bcdDevice            3.00
  iManufacturer           1
  iProduct                3
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0022
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      72
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              10

test2_msbasic_good_usb2.txt

Crashes game on item pickup: no
Physical port on computer: rear USB2
Mouse: msbasic
Polling: 125Hz (default, no extra kernal opts)

Code:

Bus 004 Device 005: ID 045e:0084 Microsoft Corp. Basic Optical Mouse
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x045e Microsoft Corp.
  idProduct          0x0084 Basic Optical Mouse
  bcdDevice            3.90
  iManufacturer           1
  iProduct                2
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0022
    bNumInterfaces          1mA
    bConfigurationValue     1
    iConfiguration          0 9
    bmAttributes         0xa0 4
      (Bus Powered)ber        0
      Remote Wakeupting       0
    MaxPower              100mA
    Interface Descriptor:     3 Human Interface Device
      bLength                 9 Boot Interface Subclass
      bDescriptorType         4 Mouse
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1   9
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouseot supported
      iInterface              0   1
        HID Device Descriptor:   34 Report
          bLength                 9
          bDescriptorType        33
          bcdHID               1.11
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      52EP 1 IN
         Report Descriptors:    3
           ** UNAVAILABLE **       Interrupt
      Endpoint Descriptor:         None
        bLength                 7  Data
        bDescriptorType         5  1x 4 bytes
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytesation will be missing
        bInterval              10
  bcdUSB               2.00

test3_msbasic_good_usb3.txt

Crashes game on item pickup: no
Physical port on computer: rear USB3
Mouse: msbasic
Polling: 125Hz (default, no extra kernal opts)

Code:

Bus 002 Device 003: ID 045e:0084 Microsoft Corp. Basic Optical Mouse
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x045e Microsoft Corp.
  idProduct          0x0084 Basic Optical Mouse
  bcdDevice            3.90
  iManufacturer           1 
  iProduct                2 
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0022
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.11
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      52
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              10

test4_ms5eye_bad_usb2.txt

Crashes game on item pickup: yes
Physical port on computer: rear USB2
Mouse: ms5eye
Polling: 125Hz (default, no extra kernal opts)

Code:

Bus 004 Device 006: ID 045e:0039 Microsoft Corp. IntelliMouse Optical
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x045e Microsoft Corp.
  idProduct          0x0039 IntelliMouse Optical
  bcdDevice            3.00
  iManufacturer           1 
  iProduct                3 
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0022
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      72
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              10

[Whales]

Polling rate versus sensitivity

Changing between 500Hz and 125Hz does not seem to have a perceptible effect on in-game mouse sensitivity. EDIT: seems a lot more accelerated now, perhaps an effect of less samples?  It's difficult to tell exactly as this process requires a reboot (in order for the same mice to be used), but things "seem" the same.

Leaving the game on its default sensitivity of 10 requires lots of mouse pickups and putdowns to turn the player 90 degrees, using it on its max of 20 is more comfortable but still a bit slow.  I would ask if the total range could be doubled (eg max=40).  

N.B. my mice are only standard DPI mice, nothing fancy.  Both 'crashing' and 'non-crashing' mice feel the same to use in-game.

[Whales]

Now that I am using a different mouse I am able to enjoy the game a bit.

I really appreciate the calm atmosphere.  This isn't a game where I feel like I am going to die around every corner or that I need to savescum.  I have not even touched a quicksave.  I appreciate that: lately I have been playing a lot of Stalker-derived mods where quicksaving every few footsteps is an (unhappy) requirement for life.  Mutant dogs, stray bullets from people hiding in bushes.  In contrast I'm enjoying animal sigils and wondering what more lore of this world I'm going to uncover from mystical bald people.

The combination of mantling (climbing) and calm atmosphere remind me a bit of Thief 1 and 2.  Movement like this is something I really enjoy exercising, especially after years of first-person shooters where you can't climb a waist-high wall.  It's a shame there are invisible walls -- being able to simply wander off into the forest would be nice, even if nothing is out there and the game cheats by teleporting you back if you travel too far.

It's good to be a weak protagonist.  ie someone working for others and not able to keep all that she wants or collects.  I have not played far enough to in to know whether this continues or if we enter the classic infinite-character-power-growth RPG storyline, I will have to see.

Anyway, enough rambling about atmosphere and feelings.  Onto specific details and mechanics.

User interface: very nice font, matches the game.  Scrolling is a bit fiddly.  Dimensions are a bit odd -- eg the scale of padding versus controls -- but this is a game UI, so it's a niggling complaint.

Combat: interesting so far, only two enemies encountered.  Appreciate it being sparse, hope it gets used for subtle story-telling (so far none of the enemies seem to have been relevant to anything other than world building... I think).

Mantling: a bit annoying to lose camera control during mantling; takes my immersion out.  I personally like games where you never lose control of your mouse, ie no unexpected cutscenes or forced control takeovers.

Lighting for inside vs outside: I find the prospect of entering those dark spaces very scary.  It chills me to where my quicksave bones hide, but I've been stretching my trust and so far things have been going well.

Inventory: lovely presentation.  I have no idea why some items are separated, almost like achievements, but maybe that will reveal itself as I go on.  

(EDIT) Vignetting: lamp effect at top-left.  Not my cup of tea, even small amounts make me uncomfortable in 3D games.

(EDIT) Autosaving: greatly appreciated, again keeps me feeling comfortable and less likely to save scum.

Right now I'm stuck so I am taking a break.  

I've found some more information that appears to help me translate a journal, but I'm having no luck.  There are multiple overlapping permutations of 'enet' vs 'net' and no combinations seem to work.

I also have several chests with no obvious way of opening them and it doesn't seem like I'm supposed to use them as stairs outside.  But hey, that won't stop me from trying.



EDIT: dang, nothing of interest up here

EDIT2: found my progression problem:







  Serif attack!

EDIT3: Didn't seem to progress me after all.  Dang.
EDIT4: Aha, I have spent too much of my mortal life feeling safe.  Sometimes it's better to be a small mammal.

[Thaumaturge]

Obligatory joke: you're a Linux user.  Don't you own any non-microsoft mice?

Actually... um... do D-sub serial mice count?  EDIT: just checked, no that one is MS too  

Don't worry--I'm typing this on a Microsoft keyboard myself, so I'm in no position to comment. (And Microsoft keyboard that my Windows installation won't talk to, amusingly enough!)

This mouse-bug is very weird. o_0

And let me say: I really, really appreciate all the effort that you've been going through in testing this bug! It's really helpful, I do think. ^_^

Frustratingly, it looks like the bug doesn't appear at all in the test-program--note that the program printed out exactly forty test-printouts in each case, indicating twenty each of down- and up- events.

Whether that's because it's in some way limited to the game (but how, when the choice of USB port affects the results?!), or because the frame-rate limitation doesn't affect the results in the same way as a true frame-rate, or for some other reason, I don't know! :/

[edit]
Actually, going back and checking, it looks like you didn't apply the frame-rate limiting? (By pressing "enter".) Would you be willing to run one test, please, using one of the "problem mice/USB-ports", and applying the frame-rate limitation?

(If it works, you should see the frame-rate at the top-right drop down to 50.)
[/edit]

Rebooted, able to get the game to crash again.  However: my hypothesis regarding USB2/3 now seems to be untrue.

After moving a mouse from a usb3 port to a usb2 port the game still crashes upon item pickup; and after moving a mouse from a usb2 to usb3 port the game continues to work fine.

Question: do you want me to keep posting all of this information here in this thread, or take it somewhere else?  I would love to be able to attach files here, but either I am not allowed or the forum does not support it.

Hmm... I'm happy to keep it here, myself--but if it'll be easier for you, we could also move to the engine's forum, or some other place.

(For now, I intend to point the engine devs to the relevant posts in this thread.)

Polling rate versus sensitivity

Changing between 500Hz and 125Hz does not seem to have a perceptible effect on in-game mouse sensitivity. EDIT: seems a lot more accelerated now, perhaps an effect of less samples?  It's difficult to tell exactly as this process requires a reboot (in order for the same mice to be used), but things "seem" the same.

Leaving the game on its default sensitivity of 10 requires lots of mouse pickups and putdowns to turn the player 90 degrees, using it on its max of 20 is more comfortable but still a bit slow.  I would ask if the total range could be doubled (eg max=40).  

N.B. my mice are only standard DPI mice, nothing fancy.  Both 'crashing' and 'non-crashing' mice feel the same to use in-game.

My guess is that it's related to the method by which that kernel option of yours increases the polling-rate.

In the game, what I do is pretty much this:

• Get the position of the mouse
• Recentre the mouse
• Use the mouse-position to turn the player's view

Thus it would looks like the engine isn't seeing all of the movement that it ostensibly should.

Now that I am using a different mouse I am able to enjoy the game a bit.

Ah, I'm very glad to read that! :D

The combination of mantling (climbing) and calm atmosphere remind me a bit of Thief 1 and 2.

Ah, that's enthusing to read! Thief 1 and 2 were indeed major influences on this game, so I'm happy that some of that influence is coming through. :D

It's a shame there are invisible walls -- being able to simply wander off into the forest would be nice, even if nothing is out there and the game cheats by teleporting you back if you travel too far.

That would be wonderful--but alas, likely a little out of the scope of this already-rather-large project, given that I'm a solo dev.

It's good to be a weak protagonist.  ie someone working for others and not able to keep all that she wants or collects.  I have not played far enough to in to know whether this continues or if we enter the classic infinite-character-power-growth RPG storyline, I will have to see.

Oof, it's tempting to answer this! But perhaps better not to, in order to preserve discovery. I will say that this game isn't an RPG--there's no real levelling.

User interface: very nice font, matches the game.  Scrolling is a bit fiddly.  Dimensions are a bit odd -- eg the scale of padding versus controls -- but this is a game UI, so it's a niggling complaint.

Good to read, overall. ^_^

I do agree about the scrolling. It's on my to-do list as something to look at, but alas, the engine's GUI system doesn't make that convenient. :/

Combat: interesting so far, only two enemies encountered.  Appreciate it being sparse, hope it gets used for subtle story-telling (so far none of the enemies seem to have been relevant to anything other than world building... I think).

Hmm... I haven't really thought of the enemies in that way, but some are more plot- and characterisation- relevant than others, I do think.

Mantling: a bit annoying to lose camera control during mantling; takes my immersion out.  I personally like games where you never lose control of your mouse, ie no unexpected cutscenes or forced control takeovers.

Hmm... I could perhaps allow mouse-looking while climbing. I might experiment with that, and see how it feels!

(I don't want to allow more control over climbing than there now is, as that would require reworking things more thoroughly, and change the feel of the game, I think.)

Lighting for inside vs outside: I find the prospect of entering those dark spaces very scary.  It chills me to where my quicksave bones hide, but I've been stretching my trust and so far things have been going well.

Inventory: lovely presentation.

That's all very good to read! :D

I have no idea why some items are separated, almost like achievements, but maybe that will reveal itself as I go on.  

I feel like I can safely answer this: In short, there are collectibles in this game, as well as actual inventory items. While inventory items are useful, collectibles are just that: things to collect.

Specifically, there are two sets of "collectibles": items, and lore. The former comes with a nice list showing exactly how many collectible items there are; the latter never tells you exactly how much there is to find, or whether you might have missed something...

(EDIT) Vignetting: lamp effect at top-left.  Not my cup of tea, even small amounts make me uncomfortable in 3D games.

Ah, I'm sorry to read that. I can perhaps add an accessibility option to disable it!

I've found some more information that appears to help me translate a journal, but I'm having no luck.  There are multiple overlapping permutations of 'enet' vs 'net' and no combinations seem to work.

I also have several chests with no obvious way of opening them and it doesn't seem like I'm supposed to use them as stairs outside.  But hey, that won't stop me from trying.

To the former, I'll note that if you can access a translation puzzle, it should be possible to solve it: the character will outright refuse to enter a translation minigame without all of the required word-roots.

That said... There is an element of the minigame that I fear isn't well-taught right now, and that isn't very clear. It would be easy to make it obvious--but that might render things a little too easy. It's something that I'm still thinking about...

EDIT2: found my progression problem:

Aaand there's that! Good catch--I should perhaps capitalise those entries for clarity! ^^;

EDIT4: Aha, I have spent too much of my mortal life feeling safe.  Sometimes it's better to be a small mammal.

Hahah, very much so in this game! XD

Hmm... Am I correct in guessing that what you'd missed was the hole in the ceiling of a certain tomb? If so, then that's a proven to be a tricky bit of design: how does one get the player to look up?

Overall, I'm happy that you seem to be enjoying the game! ^_^

[Thaumaturge]

Blog post (3rd of February, 2020)
Making Progress

Summary: In which a new enemy is begun; and a strange bug surfaces.

Greetings and salutations!

This week's screenshot shows some new content--specifically, a new enemy in the works:



The work of the week just past was primarily given to that enemy--but a fair bit of time was also given to an odd and frustrating bug:

To start with, the enemy above.

In the wake of the demos, a lot of time has gone into changes made in response to feedback given, which has been, I hope, polishing and improving the game. And while this has been useful, it had also resulted in my feeling that the game had somewhat stalled, that it might be more polished, but that without work on new content, it wasn't moving forward.

Make no mistake, I am not unhappy that I've been given the feedback that I have, nor do I wish to dissuade any further! Far from it: I'm deeply grateful for that feedback, and hope that people continue to give it.

Still, I'm glad to say that while there are a number of feedback matters yet to attend to, in the week just past I finally felt that I was in a position to return somewhat to work on the game's content.

And to that end, I've started in on a new enemy for the game! ^_^

This character isn't intended for the next level in sequence--I intend to skip that level and return to it later, focussing next on the rather shorter levels that come directly after. In this way I hope to gain a "quick win", and the sense of progress and accomplishment that comes with it, before going back to another planned-to-be long-ish level.

As to the enemy's status, they're still very much a work-in-progress. I have first drafts at the least of most of their animations, I think, but there's still a fair bit to be done. Not to mention the work of actually implementing them, both as a combatant and within their level.

On the technical side, in the week just past a rather strange and frustrating bug was discovered.

A player reported to me that, when they attempted to pick up an item, the game quite consistently crashed. Based on the game's log, it seemed to be that the game was attempting to act on an item that had already been destroyed, leaving it with invalid data.

But why?

My best guess right now is that, somehow, the game is receiving multiple mouse-up events in a single update. That might result in the first mouse-event causing the item to be taken, and thus its in-level version to be destroyed. Without an update occurring between the first mouse-event and the second, the latter event might cause the game to then attempt to act on the same in-level item--which has been destroyed, and thus is no longer valid.

But why might that be happening? It didn't seem to happen on my machine, and this was the first report of such a thing that I'd heard.

What's stranger, testing seems to indicate that such things as swapping out the mouse or even changing the mouse's USB port could affect whether or not the bug showed itself!

For now, investigation continues! (With the great help thus far of the player who reported it!)

That then is all for this week--stay well, and thank you for reading! ^_^

[Whales]

Have had this morning away from work.

Mouse tester at 50FPS

Apologies for missing this.

test5_both_50fps.txt

Input:  5 goodmouse clicks, 5 badmouse clicks, enter, 5 goodmouse clicks, 5 badmouse clicks, spacebar, 5 goodmouse clicks, 5 badmouse clicks, escape.  Mice were used in a session of ADTTM before testing.

The up/down counts onscreen didn't do anything fancy or strange.


Mouse movement sampling

My guess is that it's related to the method by which that kernel option of yours increases the polling-rate.

In the game, what I do is pretty much this:

• Get the position of the mouse
• Recentre the mouse
• Use the mouse-position to turn the player's view

Thus it would looks like the engine isn't seeing all of the movement that it ostensibly should.

That's the standard method and it's what I use in my game.  No other game feels quite like yours mouse-wise, however.  Apart from needing to be on very high mouse sensitivity your game also feels "stuttery" as I move the mouse.

There are all sorts of fine details you could be doing differently.  

(1) Are you performing any mouse input smoothing or mouse input modification in any way?  ie is any one mouse movement affecting variables that last more than the current frame or does character rotational change depend on variables from previous frames?

(2) Does any of your code, between sampling mouse position (relative to window center) and applying this as rotation, depend on any sort of time variable?  Eg frametime/framedelta?  Eg applied as a velocity to rotation rather than instant rotation change?

(It shouldn't depend on any of this, mouse movement already has the time dimension inherently built in.  Involving time in your equations invites frametime dependent behaviors).

It's probably not much more than a curiosity, but this is what I do:

Code:

	int relmousex, relmousey;
	{
		if (cio_input_window_winched || !cio_input_mousecaptured)
		{
			relmousex = 0;
			relmousey = 0;
		}
		else
		{		
			SDL_GetMouseState(&relmousex, &relmousey);
			relmousex -= cio_input_window_sizex/2;
			relmousey -= cio_input_window_sizey/2;
			SDL_WarpMouseInWindow(win, cio_input_window_sizex/2, cio_input_window_sizey/2);
		}
	}
	cio_input_rotate_pitch = 0.1 * relmousey;
	cio_input_rotate_roll = 0;
	cio_input_rotate_yaw = 0.1 * relmousex;

[...]

	playerobject->rot.x += cio_input_rotate_pitch;
        playerobject->rot.y += cio_input_rotate_roll;
        playerobject->rot.z += cio_input_rotate_yaw;

From a physics perfectionist standpoint: this means there is no rotational velocity, only teleports to the new rotational position, but mice are (almost always) sampled higher than visual framerate so this is only something that really needs considering for specific network/physics smoothing situations.


Human psychology

Hmm... Am I correct in guessing that what you'd missed was the hole in the ceiling of a certain tomb? If so, then that's a proven to be a tricky bit of design: how does one get the player to look up?

It's damn hard.  We're only wired to look up if there are predators from above, otherwise we completely zone out of everything above hat level.  You could try to tap into a bit of psychology and add some vicious pictures or sounds of birds, perhaps


New information

Now that I'm further in I have been able to test badmouse on more objects.  Interesting results, EDIT: not everything is 100% reliable, sometimes clicks on the badmouse are normal.

N.B. My mice are plugged into the opposite ports of previous tests, so today badmouse and goodmouse have traded positions.  During the testing for below I kept switching between the two mice to confirm that one works fine and the other causes problems.  Badmouse and goodmouse stay stable across game restarts; it's only computer reboots and re/plugging them in that can causes change.

Picking up inventoryable or collectable items: immediate crash, as per before.  

Picking up repositionable items (eg chests):  item immediately vanishes and a sound effect plays (possibly a distant 'put-down' sound?).  Nothing is carried in hands.  Small glitchiness afterwards when trying to pick up other objects (game sometimes thinks objects are ontop of others).  Useful for removing clutter in messy dungeons.

EDIT: the glitchy imaginary-object-ontop might be triggered by me using goodmouse to pickup and badmouse to put down.

Doors and curtains: Immediately enters the wrong animation.  Eg if door is closed: enters closing animation instead of opening.  Same effects as if I had double-clicked with a good mouse.

Activating puzzles (lockpicking, letter arrangement): Puzzle opens as per normal.  Nothing untoward, as far as I can tell, but I might not be looking hard enough.

Q: Are you looping through input devices anywhere that could affect where/how clicks are born?

[Thaumaturge]

Apologies for missing this.

Not a problem! Thank you for coming back to it! ^_^

As to the results and observations that you gave, hmm...

Given that the issue hasn't appeared in the test-program, even with a frame-rate limitation in place, it looks like the problem likely isn't as simple as multiple events being generated as a matter of course.

That said, the observations of various gameplay behaviours do seem to support the hypothesis that this does stem from multiple events being generated in some way.

I'm thus inclined to suspect that it might be related to the way that I handle input devices other than keyboards and mice. Indeed, I've actually had a case of a single phantom mouse-up event being generated there--albeit in that case only one, and only when first attempting to bind a control.

So, if I may ask, when this issue appears do you have any other peripherals plugged in at all? Another mouse, a drawing tablet (especially a drawing tablet), a gamepad, anything at all?

(There are other experiments that I could run at this point, but I fear that I've imposed enough on your time and patience! ^^; At this point, I think that it might be worth my while installing Void Linux beside my main OS and seeing if I can't replicate the issue on my side...)

Q: Are you looping through input devices anywhere that could affect where/how clicks are born?

Hmm... A lot of that sort of stuff is happening behind the scenes, on the engine-side, rather than in my own code. However, the code that handles key-binding does in places loop through available devices and bind events to them, if I recall correctly (so that it can detect attempted bindings). Quite why the code in question might be causing such an issue--especially given that it doesn't seem to happen on all systems--I'm not yet sure...

That's the standard method and it's what I use in my game.  No other game feels quite like yours mouse-wise, however.  Apart from needing to be on very high mouse sensitivity your game also feels "stuttery" as I move the mouse.

Hmm, that's a problem. :/

(1) Are you performing any mouse input smoothing or mouse input modification in any way?  ie is any one mouse movement affecting variables that last more than the current frame or does character rotational change depend on variables from previous frames?

(2) Does any of your code, between sampling mouse position (relative to window center) and applying this as rotation, depend on any sort of time variable?  Eg frametime/framedelta?  Eg applied as a velocity to rotation rather than instant rotation change?

I've checked, and no, it doesn't seem to be doing any such thing.

In addition, while I haven't had a lot of feedback thus far, this is nevertheless thus far the only report that I've had of it behaving so. (And indeed, it doesn't seem to happen on my machine.) Thus I'm inclined to think that it's caused by some interaction between one or both of my code or the engine and something in your setup. (Which is not to say that it's your "fault", please note! It may very well be some oversight on my part of some case that happens to be present in your setup.)

For reference, here is how I handle player-turning:

(See the notes below the excerpt for explanations regarding variables, methods, and some of my implementation choices.)

Code:

        if base.mouseWatcherNode.hasMouse() and base.win.hasSize():
            xSize = base.win.getXSize()
            ySize = base.win.getYSize()
            xPix = float(xSize % 2)/xSize
            yPix = float(ySize % 2)/ySize
            mousePos = Vec2(base.mouseWatcherNode.getMouse())
            mousePos.addX(-xPix)
            mousePos.addY(-yPix)
            if abs(mousePos.x) < xPix:
                mousePos.x = 0
            if abs(mousePos.y) < yPix:
                mousePos.y = 0

            base.win.movePointer(0, xSize//2, ySize//2)
        else:
            mousePos = Point2(0, 0)
        
        # A big chunk of largely-unrelated code omitted here for brevity...

        horiTurn = mousePos.x + (-keys["lookLeft"] + keys["lookRight"])*3.0*dt
        vertTurn = mousePos.y + (-keys["lookDown"] + keys["lookUp"])*3.0*dt

        self.manipulator.setH(self.manipulator, -horiTurn*self.mouseSensitivity*self.turnRate)
        
        newP = self.headBaseNodePath.getP() + vertTurn*self.mouseSensitivity*self.turnRate
        # Some code omitted here that places limitations on how far up or down the player can look
        self.headBaseNodePath.setP(newP)

Notes:

• "base.mouseWatcherNode" is provided by the engine
• "base.mouseWatcherNode.getMouse()" returns the mouse-position, in the range [-1, 1], [-1, 1], if I recall correctly.
• The "xPix, yPix" stuff accounts for window-sizes that aren't even; without it, I find that I sometimes get unwanted drift
• The "keys" variable holds inputs from things like the keyboard or a gamepad, hence the delta-time inclusion there; it shouldn't be affected by the mouse. Note that the delta-time there doesn't apply to the mouse-input.
• "self.turnRate" and "self.mouseSensitivity" should be constant, outside of user-modification of the latter via the options menu.
• To explain "setH" and "setP": The engine uses aircraft-related terminology for rotations; "H" is "Heading", "P" is "Pitch" (and "R" is "Roll").

You could try to tap into a bit of psychology and add some vicious pictures or sounds of birds, perhaps

The funny thing is that I even more or less painted arrows pointing up--albeit subtly--on the walls beneath the roof in question! XD

That said, while your exact suggestion might not work in this case, it does spark an idea: perhaps, the first time that the player stands in the relevant room and looks in the general direction of that roof, a small, precariously-perched stone or some such might fall from the hole. That might help to signal to players that there's something to look at there, and to look upwards.

That said, I don't intend to apply this degree of hand-holding throughout the game! While perhaps useful early on, I would want players to eventually learn to look around themselves while exploring.

[Whales]

I'm thus inclined to suspect that it might be related to the way that I handle input devices other than keyboards and mice.

Ahah!  I encountered something similar a few months back with a different game, Lucifer's atoms.  The game would notice/interpret some keystrokes even when the window was not focused (eg when I'm typing a password into an unrelated program  ).  Turns out the game thought my keyboard was a controller.

I should have thought of this.  My head has been squarely stuck thinking about mice, not keyboards.

I fear that I've imposed enough on your time and patience!

Apologies if I have done the same to you.  Happy to do more tests if you want me to, otherwise enjoy your development and don't let strange Australians drag you off kilter.

The funny thing is that I even more or less painted arrows pointing up--albeit subtly--on the walls beneath the roof in question! XD

What?  Nope, completely blind.

That said, I don't intend to apply this degree of hand-holding throughout the game! While perhaps useful early on, I would want players to eventually learn to look around themselves while exploring.

Indeed.  FWIW: I didn't mind being lost and confused.  Coming back to the game later helped.  It's something people used to complain about having to do in the 90's, but these days everything is so hand-holdly I'm eager for the opposite


RE mouse stuttering: might be due to uneven frametimes.  I'll have a poke later.

[Thaumaturge]

Ahah!  I encountered something similar a few months back with a different game, Lucifer's atoms.  The game would notice/interpret some keystrokes even when the window was not focused (eg when I'm typing a password into an unrelated program  ).  Turns out the game thought my keyboard was a controller.

I should have thought of this.  My head has been squarely stuck thinking about mice, not keyboards.

Ah, interesting. I'm not sure of why the system would be generating additional "mouse presses", but it's not impossible.

Just to double check: are there any other peripherals connected during play? It's entirely possible that there's some other peripheral that's similarly misinterpreted.

Apologies if I have done the same to you.  Happy to do more tests if you want me to, otherwise enjoy your development and don't let strange Australians drag you off kilter.

In going through the trouble of helping me to diagnose a troublesome bug, and in providing detailed feedback, you have not imposed on me at all! ^_^

Well, if you're willing, I might ask for another test sometime soon. I'm interested to see how the engine is interpreting your various peripherals, and whether you see multiple "mouse-clicks" if we incorporate my key-binding module into the test...

What?  Nope, completely blind.

Heh, on the walls below the roof in question there are "scratches" or other such marks, arranged to look sort of like an arrowhead. I was hoping to subtly suggest that players look up. ^^;

Indeed.  FWIW: I didn't mind being lost and confused.  Coming back to the game later helped.  It's something people used to complain about having to do in the 90's, but these days everything is so hand-holdly I'm eager for the opposite

Ah, I'm glad to read it! I do think that a little bit of early hand-holding isn't a bad idea, to teach players what's expected of them. Part of what feedback on these demos has done has been to direct me to places that call for a bit of extra hand-holding.

RE mouse stuttering: might be due to uneven frametimes.  I'll have a poke later.

It's possible, although it seems unlikely--unless you're getting really bad lag-spikes for some reason, I suppose.

[Whales]

Ah, interesting. I'm not sure of why the system would be generating additional "mouse presses", but it's not impossible.

First button on mouse == first button on controller?  eg the 'A' button?

Just to double check: are there any other peripherals connected during play? It's entirely possible that there's some other peripheral that's similarly misinterpreted.

No gaming/controller periphs.  Just two mice and a PS2 keyboard. 

Code:

$ lsusb
Bus 003 Device 004: ID 045e:0039 Microsoft Corp. IntelliMouse Optical
Bus 003 Device 003: ID 14cd:168a Super Top   [Whales: My memory-card reader]
Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 045e:0084 Microsoft Corp. Basic Optical Mouse
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

$ ls /dev/input/
by-id/    event1   event12  event15  event18  event20  event5  event8  mouse0
by-path/  event10  event13  event16  event19  event3   event6  event9  mouse1
event0    event11  event14  event17  event2   event4   event7  mice

$ ls /dev/js*
ls: cannot access '/dev/js*': No such file or directory

Well, if you're willing, I might ask for another test sometime soon. I'm interested to see how the engine is interpreting your various peripherals, and whether you see multiple "mouse-clicks" if we incorporate my key-binding module into the test...

Certainly. 

RE mouse stuttering: might be due to uneven frametimes.  I'll have a poke later.

It's possible, although it seems unlikely--unless you're getting really bad lag-spikes for some reason, I suppose.

Looks like I'm not quite hitting a consistent margin above 60FPS and there are occasional long framedeltas as I rotate the camera:



Likely a CPU bottleneck on my system.  Not the fastest in the world, i5-3470S.

I'm also encountering flickering geometry the longer I play on this level.  I suspect it may be related to repeated save/loads.



Third level: city under a city

I've been stuck in this level for the past few days.  I found the hanging brass sheet and initially assumed it was the source of the distant "light", but I now know the light comes from further in the level.  I have not been able to progress any further than the giant mound of climbable rubble (sealed alleyway next to the double-ladder room).

I spotted a marking on a wall that appeared to be pointing up.  A bit of rooftop hopping later and I was stuck:
 


Woops   It's fun to discover hidden places like this.

Anyway, whilst stuck on this level I've been experimenting with the gameplay mechanics quite a lot and I have built a small repertoire of advanced broken chable manipulation techniques.  If you saw me playing your game now I would probably cause you great anguish

In the area I'm stuck in there's a room with no ladder leading up a hole in the roof.  I assumed you needed chables to get through it, so I gamed an extra one across the map:



Unfortunately it looks like this hole in the ceiling has an invisible barrier.

More chable gymnastics:



View from top into depths of level:



Sadly I die if I try to drop down from here.  More experimentation needed.

Am I legitimately stuck, or is this level incomplete?

[Thaumaturge]

First button on mouse == first button on controller?  eg the 'A' button?

It's possible, I suppose!

No gaming/controller periphs.  Just two mice and a PS2 keyboard.

Hmm. I do wonder whether it's not the presence of two mice--although I did test that on my end, and the bug didn't turn up. But the misidentified keyboard could well be a source of issues, too!

Certainly. 

Thank you. ^_^

I'll likely get back to you with another small test-program either tomorrow (i.e. Saturday here) or in the new week.

Looks like I'm not quite hitting a consistent margin above 60FPS and there are occasional long framedeltas as I rotate the camera:

...

Likely a CPU bottleneck on my system.  Not the fastest in the world, i5-3470S.

Ah, those spikes are a pity. :/

It's possible that it's your CPU, but it's also possible of course that the geometry isn't ideal--I'm not terribly experienced in building level-geometry, I fear, let alone with an eye towards performance! ^^;

I'm also encountering flickering geometry the longer I play on this level.  I suspect it may be related to repeated save/loads.

Argh, that's frustrating!

Hum. That suggests a culling issue of some sort, although I'm not sure quite what might be doing it...

Woops   It's fun to discover hidden places like this.

O-oh dear. ^^; I should perhaps look around to find that spot, and fix it!

Anyway, whilst stuck on this level I've been experimenting with the gameplay mechanics quite a lot and I have built a small repertoire of advanced broken chable manipulation techniques.  If you saw me playing your game now I would probably cause you great anguish

Not at all! I want players to experiment, and find paths--perhaps even paths and methods that I hadn't thought of! ^_^

Unfortunately it looks like this hole in the ceiling has an invisible barrier.

Ah, oops--I should fix that, either removing the barrier or (more likely) closing the hole with something above it.

More chable gymnastics:

...

View from top into depths of level:

...

It is nice to see you exploring so, I will say. ^_^

Am I legitimately stuck, or is this level incomplete?

You are legitimately stuck; it is entirely possible to proceed (presuming that nothing's broken somewhere).

That said... I was worried about this mechanic. Indeed, if I recall correctly, that was at least one of the reasons that I used it here: to remind the player that it exists.

Since you got here, I presumably found the book at the end of the previous level. Which means that you figured out the secret of the curtain in that final room...

(Hmm. This mechanic may call for further thought, then. It would be a pity to remove it entirely, as it affects other interactions that I feel benefit from it. But if it's not something that players are likely to figure out...)

[Whales]

You are legitimately stuck; it is entirely possible to proceed (presuming that nothing's broken somewhere).

Excellent.

EDIT: wait no, I am supposed to finish some work this weekend.  Bad Thaumaturge.

EDIT2: found my way.  Felt a little odd, given all of the passive things that I had encountered previously that gained nothing from probing.

Various bugs

Tell me if any of these interest you or if you want further information.

Flickering is getting very obnoxious.  I'd agree it's culling related, the flicker rate depends on movement.  Even items in my hands flicker in and out of existence.  Culled items become dark shadows -- it seems that the lighting system uses a different culling method for determining which objects to project upon.



The above door (shelves + scratches room) doesn't survive save-load properly if left open: hitbox stays in open position (for both character collision and mouse ray casting) but visually the door ends up in the closed position.  I'll see if others are like this.

Stacked chables do not necessarily survive save-load.  Instead the top one falls inside the bottom one (making an 8-legged chable on the ground).



Quick-loading ('L') whilst the death dialog is up leads to a black screen.  Loading again fixes this problem.

Found a non-colliding mesh (wall) that lets me exit the map and enter the void.  Disappointed by lack of spirits.