LabRat Report post Posted March 30, 2008 Hiya I found and fixed the root cause of the 5000 line wrap bug in the console window (where you see the beginning of your chatlog at the bottom of the console window if you run the game for any length of time). After many hours of changing lines one at a time to trace through which line did what I discovered that the culprit was as simple as a missing '-1' in consolewin.c. Committed the fix to CVS. Share this post Link to post Share on other sites
Alberich Report post Posted March 31, 2008 now I can't see the last line on the console Share this post Link to post Share on other sites
LabRat Report post Posted March 31, 2008 Strange - do you mean all the time or when it hits the 5000 line point? I tested the bug worked by lowering #define DISPLAY_TEXT_BUFFER_SIZE 100 /*!< maximum number of lines in the text buffer */ so I could see the effect more quickly than normal, it works perfectly for me :/ and Share this post Link to post Share on other sites
kwas Report post Posted March 31, 2008 now I can't see the last line on the console I think it's a different bug - it sometimes happens to me also with or without the patch. Share this post Link to post Share on other sites
LabRat Report post Posted March 31, 2008 In which case I will have to hunt round and see whether I can't nail that one too \o/ Share this post Link to post Share on other sites
majestyk Report post Posted March 31, 2008 We had that a while ago (a different bug while someone worked on other console changes), but then it was fixed and I never saw it again.. until now: the last line of chat is missing in the console. You can reproduce it easily: just start to harvest something, switch to console, and you will not see the "started to harvest" line until there is a new chat line in any of your channels or local. This happens all the time, not only when reaching a certain amount of chat lines. Share this post Link to post Share on other sites
Alberich Report post Posted March 31, 2008 I tried with and without your patch and I only get this WITH the patch: (sorry for the weird colors - used the wrong option in GIMP and didn't notice) Share this post Link to post Share on other sites
PhilDaBurn Report post Posted March 31, 2008 now I can't see the last line on the console I had the same problem until I made the console text smaller. Share this post Link to post Share on other sites
majestyk Report post Posted March 31, 2008 Thanks Phil, reducing or increasing the chat text size by only 0.01 already "works around" this bug. Share this post Link to post Share on other sites
LabRat Report post Posted March 31, 2008 Ok, my bugfix works for "Old Behaviour" and "Tabbed Chat" from what I can tell, I will look into "Chat Window" text handling now. From PhilDaBurn and Majestyk's posts I am wondering whether clipping is occurring when it comes to drawing the actual last line of text - maybe a < or > that should be <= or >= ? Share this post Link to post Share on other sites
LabRat Report post Posted March 31, 2008 I think I found the bug in the windowed chat: chat.c:749 nr_displayed_lines = (int) (chat_out_text_height / (18.0f * chat_zoom)) + 1; I added the + 1 at the end of the line. I will do more testing before I commit that though. Share this post Link to post Share on other sites
LabRat Report post Posted March 31, 2008 ok, I found that for some reason the size of the chat window has a direct relationship with whether the bug happens even with my amendment. Guess I have to keep digging, but we're close Share this post Link to post Share on other sites
Learner Report post Posted March 31, 2008 ok, I found that for some reason the size of the chat window has a direct relationship with whether the bug happens even with my amendment. Guess I have to keep digging, but we're close Sounds like you need to improve the rounding logic, not add +1. Share this post Link to post Share on other sites
LabRat Report post Posted March 31, 2008 To be honest I want to scrap the entire round robin thing entirely and memset/memcpy/free as is needed, a 5000 line memcpy whenever a new line comes in will not exactly take long and will make things a lot easier to handle :/ Share this post Link to post Share on other sites
Learner Report post Posted March 31, 2008 To be honest I want to scrap the entire round robin thing entirely and memset/memcpy/free as is needed, a 5000 line memcpy whenever a new line comes in will not exactly take long and will make things a lot easier to handle :/ Please, not memcpy()! At least use memmove() so if someone breaks it memory won't get horribly mangled! It's better behaved when the blocks overlap. Share this post Link to post Share on other sites
Florian Report post Posted March 31, 2008 Maybe this sounds a bit stupid, but why not use a C++ std::vector to store the lines and build a c-wrapper to add/remove/etc the lines? Share this post Link to post Share on other sites
Learner Report post Posted March 31, 2008 Maybe this sounds a bit stupid, but why not use a C++ std::vector to store the lines and build a c-wrapper to add/remove/etc the lines? Because all of that code is from before Entropy allowed C++ to be used anywhere in the client, and I don't think Entropy want the client converted to all C++ either. The last general rul I heard was use C where ever possible, C++ should be in isolated areas and you might need to ask Entropy before using it there. Share this post Link to post Share on other sites
Entropy Report post Posted March 31, 2008 Well, the new engine Daniel is rewritting will be pretty much all C++, so I guess it's ok, if it works and doesn't break stuff. Share this post Link to post Share on other sites
Florian Report post Posted March 31, 2008 The last general rul I heard was use C where ever possible, C++ should be in isolated areas and you might need to ask Entropy before using it there. OK. That thought came to me because all the new stuff is pure C++. Share this post Link to post Share on other sites
Learner Report post Posted March 31, 2008 The last general rul I heard was use C where ever possible, C++ should be in isolated areas and you might need to ask Entropy before using it there. OK. That thought came to me because all the new stuff is pure C++. Those are also seperate subsystems that require more specialized skills and Entropy won't go near them at all because of how he hates C++ Share this post Link to post Share on other sites
alvieboy Report post Posted April 2, 2008 Maybe this sounds a bit stupid, but why not use a C++ std::vector to store the lines and build a c-wrapper to add/remove/etc the lines? A std::vector<std::string> or std::vector<const char *> ? The first one has some more overhead, but it's safer. I can build the wrapper for you, if you want. Share this post Link to post Share on other sites
LabRat Report post Posted April 2, 2008 C I understand. C# I understand. C++ I have never used. If you want to go and change the source this drastically hadn't someone better check if C++ is something all the other devs can program in? Share this post Link to post Share on other sites
alvieboy Report post Posted April 2, 2008 C I understand. C# I understand. C++ I have never used. If you want to go and change the source this drastically hadn't someone better check if C++ is something all the other devs can program in? Read carefully what we were discussing in the first place. A "C" wrapper to a "C++" STL implementation. That would look like this: int vector_string_clear( vector_string * ); int vector_string_add(vector_string *, const char *); int vector_string_iterate(vector_string *, int (*function)(const char *, void *userdata), void *userdata); And so on. We just can't change code to C++ in one day. That would be disastrous, and no one is thinking about that seriously (I think). Álvaro Share this post Link to post Share on other sites
Florian Report post Posted April 2, 2008 I had something in mind like - add (char *) - clear() - delete(int) - as_array() etc. Not replace the whole thing in C++, only the storage part where the chat lines are stored. Share this post Link to post Share on other sites
alvieboy Report post Posted April 2, 2008 - as_array() Hmm, as char ** ? Don't you prefer to use iterators (in C) for that ? Álvaro Share this post Link to post Share on other sites