Forum
CS2D General CS2D Bug ReportsCould you also check serverinfo.txt? For some reason it is being used by 2D all the time, as if it's not closed by the game after reading it. I am on new server so I don't know if it's permissions issue or the game
Also there is a bug with the Laser Mines.
I had 4 laser mines, and there was a laser mine on the floor, so when i got it, I lost my laser mines, I have just got one.
Lasermine thing doesn't sound good. Will check.
Well, i forgot something to ask.
Why the fps limit is 63, It isn't 60. Some pepole have 63 fps, but others have lower fps. That's stupid. I think you have to change it or i will not save the world .
DC has written
It's due to internal calculation stuff. It can be entirely ignored. It's not a problem whatsoever. Enable vsync and set your monitor refresh rate to 60 if it's super important to you that this little number says 60.
If I change it to 60 fps, yet other players will still have 62-63 fps, everyone should get the same fps limit. You might broken it. When it was 50 fps, there wasn't any issue with it. But since you changed it to 60, it's broken.
Must be fixed ASAP.
Jokes aside, this means literally nothing.
Pretty sure I had 51 FPS once in the older versions.
The cap is per frame. So for each frame CS2D checks IN THEORY if it took ~1000 / 60 ms CPU + GPU time. If it was less the game waits 1 ms until that time is reached.
If you do the math however you will notice that 1000 / 60 is ~16.666 so it's not exactly 16 or 17 ms. We can only work with ms precision though. BlitzMax doesn't allow more precise measuring or more precise delays out of the box.
This is bad because it would mean (under perfect conditions) that we always go up to 17 ms per frame.
1000 / 17 = 58.823 FPS which would be displayed (depending on rounding) as 58 or 59 FPS.
People would complain that the game doesn't reach 60 FPS. Also with VSync ON this would be really bad because we might miss some VSync cycles because we artificially delay execution for too long. This would lead to even lower FPS with VSync on. (really bad = probably nobody would notice but it would be stupid)
IN PRACTICE we take 1000 / 65 instead of 1000 / 60 as target FPS. Together with all overhead and imprecision this leads to ~60 FPS IN MOST CASES and it ensures that - if VSync is on - no VSync cycle is missed because of too high artificial delays.
The logic is the same for everyone. We are talking about sub-ms precision. Human reaction times are much higher. It doesn't give anyone a noticeable/measurable advantage or disadvantage. I'm very sure that no human being could ever tell the difference between 60 and 63 FPS without seeing the frame counter (maybe you can because you're super man but that's an edge case, sorry).
So as you see there's a good reason that the FPS sometimes go very slightly beyond 60. This is by design, intended and not a real problem at all. Nothing is broken there and it won't be changed.
edited 1×, last 10.11.19 01:37:31 pm
If you have 1 flash in your inventory and move over a tile where there's 2 flashes, you pick both of them instead of just one, so out of the 3 flashbangs, one of them magically disappears.
The point with this one is that it's not a bug. It's how the game works. If you collect something you always collect it completely. If you hit a carry limit it doesn't matter. Everything you can't carry is just ignored and the item on the map is removed.
To me this is not a crucial problem. Of course it makes a big difference in gameplay but if the behavior is consistent it's fair and not a bug.
Therefore changing this never had a high priority for me.
https://streamable.com/qkec2
For example if a player is stuck in between an L shaped wall, it will report that he can walk, even though he cannot.
This causes for taking unnecessary measurements around the player since this doesn't seem to check if the player core (12x12) is walkable, but rather if the core's core (1x1?) is walkable.
Is this the only solution?:
1
2
3
4
5
2
3
4
5
if (flr(math_floor((newX - pl_collision) / 32), math_floor((newY - pl_collision) / 32), 'walkable') and flr(math_floor((newX + pl_collision) / 32), math_floor((newY + pl_collision) / 32), 'walkable') and flr(math_floor(newX / 32), math_floor(newY / 32), 'walkable')) then 	-- Walkable else 	-- Not walkable end
flr = tile
math_floor = math.floor
pl_collision = 14
EDIT:
The shieldhit hook doesn't seem to trigger when the shield is hit by a gut bomb...?
edited 1×, last 11.11.19 08:07:27 pm
tile works as explained in the documentation. It simply gives you information about a specific tile. Nothing more and nothing less.
If you want to check if a player can walk a certain space you have to write your own logic. Like you did. Basically checking the 4 edge points is the solution.
Just put it in a nice function and you can use it everywhere.
Edit: Regarding shield: I don't think the shield registers any projectiles except for regular bullets / laser. It also doesn't block those I think.
edited 1×, last 11.11.19 08:13:50 pm
How am I supposed to prevent the shield from blocking shots or modifying the damage?
And it doesn't get triggered by gut bomb, sadly.
Scripting tasks (or feature requests) shouldn't be discussed in the bug report thread.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[21:37:57] Leaderboard Access [21:37:57] Leaderboard User Request 1 [21:37:57] Leaderboard User Request 2 [21:37:57] Leaderboard User Request 3 [21:37:57] Leaderboard User Request 4 [21:37:58] Leaderboard User Request 5 [21:37:58] Leaderboard User Request 6 [21:37:58] Leaderboard User Request 7 [21:37:58] Leaderboard User Request 8 [21:37:58] Leaderboard User Request 9 [21:37:59] Leaderboard User Request 10 [21:37:59] Leaderboard User Request 11 [21:37:59] Leaderboard User Request 12 [21:37:59] Leaderboard User Request 13 [21:37:59] Leaderboard User Request 14 [21:38:00] Leaderboard User Request 15