ttlanhil's Patches

[ttlanhil]

since several of my patches are in this thread anyway, I may as well do this here.

 

status of my patches on berlios (people with CVS commit, please look ^_^ )

 

ones I want committed

 

000484 change healthbar colour scale up to aqua over full health

If someone has more than max HP (from potion, reset, whatever) then scale into aqua (and up into white)

this should either be accepted or rejected(as in people are allowed to use it, but it won't go into CVS) or whatever, because it's a minor patch, has been there a while, and is purely cosmetic. and possibly needs to be updated to latest CVS

 

000550 add timestamps to all logs

it also remembers what the last error message was, and if it's the same, counts them instead of filling up the log. this is particularly handy with the recent `No Anim: ./animations/player_slash1.caf` error.

using this patch, here's an error_log where the client is loaded, but not logged in. y'know how long it'd be with those repeated messages? :glare:

note that it also logs the time zone(which might matter), and when the client was closed(also could be useful)

Log started at 2005-10-21 20:18:16

 

(Cen. Australia Standard Time)

 

[20:18:16] Error: Can't open file "./textures/fontv.bmp"

[20:18:16] No Anim: ./animations/player_slash1.caf

Last message repeated 527 times

[20:18:17] No Anim: ./animations/canine_pain.caf

Last message repeated 2 times

[20:18:17] No Anim: ./animations/player_slash1.caf

Last message repeated 527 times

[20:18:19] No Anim: ./animations/canine_pain.caf

Last message repeated 2 times

[20:18:19] Error: Can't open file "./textures/particle5.bmp"

[20:18:19] Error: Can't open file "./textures/particle6.bmp"

[20:18:19] Error: Can't open file "./textures/particle7.bmp"

[20:18:22] Client closed

this patch won't give any in-game advantages at all, but will make the error_log a fair bit neater (next problem: all those "cannot add command" messages, which aren't the same)

I hope this can go in soon

 

000626 #config_save & fix to save config past the *nix exit hang

be able to save your el.ini and el.cfg anytime, and do it before the point where we had the music hangs during shutdown, instead of after. I beleive that problem has since been fixed, but being able to save config without closing client could still be useful

 

000628 save positions of buddy, stats & help win to el.cfg

from when 1.1.0 came out, these windows' locations weren't being saved to el.cfg with the rest

 

000624 expert config, config cleanup, & windows use global colours

there are a lot of options in config window that people shouldn't be messing with, since they don't know what they do. so why not simplify it, and hide the more advanced options? (and allow people to show the extra config if they so chose)

the order of all the options added to the list in current CVS is a mess, this patch orders & groups them (which makes it a pain to keep up-to-date. if/when someone wants to commit this, I can do a final cvs-up on the patch. not worth doing regularly otherwise)

with this, you can also explicitly hide options like password, instead of using special-case programming to check for stuff like that

 

000604 make quickbar use lower items from inv if top empty

Wytter asked me to do this back when I was starting to learn C. it was a while later before I was able to actually do it ^_^

alt+<num> works, the picture is right, and click does the right thing (the three parts, which are handled differently, that have given me a few issues )

(please, no-one use this until/unless it goes into CVS or you're testing it for the same. access to all of inventory is an advantage, and you might get in trouble if caught using this)

 

000629 new widget type, frame. canvas to put other widgets in

currently tabs actually embed another window inside them, then leave that window to display stuff you put in it.

You also have to add and manage your own scrollbars. In most cases, that'll probably be setting a length for the scrollbar when you write your code.

It's easy, and it looks bad.

just open the encyc, the pages might fit in the window, but you still have a hugely long scrollbar (which is used for the help tabs)

This patch fixes the problem. Simply add a frame/canvas/whatever to your window, then you can pass any other widgets into it (you must still create the widget in the window, but you can then pass it over to the frame). The frame will automatically add/remove/resize the scrollbar, as the window size changes (assuming your frame occupies the whole window. otherwise when you resize the frame), or when you add/remove/resize stuff in the frame

One thing that could be a downside is that this requires everything in the fvrame to be a widget... but good practice will be to use widgets instead of doing it manually anyway, so it might be a good thing

there's an example window w/ frame in this patch, people who are curious about how it will look can use that pre-made example (though it needs to be removed before going into CVS, of course )

 

 

 

ones I want in, but not ready to be committed

 

 

000565 add names for more of the channels(the tabs)

nothing large here. just adds names (instead of numbers) to many of the channel tabs. also fixes one typo for the create-char screen "about human"->"about humans"

Note: After this, you also need to update the `languages/XX/strings/titles.xml` files. I can provide a patch for the english ones, but languages stuff comes from another place, so providing that patch here won't work out right

 

 

 

000489 adds #url to list last 20 seen URLs, and #url <num> to go

(yes, the title is now wrong. this has come a long way from an array of 20 strings in console(thanks, vegar, for telling me GUI is better for most users)

a window that shows all URLs the client has seen. not just http:// but also others like gopher:// and email addresses. F2 still works as you expect, it's just handy to have.

This should not be added right away, because: (1) I'd like to convert it to use the frame-widget, and have the URLs as label widgets with underline and tooltips; (2) there's an SDL bug, where since we're launching the browser on mouse_down, ELC doesn't get the mouse_up event. this causes odd behaviour. (3) currently you have to type "#url" to open the window. it needs a button or something before it's completely GUI based. and (4) the email catching is way too liberal. it'll catch things like "@message" (note that for things like email addies, gopher, etc, you'll be launching them in your default browser. on windows, that's now a system call, so the associated program should be opened. on *nix, if you're using the web browser that's built for your desktop environment, hopefully it'll all work (I expect it will with KDE, don't know about gnome, it'll work with mozilla if you have the mail client setup, won't work with other browsers))

 

 

ones I don't want in

 

 

 

000607 just a few comedy commands I'll include in my client

some of these might be useful, like #rainbow, which demonstrates all the colour codes (I was first using it when trying to decide on a colour for a log_to_console message). mostly it's just fun stuff, and won't give any advantage to a player.

should probably be set as rejected (allowed for custom clients, won't go in CVS)

 

 

000572 remove colour codes from #GMs received

Learner posted that this should be done server-side. I mostly agree (some people like the coloured #GMs). Dunno if it has been done server-side yet. if yes, this patch is out-of-date. if no, you could copy'n'paste from this one if you want, it's very little code

either way, it'd be nice to remove this from the pending list

 

000605 make the loadbar a bit more colourful(scales colour)

out-dated, other work has since been done

 

000608 a shortcut `#lc all' to leave all channels

Learner said this should be done server-side. I agree. once/if it is, this patch will be out-of-date

 

 

000613 progress towards snow support

outdated and supersceeded by lachesis' new weather work. the concepts may still be useful in the future when we can define weather areas, however

 

 

 

If i need to re-do/add to some of them before they can be accepted, let me know, and I'll try to figure it out. (except the URL window, I know that one needs work)

if the patch is out-of-date or whatever, please reclassify it as so, so people won't try to use it, and it doesn't fill up the list of pending patches

if the changes won't be going in CVS, fine, please reclassify them so they don't fill up the page of pending patches(yes, the page is kinda long)

and if they do go in, well, the sooner the better

Edited October 24, 2005 by ttlanhil

[crusadingknight]

Sorry, but I had to split this. It's too long, and duplicates the topic. (Since it's a lengthy reference).

 

BTW, maybe try organizing it into categories like 'obsolete' or 'current' next time, so it's easier to parse.

 

EDIT: Uh, made my intentions clearer. Typographical error fixed.

Edited October 21, 2005 by crusadingknight

[ttlanhil]

Sorry, but I had to split this. It's too long, and duplicates the topic. (Since it's a lengthy reference).

well, prev thread was patches I wanted in, and about half were the same patches. either works fine for me ^_^

BTW, maybe try organizing it into categories like 'obsolete' or 'current' next time, so it's easier to parse.

212153[/snapback]

done ^_^

[ttlanhil]

bump.

I'd like to get a yay or nay on the frame widget and the expert config patches soon, because I'd like to do new patches using those. if they don't go in, then the following patches will have to be done differently

[Lachesis]

(to ttlanhil) Meep! Is that list in order of priority?

The pane implementation is certainly an improvement, (to all devs) however I still don't like the separation of windows and widgets. They should share a common base class so they can be nested and we don't have the problems you mentioned.

I'm indifferent about the other patches. Please our developers, please add your comments

 

With Regards

Lachesis

[crusadingknight]

(to ttlanhil) Meep! Is that list in order of priority?

The pane implementation is certainly an improvement, (to all devs) however I still don't like the separation of windows and widgets. They should share a common base class so they can be nested and we don't have the problems you mentioned.

I'm indifferent about the other patches. Please our developers, please add your comments

 

With Regards

Lachesis

213163[/snapback]

Making a general canvas object which allowed some window-style properties, but generic and individual handlers (like my proposed widget implementation), and making windows just a subsidary type to them seems like a workable implementation?

[ttlanhil]

(to ttlanhil) Meep! Is that list in order of priority?

The pane implementation is certainly an improvement, (to all devs) however I still don't like the separation of windows and widgets. They should share a common base class so they can be nested and we don't have the problems you mentioned.

I'm indifferent about the other patches. Please our developers, please add your comments

 

With Regards

Lachesis

213163[/snapback]

no, they're split by 'please add', 'want to add later'[note], and 'don't want added', but within that they're not really ordered. the priority comes from where other devs see that the code is useful.

[note: the channel names one is actually ready to go, but as long as the languages repository is in a different place, it'll require two seperate patches, and translators will probably want to go over the languages one]

I think the timestamp, expert config, and pane are high priority, however the pane might not be finished. like you say, windows seperate from widgets isn't needed... the downside is that even if the work is simple, there's a lot of code to change(the pane's way of having widgets inside a widget is kinda a hack, though I don't think it's too bad of one)

timestamp does solve one big bug, the repeated message in error_log like a thousand times over

I feel that expert config will make the options window more newbie friendly (and we can say "well, if it was in expert config, you messed with it, didn't you expect you could break something?"). the priority I have for this one is that it reorders all of the variables for the options window. they are currently all messed up, this patch tidies it up, but this means any changes in CVS to options require manual updating

 

aqua helthbar is very low in impact/importance, but has been on the patch list a while. I'd be quite happy if it got a 'no' and was rejected, i just don't like how many awaiting patches I have on the list

config save and window position save are kinda clean-up, quickbar is a minor feature

 

Making a general canvas object which allowed some window-style properties, but generic and individual handlers (like my proposed widget implementation), and making windows just a subsidary type to them seems like a workable implementation?

213165[/snapback]

widgets are already set up as a base type, with extras added on depending on the subtype (you can tell that cases like this are where classes are handy ), whereas there's one type of window, which is seperate. if you can nest widgets, and the window becomes a type of widget

 

the stuff like auto add/remove scrollbars would be great for windows to do themselves, though that does imply that you will use only widgets. no writing the text yourself. while good, this means we need further work. the label widget might need to be extended to be able to use underlines(which is the reason I drew text myself in the URL window, instead of a label widget), bold, maybe changing colours (could codes for underline, bold, italic, etc be added to the colour numbers?)

many existing windows probably need to be adjusted as well (perhaps a text-area widget, that you can resize and it dynamically wraps the text, over many lines, and shrinks/grows itself as required)

note that some of these changes will also be required if people can change font size ingame, or if you use a font that's not monospaced. I beleive the stuff in encyc/help requires the writer to do line wraps themselves, and this won't work with non-monospaced or adjustable size font(even without changing font size, this is one extra burden on translators, if the line gets longer/shorter, they may have to adjust several lines)

not to knock the good work that people have already done on getting the encyc and such in the game, it's just I think we can improve it still

[Lachesis]

Making a general canvas object which allowed some window-style properties, but generic and individual handlers (like my proposed widget implementation), and making windows just a subsidary type to them seems like a workable implementation?

213165[/snapback]

Exactly. However, lots of handler function pointers waste memory space. So "handlers" that are actually virtual (overwritable) functions should be placed in a "class object" so that an object instance needs to carry only one pointer, namely to the (shared) class. That makes calls slightly slower however all OOP compilers do it that way, so it can't be that bad

 

Anyway, slightly digressing here.

 

Lachesis