ttlanhil

Now in CVS Yup, it's now using a static int as a bitstream. Perhaps not as elegant as an array of window IDs, but it works

Or so I thought. Unfortunately I can't just copy FONTS_FIX for the fonts, since the number of language dirs may change, and it'd be a big problem for it to go to the wrong one.I could make it so the tooltip for languages has the list of available names, I guess. The other option (which I was considering before) was to make MULTI variable save as text; but to do that we'd have to init all the types before loading any variables... even where el.ini can be found. So that's no good. (And we have to check things like the available dirs for languages first, so that we can select the right index when we do get around to reading in variables.) Sorry, but right now, it's not that feasible unless someone else comes up with a better approach.

Sure, except that MSVC does not support all of C99 (a lot is supported than gcc, though gcc doesn't support all of C99 last I heard either). We can generally rely on C89 support, with support for some C99-isms (such as C++ style comments). Variable declarations mixed with code are another case where we have to go with the C89 standard, MSVC doesn't like that, either.

Actually, no, when you don't care what the max size is.Theoretically, it could be slightly faster than an int, depending on the CPU. As such, it may be useful in highly-critical sections of code where you need to squeeze out every last cycle (ops that are called a thousand times per second; where a large amount of the CPU time is on integer mathematics, for example). There are certainly places in ELC that need tuning, the client doesn't run as fast as it could, but things like that datatype just look like premature optimisation to me. Of course, you should probably talk to Xaphier before changing it

It can be done. But not well. Not if you want names. The fast-click scamming that may work on some bots will cause the same problem here; the name associated with an item (trade slot) may be wrong.Ideally, the server could send a name with trade items, not just the image ID (heck, it could send the entire description; which the client could cache, and hence eye-clicking your items would be instant and use less bandwidth). Until and unless that happens, however, I don't think a trade_log.txt is practical.

As a foreword, since it seems to have been ignored (and yes, check your bots logs, it is common): Also: Same problem as above, though it doesn't really have anything specifically to do with a bot channel; matching item names it useful already...And different bots will have different approaches and levels of matching already. Unless you suggest all bots have a certain method of item name matching, and they have to use that and only that for this channel (and it's backed up by the rules) bot owners will do what they can to increase sales. That means matching even if other bots don't. Even if it's one line per 10 bots, that's gonna be rather a few PMs. Probably better to have a few (for example, 4) 'nominated' bots that post every now and then (in this case, once an hour, properly offset) so that there are regular messages on the channel so that people know how to use the channel. Why not one bot? So that if one is missing then you only miss one example (so there's a half hour gap instead of 15min. Not great, but not that bad).How long this should be, I don't know... Perhaps one message per 5min, even, would be appropriate. The bots would, of course, have to have reasonable uptimes, reliable timers (vakana used to use a delay for her timers, rather than clock time, so she wouldn't have been reliable before), and different Earth locations (no good having a dozen bots on the same machine doing this) Regexps are tricky to make safe, and well beyond the capability of most people. Limit it to substring matching, with possible acronyms (ie: MtE for matter essence; ME should not produce a match as it's indistinct), and fudging ("ring of X" vs "X ring"). Just because LabRat doesn't like the idea doesn't make his points any less valid. And how can you expect bot owners to develop and test things when you say you'll clarify exactly what the syntax and all means later?Maybe you haven't worked on large projects before; but you need to plan your project before you jump in and start coding. Coding without plan leads to patchwork, feature creep, and ugly design. What penalties will there be for bots that are better at matching? Assuming "HE" isn't defined as meaning "Health Essence", but a bot matches anyway, what are you gonna do? Nothing? Then bots will match it I'm glad you at least know this idea was bad

According to the docs I read; that type is used when you want the compiler to guarantee that you will have an int of at least 32bits, but it can be bigger if larger is faster (ie native bitsize or whatever, I guess).This looks like the sort of thing that's a case of premature optimisation; Xaphier has a compiler that supports a lot of new things (the TR1 #ifdef is to use technical recommendation #1 support for the next C++ standard, as I understand it), so he uses it. Later on, we find out other compilers don't support a lot of this stuff, and have to compensate. One of these days I'm just gonna up and split global.h into two parts; one for the bulk-include and one for platform issues, and then #include the platform one to anything that uses types or functions we have to (re)define... I don't like the bulk-include in files that don't need it, but things like the above problem will be easily fixed if we can just include the platform one.

Right. No, Free's suggestion is a client-side change. What you're talking about is a server-side change (I like the idea as well, but it's a separate issue).

I think it's far more likely that's related to Xaphier's large changes, but it's possible... When I get Emajekral's code fixed up and into CVS we'll see.

This makes me wonder if it's worth going to a more KDE-esque style where you can assign multiple key combos to a task... I intend to try to come up with a hotkey editing GUI at some stage, so I may take that approach then. In either case, I sent Grum an ICQ message, but I dunno if he even uses ICQ anymore, so: When you hit escape or enter to send a message, the highlight selection on the input widget isn't reset, and I think it should be. (Unless this was fixed in CVS within the last few hours; in which case just ignore this part )

You'd need to get Learner or Entropy to look into this, to get the server to support it. As for the client, well, I'm pretty sure it would only take a couple of minutes to add support for this, the current way to display windows would be simple to extend. ed: Correction after remembering some of the code in ELC

Perhaps unfortunately, there are a great many things that EL can do that most people don't know about. And because of the sheer number of little tricks and tidbits, trying to document everything would make the list so long few would read it But yes, a while ago I made it so that #save would save all local data as well, same as on logout. That's your el.ini and el.cfg (settings), counters, notepad, and anything else that should be saved on exit. It's not perfect, because crashes can wipe data, but I think it's a reasonable step while we try to fix all the crashes

I see several points here, which I'll cover. -Bots on a separate channel. Covered before, general concensus is that we bot owners don't really want to lose the business, but if it can work well, most of us will probably support the idea. That's the idea behind that thread about a channel for bots to lurk on, waiting for "wanted fire essence map:portland" or similar. -Bots with poor prices. In a few cases I agree, like when a certain bot is suggesting great swords are worth 15k (as opposed to the 20k the NPC pays). But mostly I disagree... In the past, bots used to provice the middle ground between players and NPCs on quantity, availability, and pricing. I think it worked pretty well back then; but nowadays there's too much supply and not enough demand in many areas (bots aggravate the problems with the economy, but they don't cause them). I don't see a problem with bots having 'worse' prices than players, as their availability and stock levels make up for it (I do, on the other hand, dislike bots having to compete with each other and players on price). -Botspam. Well, some of us bot owners dislike that too. The rules say our bots can post once per 15min. Some bot owners don't have their bot post at all, others with a far larger time (vakana, for example, has one ad on @@3 per hour, even though it seems to have reduced trade)

Counters are only saved when you log out or manually #save (the one when you automatically save from trading doesn't count). It's unfortunate, but the best we can do is tell you to #save regularly and report all crashes with enough info so we can fix them

Currently Emajekral's old banners code is in CVS. I have a newer version of it, but I haven't been able to finish getting it ready for CVS (fixing other problems and such). When it does go in, it should fix this problem (I've seen it to; for what it's worth I think you can increase the size of the floating messages with the name font size).

None of those errors is critical... I'd suggest that Freeone's comment about overheating is still the best bet. Please try limiting FPS in ctrl+o (or edit ~/.elc/el.ini ) and see if that helps

[11:22:17] Couldn't find the GL_ARB_fragment_shader extension, not using it...[11:22:17] Couldn't find the GL_ARB_vertex_shader extension, not using it... [11:22:17] Couldn't find the GL_ARB_shader_objects extension, not using it... [11:22:17] Couldn't find the GL_ARB_shading_language_100 extension, not using it... Your card/drivers don't support shaders, sorry. Xaphier's code really should be tolerant of this, but apparently not. In the mean time, you won't be able to use shaders, so you may as well remove USE_SHADERS from your make.conf

This has come up before. The answer was no. Why? Because the ways where it'd be most useful are where it'd get around things. Getting to an area of the map you shouldn't, or shouldn't without a lot more effort (imbroglio springs to mind. A few TPs there and you can bypass nearly all dangers). Even if you can walk there normally, this can be used to skip PK or environmental damage areas... And those are there for a reason. IIRC, last time the thread then derailed onto a repeating TPTR spell (hop hop hop, to overcome the ability to get places you shouldn't but not dealing with being able to jump through an area quickly). You have the portals room. You have rings. You have TPTR. You have boats/flags/secret shortcuts. Learn the game well, and you can move around pretty quickly. And lets not bring up that tired old running discussion again

Perspective should have an effect now... It was broken for a while, but I restored the old behaviour. The extra zoom is probably due to a difference in scale of zoom, rather than being able to zoom further (as in, the same reason why a mouse-scroll makes it move further than before). AFAIK, it is unintentional; however with the new 1st person view and all, it's possible it may end up becoming a permenant change.

Do you get information about support (or lack thereof) for shaders in the GL checks on startup? If so, what support is there? Also, it shouldn't cause a segfault if they're missing, but have you copied CVS/elc/shaders/data/shaders to datadir/shaders ? (I know this one isn't well documented. But you need to copy/link that directory over to datadir).

Today is a special day: Smile Day. Today we all smile all the time, so that everyone who doesn't read the #day descriptions wonders what the heck is going on.

Okay, I've added the check to that one in CVS, please see if it's fixed... If not, maybe try adding checks like that (where applicable) to the places where you get the next crash so you can find all the places where the check should have been applied ed: Sorry I (or other devs) didn't get to it early, but the same changes that broke it for you broke a heck of a lot of other things as well, there has been a lot to fix today

Sorry, I should have explained better, but I was somewhat rushed for time, as well as kinda frustrated at having to fix CVS.Here's a slightly longer version. Most of the files in ELC are used no matter which FEATURES are enabled, it's just that how some parts work may change. However a few files are only used when a certain FEATURE is enabled. the files in shader/ for example, are only going to be useful if USE_SHADER is defined. And many files in io/ require NEW_FILE_IO. The way Makefile.linux is written means that these files are only added to the list of files to compile if the feature is set. Some pseudocode: foreach FEATURE append {FEATURE}_COBJS to COBJS and {FEATURE}_CXXOBJS to CXXOBJS Some files are written so that being included when they aren't wanted is safe. This is, of course, needed for when there isn't a Makefile set up for the platform; or if the user has some other reason why they can't or won't use the Makefile we supply. AFAIK, MSVC has the same problem that you do, because you have to add files to the project; not include files based on some check. So check Makefile.linux, the COBJs you should use; and the FEATURE_COBJs should be appended if you use FEATURE. That applies for anyone not using Makefile.linux or Makefile.win Hopefully that's clearer now ed: For those who have noticed that perspective was messed up (cranked way too high to look decent), I've reverted some of the code to fix that.

Ahh, well, that's the problem then. Same as before, actually.Don't include things like shader.o if you don't have USE_SHADER set, or io/elfile.cpp without NEW_FILE_IO set, etc. That's why, in the windows/linux makefiles, these are set dependant on use defines used. I understand this may be hard or not possible on other platforms, such as OSX, but if you're rolling your own Makefile you really should read Makefile.linux to see which files should be included. Please try removing the files withe the offending functions, and it should work (Yes, ideally they'd all have the #ifdef guards to prevent any of the file being used if the feature isn't set, but that's not something we can rely upon )

Oh, for the... The reason that happens is because get_path_config() is in a file that's properly #ifdef guarded, and the functions calling it are not. I'll go fix this in CVS next, thanks. ed: Err. Ooh. the previous CVS commit took ages, so it ended up in the previous commit instead Still, the big problem seems to be that you were attempting to compile files that shouldn't have been compiled, which I suspect is a problem with the OSX Makefile (sorry 0ctane!), adding the guards should have fixed it. Please let me know if there are any further problems