[Netspark]

Heyya together.

I don't knmow what goes wrong with Mapster but as soon as I want to copy a sector by selecting it's sector vertices with R-Alt, the vertice anchors start blinking and the sector can be moved but not copied. All that happens when pressing C is the message "Sprites have been copied"

Checking videos on youtube also clearly state that the sector should be shrouded green indicating that the whole thing is selected but can't move Mapster to behave like that. Is there a special modifier key to make Mapster select sectors as intended and not only it's wall vertices?

This is really frustrating as I never had such problems with BUILD in the past - Pushing R-Alt, dragging the purple frame around the sector vertices and TADA, the sector was shrouded green and ready to be duplicated.

[TerminX]

I thought the key to copy highlighted sectors was insert...

[Helixhorned]

Netspark, on 28 October 2013 - 05:26 PM, said:

I don't knmow what goes wrong with Mapster but as soon as I want to copy a sector by selecting it's sector vertices with R-Alt, the vertice anchors start blinking (...)

Apparently, RAlt gets interpreted as RShift under your keyboard layout then. What happens if you switch to US? The recent switch to SDL2 has introduced a variety of similar issues for users with international keyboard layouts.

[Mike Norvak]

Helixhorned, on 29 October 2013 - 10:29 AM, said:

Apparently, RAlt gets interpreted as RShift under your keyboard layout then. What happens if you switch to US? The recent switch to SDL2 has introduced a variety of similar issues for users with international keyboard layouts.

It's happening to me with 4200. I can't use Alt, even if I switch the keyboard to US

[neoacix]

There are several bugs with the SDL2 implementation:

- RAlt
- differences between 2D and 3D mode with different keyboard layout keys like Z and Y (german <-> english layout)
- the NUM-Switch has an effect (eg in 2D with scaling and placing textures)
- negative values in sprite editing (eg X-Vel) with minus (-) is not possible on german layout, have to use 65535 for -1 instead ...

This is why I often use the r4096 build of mapster for mapping.

I hope this will be fixed in further updates.

[Hendricks266]

The team is chipping away at the input issues. I fixed the mousewheel most recently. Next up will be AltGr / RAlt.

[Hendricks266]

AltGr debugging build (and any other keys that don't work)

1. Download this build: edit: http://hendricks266....g_20140127_2.7z
2. Open Mapster32. Press no keys on the keyboard.
3. Hammer one key you know not to work properly many times (at least 10).
4. Close the program.
5. Post the log here, saying what key it was that you hammered.
6. Repeat 2-5 for all malfunctioning keys.

For example, when I hammer RAlt, I get this line many times:

SDL2: got key 230, 184

[Daedolon]

SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184

SDL2: got key 41, 1
SDL2: got key 41, 1
SDL2: got key 20, 16
SDL2: got key 20, 16
SDL2: got key 28, 21
SDL2: got key 17, 49

The last block should be ESC, Q, Y, N, but for some reason there are duplicates for ESC and Q.

Not to mention the whole block of AltGr looks funky as hell.

[Mike Norvak]

Spoiler

SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 224, 29
SDL2: got key 230, 184
SDL2: got key 41, 1
SDL2: got key 41, 1
SDL2: got key 20, 16
SDL2: got key 20, 16
SDL2: got key 28, 21
SDL2: got key 28, 21
SDL2: got key 17, 49
polymost_glreset()

Alt Gr

[Helixhorned]

Daedolon, on 27 January 2014 - 03:06 AM, said:

SDL2: got key 224, 29
SDL2: got key 230, 184

So, on pressing RAlt, SDL2 wrongly reports SDL_SCANCODE_LCTRL, while on releasing the key, it's SDL_SCANCODE_RALT as expected. This looks like a bug in SDL2 or lower levels.

[Hendricks266]

New build that also shows whether it's SDL_KEYDOWN (768) or SDK_KEYUP (769).

http://hendricks266....g_20140127_2.7z

[neoacix]

AltGr

SDL2: got key 224, 29, 768
SDL2: got key 230, 184, 768
SDL2: got key 224, 29, 769
SDL2: got key 230, 184, 769
...

Y:
SDL2: got key 29, 44, 768

Z:
SDL2: got key 28, 21, 768

Y and Z have a different behaviour in 2D/3D-mode.

Right Shift:
SDL2: got key 229, 54, 768
SDL2: got key 229, 54, 769

8 on Numblock (no difference if Num is enabled or not)
SDL2: got key 96, 72, 768
SDL2: got key 96, 72, 769

And now, holding RShift and pressing the 8 on the Numblock 5 times without Num and then 5 times with Num enabled:

SDL2: got key 229, 54, 768 -
SDL2: got key 229, 54, 768 \
SDL2: got key 229, 54, 768 |
SDL2: got key 229, 54, 768 } holding RShift
SDL2: got key 229, 54, 768 |
SDL2: got key 229, 54, 768 /
SDL2: got key 229, 54, 768 -
SDL2: got key 96, 72, 768
SDL2: got key 96, 72, 769
SDL2: got key 96, 72, 768
SDL2: got key 96, 72, 769
SDL2: got key 96, 72, 768 ... pressing the 8 five times
SDL2: got key 96, 72, 769
SDL2: got key 96, 72, 768
SDL2: got key 96, 72, 769
SDL2: got key 96, 72, 768
SDL2: got key 96, 72, 769
SDL2: got key 229, 54, 769 ... releasing RShift
SDL2: got key 83, 69, 768 ... pressing Num (Num is on now)
SDL2: got key 83, 69, 769
SDL2: got key 229, 54, 768 ... holding RShift again
SDL2: got key 229, 54, 768
SDL2: got key 229, 54, 768
SDL2: got key 229, 54, 768
SDL2: got key 229, 54, 768
SDL2: got key 229, 54, 768
SDL2: got key 229, 54, 769
SDL2: got key 96, 72, 768 ... and starting pressing 8 five times again
SDL2: got key 96, 72, 769
SDL2: got key 229, 54, 768 <- difference here!!!
SDL2: got key 229, 54, 769
SDL2: got key 96, 72, 768
SDL2: got key 96, 72, 769
SDL2: got key 229, 54, 768
SDL2: got key 229, 54, 769
SDL2: got key 96, 72, 768
SDL2: got key 96, 72, 769
SDL2: got key 229, 54, 768
SDL2: got key 229, 54, 769
SDL2: got key 96, 72, 768
SDL2: got key 96, 72, 769
SDL2: got key 229, 54, 768
SDL2: got key 229, 54, 769
SDL2: got key 96, 72, 768
SDL2: got key 96, 72, 769
SDL2: got key 229, 54, 768
SDL2: got key 229, 54, 769

This shows why you have to enable Num in mapster to move textures in 3D-mode, because without Num enabled they got scaled like you press 8 without Shift...

Pressing 1 (left side, not on the Num-Block) with and without Caps-Lock:
SDL2: got key 30, 2, 768 ... press
SDL2: got key 30, 2, 769 ... release

Caps-Lock has an effect in mapster in 2D-mode.
For example if you want to save your map with "a" and then type a name with a number eg "map23".
If Caps-Lock is enabled it would look like this: MAP"§
This is new since SDL2 and kind of ennoying, because you use Cap-Lock for changing between gravity-mode, free-look, ...

Okay, enough bugs for the moment.

[Daedolon]

Helixhorned, on 27 January 2014 - 10:22 AM, said:

So, on pressing RAlt, SDL2 wrongly reports SDL_SCANCODE_LCTRL, while on releasing the key, it's SDL_SCANCODE_RALT as expected. This looks like a bug in SDL2 or lower levels.

Actually I just noticed, the weird thing is if you hold LCTRL and ALTGR and start dragging the mouse, then release the keys, the selection area flashes very quickly AND the actual sectors do indeed get selected.

[Helixhorned]

Helixhorned, on 27 January 2014 - 10:22 AM, said:

So, on pressing RAlt, SDL2 wrongly reports SDL_SCANCODE_LCTRL, while on releasing the key, it's SDL_SCANCODE_RALT as expected. This looks like a bug in SDL2 or lower levels.

neoacix, on 27 January 2014 - 12:30 PM, said:

AltGr

SDL2: got key 224, 29, 768
SDL2: got key 230, 184, 768
SDL2: got key 224, 29, 769
SDL2: got key 230, 184, 769

I was wrong then. Here, RAlt generates the pair SDL_SCANCODE_LCTRL and SDL_SCANCODE_RALT, in this order, for both press and release events.

Daedolon, on 27 January 2014 - 01:10 PM, said:

Actually I just noticed, the weird thing is if you hold LCTRL and ALTGR and start dragging the mouse, then release the keys, the selection area flashes very quickly AND the actual sectors do indeed get selected.

In the editor, RAlt is expected to be pressed alone. You could also try the following: after pressing and holding RAlt, press and release LCtrl, keeping RAlt pressed. Now, do you see the yellow selection rectangle?

[Daedolon]

Helixhorned, on 28 January 2014 - 01:17 AM, said:

You could also try the following: after pressing and holding RAlt, press and release LCtrl, keeping RAlt pressed. Now, do you see the yellow selection rectangle?

This works fine, yes.

[Helixhorned]

Just to reassure you, even with that workaround I still consider it a bug. The SDL2 source distribution contains a test program "checkkeys". If it gives the same results, I'll be considering to file a bug report to the SDL folks. It'll be a bit vague ("some people experience this strange issue"), but if many people run the test, there's a chance that some will see it too.

[neoacix]

The difference with Shift+NumKeys on activated/deactivated Num-Block looks like SDL-2 bug for me too.

Pressing the "8"-key on the Numblock while holding Shift with activated Num-Block looks like this:

SDL2: got key 96, 72, 768 <- "8"
SDL2: got key 96, 72, 769
SDL2: got key 229, 54, 768 <- "RShift"
SDL2: got key 229, 54, 769
SDL2: got key 96, 72, 768
SDL2: got key 96, 72, 769
SDL2: got key 229, 54, 768
SDL2: got key 229, 54, 769
...

While with deactivated Num-Block it only gets the key-pressed and -release event of the "8"-key and not Shift anymore, like this:
SDL2: got key 96, 72, 768
SDL2: got key 96, 72, 769
SDL2: got key 96, 72, 768
SDL2: got key 96, 72, 769
SDL2: got key 96, 72, 768
SDL2: got key 96, 72, 769

It should be the same result, no matter if Num is actived or not, or am I wrong?

But Hendricks, could you work on the Y/Z and Caps-Lock issues?
These are clearly not SDL-2 bugs.

[Hendricks266]

neoacix, on 29 January 2014 - 10:46 AM, said:

But Hendricks, could you work on the Y/Z and Caps-Lock issues?
These are clearly not SDL-2 bugs.

I think I understand the caps lock problem, but I don't understand the "Y/Z" issue. Could you explain that more (or quote yourself if you explained it before)? Also, the one-line quotes of the log printout above for Y/Z are not sufficient...

[neoacix]

Hendricks266, on 29 January 2014 - 11:10 AM, said:

Also, the one-line quotes of the log printout above for Y/Z are not sufficient...

These were just to show that SDL-2 got the keys right, so they are pretty useless. ^^

But try this with a german keyboard (and maybe german layout in your OS too):

Start up mapster.

In 2D-mode press ESC, then q.
Mapster ask you if your realy want to quit.
Here you have to press Y to quit.

Now go into 3D-mode and press ESC again.
Mapster asks again if you want to quit, but...
here you have to press Z to quit.

And I think the same problem goes with other keys like Minus ( - ).
In R4096 (Non-SDL-2 builds), I can edit a sprites and give properties like Extra a negative value with the key right to zero, which is - on US-layout, but ß in german layout.
In newer SDL-2 builds, I can use the key right to . (point) which is / (slash) on US-layout, but - in german layout.
So basicly, SDL-2 builds maps my keyboard correctly in 2D-mode, but in 3D-mode it's like US-layout.
Non-SDL build maps my keyboard allways in US-layout.
This is quite confusing and can be frustrating.
Mapster should map keys in on or the other way, but not in a mixed mode.

Edit: So basicly, all you have to change is, that mapster maps keys in 3D with the correct keyboard layout, like it does now in 2D-mode.
Then everything is fine.

[neoacix]

Just thought about over it again...

I guess it would be better to use a US-layout mapping for german keyboards then native german layout, because some keys like [ ] are single keys in US-layout, but are combinations in german layout.
And especially [ and ] which are AltGr + 8 or 9 are combinations which propably wont work in SDL-2 builds because of the known AltGr bug.

So.... it's better to change back to US-layout in 2D-mode instead of swichting 3D-mode to german layout.

Man... I know this sounds confusing... it confuses me even while I write it... but I hope you understand what I mean Hendricks. ^^

I gues germans just have to open up an image of an US-layout for finding the right keys or just know the differences, but at least, they could use all available functions if mapster is just mapping alle the keys in US-layout, like it was before SDL-2.