Hello!
Currently I'm using 120.0.1 r7373 with the newest version of pak192.comic. When I'm pressing down the key not mentioned to be pressed I get such message (see pic below). That thing doesn't occur with pak64: I get list of keys. What's up?
Must be some error in the help text for pak192.comic. (Plus the fact that Simutrans doesn't do full error checking on the things it is given. It just goes with it, until the OS puts down its foot.)
What key? Please explain more the steps you do to cause the crash (what action triggers it).
I think the OP means any key with no defined action?
I thought he meant any key, as he gets help text with pak64. (I think there was some error in the help text earlier.) Now that I actually took the time to enlarge the screenshot, I see that it is actually a way tool that is crashing, and the key is just something that is bound in pak192.comic, but unused in pak64.
Why screenshot?!? Anyway I can press almost any key and nothing crashes for me. Even with an undefined language.
The error dialog art appears to be that of an older Windows operating system (anywhere from 98 to XP although it could be Vista/7 with aero off). It is possible that this is a legacy support issue.
Some standard windows library features only run correctly on more modern operating systems. If simutrans used any of those (I think some are used when building for Windows based on what I saw when investigating the nightly build issue) they could be returning unexpected results and thus cause an error. However I do admit it seems strange that it is only affecting one pakset.
I think the only way for this to happen, is that werkzeug_t::default_param == NULL or wegbauer_t::weg_search() returns NULL.
Could also be pressing 't' to activate default track, but no track is available? There is very precise information about the place of the failed assertion in the screenshot.....
Quote from: Dwachs on December 03, 2014, 06:05:19 PM
Could also be pressing 't' to activate default track, but no track is available?
That's along the lines of what I was thinking while writing my last post, but I got lost in the code trying to figure out how the tools were configured. I could only find the tools that were configured when a specific besch was loaded, and then there obviously will be a way type available for that tool. But if tools are constructed elsewhere, not tied to a particular besch, the possibilities are opening up again.
I'm using Windows 7 with the ol' good theme (so without aero, I find it an useless thing that's consuming additional power of my graphic card) and a modified menuconf.tab. All keys I defined in it are working correctly. The other - aren't.
there was a problem with the menuconf.tab. Check with r7397
Quote from: Dwachs on December 04, 2014, 02:31:56 PM
there was a problem with the menuconf.tab. Check with r7397
I'm curious. What exactly in menuconf.tab triggered all of this?
Quote from: Ters on December 04, 2014, 04:04:50 PM
I'm curious. What exactly in menuconf.tab triggered all of this?
There problem was this line:
general_tool[14]=,,11,,1
essentially too much commas. It generated a tool with a weird hotkey and NULL default parameter. If an unknown key is pressed, a help page with all defined keys is generated,
which uses tooltip functionality. The tooltip function did not check for missing parameter (and NULL besch) -> boom.
There may be more problems with simutrans not properly treating broken or invalid menuconf.tab
That was quite a roundabout way of involving a pak set specific file (yet not the pak files themselves), the help window and the construction tools. (Which reminds me that I haven't gotten the verdict on my equally roundabout theory for "impossible" data at work. Computer debugging could probably make House look like child's play. Maybe not as entertaining for the average guy, though.)
I resolved the problem succesfully by correcting mentioned string to
general_tool[14]=,,11
Thank you!