- User Since
- Feb 3 2017, 10:51 PM (96 w, 3 d)
Fri, Dec 7
The commit contains only few style mistakes. So the accept isn't required. My point that the commit doesn't have any linked diff/ticket or link to its conversation. My first thought was are these bots and rooms already exist.
Thu, Dec 6
Only if needed.
Do really need it? I thought we have pretty compatible versions. Also these *b versions aren't running on serverside, no?
Thu, Nov 29
I think you didn't read my comment right :)
The patch now forbid to use different values passed to the GUI stack, only functions. Before the patch someone could easily add another param (with C++/JS modifications).
Yep, clouds in the sky texture. Separate "clouds" we have only as particles. Anyway close clouds should be separate, yes.
Wed, Nov 28
Sun, Nov 25
Did you test it on really wide monitors/windows?
Sat, Nov 24
Why separate header? I don't think it helps much. All other components don't have headers.
Fri, Nov 23
The problem isn't in macros, because we use scoped block to solve the redeclaration. Probably it was missed somewhere. If you still remove macros, you need to remove scoped blocks too.
Thu, Nov 22
so that the slider position wills be 0, 4.99999.., 9.9999...
No, the slider position will be correct in C++ (with an epsilon correction), but the double > JS::Number conversion loses precision.
Then min and max can also be 4.9999 and the current patch is as affected by epsilon as the change that I request, where is the issue?
Min, max can't be 4.999, the problem is only for the return to JS value.
Wed, Nov 21
You can check it by returning a fixed number, like 4.5. JS may get from C++ the 4.499999 value. And for JS these values are different.
Yeah, compilers started optimize these cases a long time ago. But there're many nuances.
Not a workaround solution requires improvements in the our option page logic. Because we shouldn't change visible scale while a user is dragging the slider.
Do I understand it correctly, that IPv4 won't work when IPv6 is enabled?
I can close this ticket, if you'll solve the problem in your diff.
Mon, Nov 19
Isn't the flag needed in the premake4.lua too?
Isn't the flag needed in the premake4.lua too?
Sun, Nov 18
Wed, Nov 14
Mon, Nov 12
Nov 10 2018
Nov 9 2018
Function were declarated by CC, but used with a wrong first letter.
Can the -mmacosx-version-min=10.9 flag be replaced by a constant? To prevent those big changes to change a version.
Nov 1 2018
That'd be awesome, because we need to avoid a code duplication.
Why 32 in C++ and 24 in JS?
Oct 30 2018
Oct 29 2018
Oct 28 2018
I'd say that this part can be better in the C++ part. Because it may be faster and has much more information about elements.
Does our spidermonkey support Uint8Array/Uint32Array? It'd be good to compare them by performance/memory usage.
I have to say the current way (1 vertex per call) to modify the terrain is pretty slow, especially if it's called from JS. So I suggest to use a range modifier, or even better - brushes. With brushes you only need to pass brush params and C++ part will complete a request as fast as possible. With brushes you're still able to edit terrain by 1 vertex: just pick the brush radius as 1.
Aug 27 2018
Aug 26 2018
Aug 25 2018
Aug 17 2018
Aug 15 2018
Aug 10 2018
Aug 8 2018
Aug 7 2018
Nope, do we escape strings, not characters? I mean to prevent things like "\ ", when the escaped character does nothing.
Probably we need to report about unsupported escaped symbols.
Aug 6 2018
Aug 5 2018
Yes, I mentioned this some time ago.
Jul 29 2018
Updates the year.
Adds the Mod.IO support.
Jul 7 2018
Jul 6 2018
Jul 5 2018
Could you attach your errors?
Jun 29 2018
It'd be good to get first item from the list.
There is many duplication of std::string(reinterpret_cast<...>...), especially for reinterpret_cast it's not very good. I suggest to add a function Hexify(const u8* data, size_t size) to fix the number of reinterpret_cast.
Jun 28 2018
Jun 26 2018
I think default is good, because as I mentioned above, we have the default logic for the Paint Terrain tool.
Nope, there are at least 2 other similar problems:
It can be the same as the the paint tool for terrain (to be consistent). If a texture isn't selected, then a terrain would be painted with a default selected texture.
Jun 25 2018
It's not good. It's a workaround.
Jun 24 2018
I'd only prefer for a better name, but we didn't decide it. And I don't see problems in the code. So the patch is ok for me.
I edited the comment few minits later (UPD = Update).
Jun 23 2018
I didn't tell about sprintf_s at all in the last sentence, but about modifying the same buffer with hardcoded offsets.
If it works now it's not the reason to add a non-standard workaround. But do you agree that it was wrong to commit it without this discussion in the diff (especially without reviews)?
The problem is that you used the code from tests. The problem is that you didn't see difference between single write in a buffer and multiple and have insecure construction of std::string. The problem is that you didn't wait my approve or full review.
I don't set myself as a reviewer, it happens automatically, because I mark it as Needs Changes. I agree with your point, I will removing myself from reviewers manually in similar cases after my objections will be completed.
Jun 22 2018
Thanks, I'll fix it after the FF.
It's not different 16 pieces, it's logically related pieces. You said you don't want to add hardcoded things, but you did add it. Without review. With my Needs changes. You have std::stringstream without so hardcoded numbers, but you didn't use it.
I agree with @elexis, we don't need to prefer the one type of files. The compressed version of a mod is less portable. The security reason is nothing for the open-source project, because you can just modify the code a little bit to easily extract things.
You have 2 implementation depended hardcoded numbers, it's more than 1. Also you get it from the test code, instead of the production code. It's not good.