Official Game Feedback
-
> Those keys are supposed to do just what you said when num lock is off
Could you please stop treating me like an idiot? I know how NumPad works.
> it's just your keyboard
LOL, I get the same result with screen keyboard. Now what? Conspiracy? :P
-
@arK (View Post)
so is it fixed? I can't really tell from what you said ...
I can fix the '3', '5', and '9' issue if you want, but i'll only do that if you can confirm my commit fixes it (still no numpad, I just guessed the bug from reading what you said). I need to know if it works correctly with both numlock on and off.Edited once by jacob1. Last: 11th Mar 2014 -
> so is it fixed? I can't really tell from what you said ...
"NumPad still doesn't work properly" - I think it's pretty clear.
> I need to know if it works correctly with both numlock on and off.
It doesn't, with both NumLock on and off. When it's on it does Home, End etc. for 1, 2, 4, 6, 7, 8. 5 works fine (cause there is no alternative action for it), 3 and 9 work "fine". When shift is pressed NumPad works the way it should, no numbers, just End, Home etc. When NumLock is off NumPad does nothing.
Edited once by arK. Last: 11th Mar 2014 -
Shift doesn't affect numpad in TPT at the moment, but apart from that numpad seems to work fine for me.
- Which OS are you using?
- Which textbox in TPT are you testing in? (I don't know of any reason why different textboxes might behave differently though...)
- Please could you compile and run example 3-11 from http://www.libsdl.org/release/SDL-1.2.15/docs/html/guideinputkeyboard.html (about halfway down the page), then press all keys on the numpad one by one with numlock off, then repeat with numlock on. Then pastebin the output. (This is to confirm that the key events SDL is producing on your computer are the same as on mine)
Edit: shift now affects numpad.
Edited 3 times by jacksonmj. Last: 12th Mar 2014 -
Interesting, thank you. The num lock state provided by SDL doesn't match the num lock state in the comments. However, the unicode values do match the num lock state in the comments (digit characters when num lock is on, 0 when num lock is off and arrows/home/end should be produced instead).
When cracker64 tested on his Win 7 computer, the num lock state provided by SDL was correct (log), though he did say shift+numpad keys were acting strangely. So I have no idea why it's wrong on your computer, maybe some weirdness in SDL, or in how your keyboard/computer is set up.
I've added a workaround in the latest source, so that it checks the unicode value to determine whether numlock/shift are on, instead of looking at the modifier key states provided by SDL.
Edited once by jacksonmj. Last: 12th Mar 2014 -
This post is hidden because the user is banned
-
@arK (View Post)
The writable tpt.selectedX is in development. Currently it's called sim.state.selectedLeft, but it may change in the future. -
Heyho!
I'd like to point out some issues in the game. Some of these aren't actual bugs but inconsistent behavior. I've created a simulation that makes the problems more descriptive: id:1491458
1) When shooting CRAY through FILT the resulting particles' color ignores the FILTs tmp. Most modes, such as "AND" and "OR" wouldn't make much sense, but "No Effect" should definitely be considered.
2) When photons pass by DTEC surrounding FILT is colored with the PHOTs color. Bray, although behaving similar to photons when used with FILT, is ignored though.
3) Whenever a photon's ctype (color) turns "black" it is discarded. BRAY instead changes to its default greyish color.
4) When FILT is placed too close to powered clone the spawned photons don't change their color as they should.
5) Lastly it seems that TPT uses a lua variable/definition that is no longer available. When building TPT on fedora with recent lua libraries I get the following error:
In file included from src/lua/LuaButton.h:9:0,
from src/lua/LuaButton.cpp:10:
src/lua/LuaLuna.h: In static member function ‘static void Luna<T>::Register(lua_State*)’:
src/lua/LuaLuna.h:28:19: error: ‘LUA_GLOBALSINDEX’ was not declared in this scope
lua_settable(L, LUA_GLOBALSINDEX);
^
scons: *** [build/src/lua/LuaButton.o] Error 1
A user on stackoverflow claims thatIn Lua 5.2 the LUA_GLOBALSINDEX value is no longer defined so this line of code no longer compiles.
I have no knowledge about lua but this appears to be TPT's fault.
I know that most of these issues seem immaterial. That's wrong. Issues (2) and (3) are currently hindering development of an ultra-fast superscalar 28-bit computer (2 frames per clock are probably possible). Some of you may have seen my HD Screen(id:1488087). If (3) was fixed the friggin' photons inside the screen could be replaced with invisible BRAY.Edited 3 times by drakide. Last: 22nd Mar 2014
