input thread, compass direction, URL catcher, new widgets, ~ on WinNT, cleanup of patches on berlios, reduce defines

[ttlanhil]

this thread is aimed more at other developers, though anyone with coherent and helpful input can post.

"sounds cool" is reserved for the devs-on-high, however...

 

this is to get input from people, see what yawl think. some of it will be a bigger job, but it's mostly stuff I can do in a short time, it need not put more load on anyone else (this is mostly stuff I'd do anyway, but it's a good chance to get input. stuff like defines and berlios need someone on high, though)

 

input thread

currently, keyboard and mouse handling is done in the main thread, I'm suggesting moving it to a seperate thread.

for people with a low FPS this is a big win (if you type faster than it renders, you can lose keystrokes), and it's also a benefit when loading the next map (even if the text isn't shown, it's still queued while map is loading)

another possibility is loading the map in a different thread, and having that draw to a buffer to be shown when veiwing main. if you're looking at console, CPU goes up but it's still working. that means you can chat while loading the next map, etc. looking at main will show the loading screen we currently have, but not including HUD (probably). so you can still open buddy win, etc

 

compass direction

this makes the compass needle turn in the opposite direction (when it's turned on it seems correct, anyone prefer it off?). is that really worth taking up code and elconfig window space?

 

URL catcher

I made one of these a long time back, but was going to make changes that didn't happen. basically, instead of F2 only memorising the last URL, you have a window showing all previously seen ones (F2 can still load the last one, of course)

 

new widgets

one of the things the url catcher was waiting on, was the list widget. instead of drawing a list of lines yourself, you put them into the list widget (however it only takes other widgets, so you use labels). this handles adjustment of scrollbars for you

also: link widget. similar to label, but set up to be used as a clickable link (either that, or a way to tell labels to be underlined). onclick functionality we already have should be sufficient

also: tree widget. has a name, boolean expanded, and a list of pointers to either other tree widgets, or other widgets (it doesn't actually care what they are, just calls their display). only shows children if expanded

also: drop-down multis. I've made a working drop-down before (see the channels list in windowed_mode=1), this allows us to save space in elconfig and similar

 

click handling, highlighting, and copy

I have a working copy (on windows) from ELC, but it needs selection ability before it's much use (unless it's only available for the total input area, which is something). to do this right, it'll need mouse-down checks, ad mouse-up checks

I'll need someone else to do the text-copy for X, but otherwise it's half done and the rest shouldn't be too hard

 

~ on WinNT

on WinNT, users have a home dir; we could use `%APPDATA%\elc` as our config dir (that's WinXP home, at least, I expect others to be similar if not the same. for Win9x, it can stay in data_dir)

 

cleanup of patches on berlios

there are a lot of these that are probably worth cleaning, some are over a year old (so it's highly unlikely they'd apply, but the idea in them may still be wanted...)

oh, and I'd suggest another patch category, "bug fixes" or similar

 

cmds.ini

just as we have key.ini, how about one for commands? this could let people set up `;;`->`#gm`, use a different character instead of @ and #, etc... which could be a big win for people with non-US keyboard layouts

 

reduce defines

there are a lot of these... some which seem to be wrong (for example, CUSTOM_LOOK CUSTOM_LOOKS and CUSTOM_UPDATE ?)

 

AFK_FIX

a yay/nay on merging this into standard would be good

ANTI_ALIAS

there's a elconfig option for this, so do we need a define as well?

ATI_9200_FIX

this is only one small change in the code, and the card will probably be around a while, is it simpler to just merge it in (since those compiling for an unknown audience probably need it)

AUTO_UPDATE

there's a elconfig option for this, so do we need a define as well?

CUSTOM_LOOK

CUSTOM_LOOKS

as above

EL_BIG_ENDIAN

LITTLE_ENDIAN

why both?

MINIMAP

will this be used in the main client? it drops the FPS a bit when open, but works (how well, I don't know, but it compiles and works as expected)

NOTEPAD

it's in ent's build, so should it be merged?

PNG_SCREENSHOT

the libpng13.dll that I have is 199KB, so it's not much extra download to require it... can this be made standard? (a lot of people want it)

USE_FRAMEBUFFER

there's a elconfig option for this, so do we need a define as well?

 

questions, comments, answers?

[Roja]

All sound good to me.

(excluding the defines, get some other programmer to comment on it)

 

Thanks for taking the job of working on these things!

[Drakos7]

I think the HUD options"Stats In HUD" and "StatBars In HUD" could be merged together also. I am pretty sure that most people who use one, use both.

[ttlanhil]

I think the HUD options"Stats In HUD" and "StatBars In HUD" could be merged together also. I am pretty sure that most people who use one, use both.

actually, I've had someone say they'd like only the bars and not the numbers (since the numbers get in the way)

but otherwise, yes, saving elconfig space is a good thing, and I don't see much need to seperate them

[Aislinn]

I think the HUD options"Stats In HUD" and "StatBars In HUD" could be merged together also. I am pretty sure that most people who use one, use both.

I love the stats in the HUD but really dislike the bars. Makes it way too busy over there. I'd like to keep them separate.

 

Question on the url catcher: would we be able to copy/paste from it? It would be hugely handy if that were the case.

 

I also especially like the input thread ideas, i currently have lots of troubles with those issues, and the cmds.ini as well.

[0ctane]

I really like the commands.ini idea. There are a lot of international Mac users who have problems with specific keys (# comes to mind).

 

click handling, highlighting, and copy: Well, I do not have copy/paste working for OS X. This is a little beyond my scope of Mac programming knowledge, and I do not have the time to look into it. Some people will have to live with disappointment for a while.

 

I think I am one of the few people that have to seriously worry about endian issues. I did not even know there was a LITTLE_ENDIAN define. Seems pretty silly to me.

 

PNG_SCREENSHOT.... Honestly, I have not played around with this in OS X yet. OS X has its own screenshot key combo. Might want to #ifndef OSX those areas as there is no need to bloat the OS X client (and I am not going to port a png.framework).

 

Overall, good suggestions.

[ttlanhil]

Question on the url catcher: would we be able to copy/paste from it? It would be hugely handy if that were the case.

copy from it... probably. once the ability to copy to clipboard is available (I already have it for windows), copying stuff into it is simple enough

PNG_SCREENSHOT.... Honestly, I have not played around with this in OS X yet. OS X has its own screenshot key combo. Might want to #ifndef OSX those areas as there is no need to bloat the OS X client (and I am not going to port a png.framework).

there's stuff in windows too, but that saves a screenie to the clipboard. which means you then then to paste into paint or whatever. with PNG_SCREENSHOT, it's ctrl+p and it's saved for you, so you can take a lot quickly, which is the main point. if it goes in, #ifndef OSX is easy enough to add

[Roja]

i'd like for the png support to be there.

[Learner]

After the current update gets released

 

I see no problems with removing need to have:

AFK_FIX

ATI_9200_FIX

 

To be decided on:

AUTO_UPDATE

 

Concerns with:

PNG_SCREENSHOT - Entropy has been wanting to avoid adding more libraries, not in the official client, and would need his blessing

 

I don't know if these have problems compiling on any platforms (has BSD been compiling with them for example?):

ANTI_ALIAS, the official client has never used this

USE_FRAMEBUFFER

 

I corrected:

CUSTOM_LOOKS

 

Can NOT be removed/forced yet:

CUSTOM_LOOK, not stablized

CUSTOM_UPDATE, not functional

MINI_MAP, not supported and known bugs (developer left)

NOTEPAD, too many bugs still

 

Thats my two cents on the compile options, then ENDIAN issues really should be addressed by the OSX group.

[crusadingknight]

NOTEPAD, too many bugs still

As the author: It's not even finished (scolling has to be integrated... AFAIK I have a patch from over a year ago on berlios, which I can fix and clean up after my vacation), and the buttons aren't even using the correct types. Plus, it need beautification, probably replacing the main tab's hackish list with a list widget, and a tab pool, to keep opening/closing of notes from (very eventually) overflowing the widget id and causing a crash.

 

cmds.ini

just as we have key.ini, how about one for commands? this could let people set up `;;`->`#gm`, use a different character instead of @ and #, etc... which could be a big win for people with non-US keyboard layouts

Call it aliases.ini - alias is a more familiar term to *nix shell/gaim/vim/etc. users. (You can use ie. #alias [from] [to] to add while the client is running.) From experience, I would say the best way to do this is to try to parse after Enter is pressed, and then run a sanity check on the buffer length - it makes it easier to parse once. Also, for extensibility, given the number of aliases a user could have, a burst trie will likely be the most effective data structure, though one could possibly get away with a BST using hashes as keys and chaining duplicates. I certainly doubt anyone will have enough to warrant a fab-tree or a hash table though. That's a project I'd really like to have a go at tomorrow, if nobody else minds?

(Already have my notes on it too - it'd need to import from UTF-8, and export to UTF-8, and parse a strndup'd buffer in place. I suspect a burst trie would have a great performance boost, with a slight memory cost over the standard array/linked list implementation, which could likely be extended to the names list - currently, autocompletion costs me about ~2 FPS, or 10%.)

Edited July 27, 2006 by crusadingknight

[ttlanhil]

As the author: It's not even finished (scolling has to be integrated... AFAIK I have a patch from over a year ago on berlios, which I can fix and clean up after my vacation), and the buttons aren't even using the correct types. Plus, it need beautification, probably replacing the main tab's hackish list with a list widget, and a tab pool, to keep opening/closing of notes from (very eventually) overflowing the widget id and causing a crash.

<snip>

Call it aliases.ini - alias is a more familiar term to *nix shell/gaim/vim/etc. users. (You can use ie. #alias [from] [to] to add while the client is running.)

<snip>

That's a project I'd really like to have a go at tomorrow, if nobody else minds?

all sounds good to me. one of the important parts of that, IMO, is being able to change @ and # to different characters, so it's not just command name aliases... plus I suppose you have to worry about people aliasing something short to something long and spammy (then again, people seem to have behaved reasonably well about ctrl+up and paste)

my interest/progress:

input thread I've had a bit of a play with this, the mouse handling is a bit more convoluted than I thought before I started, but it shouldn't be too much work.

the other option is to have the thread only handle the keyboard. the mouse stuff is about changing cursor based on what's under it, which is render-related... but a thread just for keyboard may be wasteful.

background loading (I mentioned map-change before, but it may also work for loading other stuff on demand, such as the delay when you start to get close to a crowded storage, and it has to load stuff from disk), on the other hand, may be useful enough that it's worth its own thread

URL catcher I'd like to be able to have this in the client. the patch I made way-back worked, but I'd want to polish it a bit

new widgets I think it'd be handy to have them, and I want a list-type for the URL window (it'd also be handy for buddy list and possibly others)... I had a pane widget patch made, but I'm not really into the widget stuff

cmds.ini if I were doing this, it'd probably just be clone and modify the key.ini stuff. you're welcome to do both of the above

click handling, highlighting, and copy I have windows copy already, text highlighting sorta works (there's a bug if it's selected to end of the line, and the way isn't done isn't really pretty, but it does work), just needs the mouse drag-select and changes to the input area key handling (shift+arrow = selection, etc)

~ on WinNT I think it'd be nice for computers that have more than one EL player, but that's not mine... if/when Win9x is old enough not to need support, then everything working out of users' home dir may make the client a bit simpler... it's hardly a big thing though

[crusadingknight]

all sounds good to me. one of the important parts of that, IMO, is being able to change @ and # to different characters, so it's not just command name aliases... plus I suppose you have to worry about people aliasing something short to something long and spammy (then again, people seem to have behaved reasonably well about ctrl+up and paste)

Hrm, that's true, but I suppose we could just have a keymap.ini to cover that - unfortunately, judging from keys.c, there really isn't any code to share. Given the fact that they have to have unique values, you'd also have to check for (and maybe resolve?) keymapping conflicts. Hrm, I'll check said requirements in the morning.

Edited July 27, 2006 by crusadingknight

[UberLord]

AUTO_UPDATE

there's a elconfig option for this, so do we need a define as well?

 

Please don't remove this unless my patch to create required directories is merged as it will bork Gentoo users a little if an update requires to be placed in a non-existant directory.

 

http://developer.berlios.de/patch/?func=de...p;group_id=1256

[0ctane]

I think it'd be nice for computers that have more than one EL player, but that's not mine...

On this note, I think that the chat_log file should be named based on the current player just like spell lists. That way, if two people use the same computer (or if an alt is concurrently used) the chat logs would be separate. If there are no objections, I can do this modification.

[Roja]

 

cmds.ini

just as we have key.ini, how about one for commands? this could let people set up `;;`->`#gm`, use a different character instead of @ and #, etc... which could be a big win for people with non-US keyboard layouts

Call it aliases.ini - alias is a more familiar term to *nix shell/gaim/vim/etc. users.

 

eek..can we please name it commands.ini(or cmd.ini)? That way it's clear to all....aliases.ini, i'd have no idea. cmd/commands is self explainatory.

[bkc56]

On this note, I think that the chat_log file should be named based on the current player just like spell lists. That way, if two people use the same computer (or if an alt is concurrently used) the chat logs would be separate. If there are no objections, I can do this modification.

 

I think this a very good idea.

 

I also think that when the chat file gets larger than some threshold it should be renamed (chat_log-x.txt or something like that) so it doesn't get SO large. If people want to keep all the history, fine. But if they want to prune the older stuff they could delete some of the older *-x versions.

[Drakos7]

Bkc56: I just submitted a patch to rotate log files based on month (as opposed to size). http://developer.berlios.de/patch/?func=de...p;group_id=1256

[ttlanhil]

been done

http://developer.berlios.de/patch/index.ph...p;group_id=1256

split by channel, user name, and size. and rotated out to /logs/ by size

it needs to be cleaned up, because it's quite old, but it had the functionality

[0ctane]

been done

http://developer.berlios.de/patch/index.ph...p;group_id=1256

split by channel, user name, and size. and rotated out to /logs/ by size

it needs to be cleaned up, because it's quite old, but it had the functionality

Have you checked this with the current CVS? It sounds perfect for the logging tasks suggested above.

[ttlanhil]

Have you checked this with the current CVS? It sounds perfect for the logging tasks suggested above.

no, that patch is ancient. there's probably a lot of old patches on berlios that are worth reviewing though, which is why going through the list is on the todo list above

[Vegar]

cmds.ini

just as we have key.ini, how about one for commands? this could let people set up `;;`->`#gm`, use a different character instead of @ and #, etc... which could be a big win for people with non-US keyboard layouts

# and @ is already configureable (actually it's translateable, but it works the same way)

as for the ;;->#gm part, it could easily be done with the new command system

 

I see no problems with removing need to have:

AFK_FIX

ATI_9200_FIX

ATI_9200_FIX should be made a runtime option, it's a slowdown for people who don't need it. Edited July 28, 2006 by Vegar

[ttlanhil]

# and @ is already configureable (actually it's translateable, but it works the same way)

I've seen that in code, but can't find it in /languages/, where can it be adjusted?

ATI_9200_FIX should be made a runtime option, it's a slowdown for people who don't need it.

in order to avoid having too much in the config window, should there be a multi-select for video cards? there's also the workaround for S3 that I had to make (a simple fix, but I'm leery of adding too many config options)... alternatively, is it worth doing it without a config option, since we can check the card name anyway? (or with a config option so more people can use it if need be, but automatically enabled for people with those cards)

[emajekral]

Please keep the -DUSE_FRAMEBUFFER define for now. The framebuffer code does things that interact with my camera code badly, even when the elconfig option is turned off. For one, it seems to change the far clip plane.

 

It is also buggy.

 

In a clean install (compiled from unmodified source in linux, and the official installer in windows) the elconfig option claims it is currently only used for Reflections and on my system (gForce 6800, new drivers) enabling framebuffer causes reflections to flicker in Linux, and disables them completely in Windows... The only noticeable effect on reflections is that the fake sky color no longer appears when reflections are on, just the clear color with a little alpha texture. Also framebuffer allows me to use higher resolution shadow maps, despite what the option claims.

 

Are these things only a problem for me or have others had them as well?

Edited July 30, 2006 by emajekral

[JoshuaMckee]

has all the stuff at the beginning of this thread been done already, or is there something that I can do?

 

Josh

Edited July 30, 2006 by Josh

[ttlanhil]

has all the stuff at the beginning of this thread been done already, or is there something that I can do?

most of it has, has been spoken for, or is up to the higher-ups. if you have WinNT/XP, then using %APPDATA%\elc for EL data like is used on *nix is something that you could do. shouldn't be too difficult, though it will take a bit of work