ttlanhil

Yeah, as I said above, just extend the valid range in the check (to match your script, most likely) and all should be well Lights that close will be valid since they cast light, it's only the "garbage" numbers that need to be cut.

As amusing as this example is, write-only memory is incredibly useful... Just look at the dead trees your printer churns out (your computer can write to it, but the computer can't read it)

If every step taken (and even walking can show the mismatch between client and server in timings, like bags opening before you step on them) or action taken is the same length of time, server-side, then all it should take is the exact length of a tick for the server to normalise all client-side actor_command animations. Theoretically, this shouldn't be hard to do or take long, but it can fix a range of glitches, so I'd suggest it gets fixed ASAP

Assuming you mean with the old/current version, not on the test server... "#sto slo" (or slot, if you prefer)

While I don't necessarily think 3 channels is enough, at least not for the busier people, I don't see a valid reason to be able to send message from outside the channel. What'd the message be, anyway, "Yadda yadda, PM me to discuss"? Better if you're in-channel to hear responses. As for the help... If you're not going to read it, you should not be making suggestions. If it's out of date, post about a correction. If you disagree, search forums and maybe comment. But apart from the newbie-related suggestions (like how to make it easier to find help, get started, etc, simplifying things the oldbies already know and take for granted), you must read and search before posting.

It used to be just an S in the corner... But when LabRat's patch for the quantity staggering went in, I changed it to 'sto' instead, since it's a little more intuitive. As for the bug... I've seen it often, but always when the trade happens quickly. If each step (you click, they click, repeat) has a second or two between, it doesn't seem to be a problem. If one accepts, then the other goes from red to green, it'll happen often. So I know it doesn't fix the problem, but slow down, and it should be a lot less common.

You get the same problem with 1v1 fights, if they last long enough (we spent a while testing longer fights with the crashes before the last update came out)... Large fights may make it more common, but it'll still happen. The correct answer? Correct the timings. If the server is sending actor commands faster than the client displays them (which it does, and for another point, see how soon you open a bag when you click on it from a distance, still a few steps away when it opens. That's the same thing, the client has the commands, but isn't processing fast enough), you'll always have problems from this, no matter how hard you try to engineer around them.

1) You can name any channel, or change their names. Just edit channels.xml . That works with the shortcuts like "#jc group" "@@group message" as well. 2) There aren't many colours available, and many have other common uses in chat already. 3) I guess using short-names for the channels could allow more use of "shortcuts", but I don't see it saving much time, compared to typing in the number. 4) Eh? You mean like being on more than one channel at once? Or being able to have a shared channel with a bunch of other people?

When tuning values for the stuff I worked on, the rain was clearly visible, or else I wouldn't have left it that way... So I'm going to point the finger at OpenGL differences between systems... Which is a problem, if different computers will display the GL_POINTS with different sizes/alpha. I did experiment with using larger points, but they came out rectangular as well as being uniform in size (not taking into account distance from camera). That could just be something OpenGL related I don't know about, of course. This all leads me to think that we may not get NEW_WEATHER until it's done with particles (which should solve the above problems).

Kinda reminds me of the compiled vertex array problems on some chips... Does playing with graphical options fix it?

Which probably covers it for trade bots, but probably doesn't help much for the others (or bots that do trade as well as other things).Granted, doing some networking so bots share the info they 'see' would mostly cover it, but that info can be rather out of date if the player hasn't been seen by a participating bot for a while.

Well, we've talked about this already, but I'll add my comments here... I would imagine that the computer can automatically change things over for you when it finds the new card. I'm pretty sure mine did when I put in a graphics card, but I guess mine is newer and all. Plug it in, put the monitor cable onto the video-out of the new card, and start it up. If no good, power down, put the cable onto the motherboard's video-out, start up, go into bios, find the option, toggle it, power down, move the monitor's cable back to the card's video-out, and restart. If still no good, you should still be able to swap the monitor's cable to the old video-out and do everything like that... That'll allow you to get more help If you didn't get anything on the monitor from either the motherboard or vid card's video-out, then check for anything not being connected right or all the way plugged in, other video-out connectors to try (even if it's a different type, analogue vs digital, for example, which the card should be able to do) One thing is to watch the monitor right when you turn the computer on, as if there's any signal at all, it will likely tell you which video card it's running from. Even if you don't get any picture later on, that can tell you whether it started with the card or not.

If you want to do this, then you can use accounts rather than just characters... That way all of a player's characters are linked into one account. Kinda a big change, but it would solve the issue with alts/bots. I think a larger problem might be that people then expect names to be the same ingame and on the forums, and some current cases won't match that... what would be done about that? forced name changes for one or the other? ed: Well, Learner beat me to it. But I did answer one of his points. Actually, possibly more than one, since making people verify accounts before making a char would fix the last one as well. It does take a little longer before people can play, which may not be ideal, but if the email addresses are checked for dupes it could help reduce the account creation spam stuff.

As far as the fade-in... The same would apply on changing map, and I believe it's present in the old weather as well (just less noticeable). The good news is that the new weather protocol allows the server to say how long the run in/out will be (which would be very low for map-change or login to where it's already raining), so fixing this means just waiting for if the server support ever comes. ed: Hmm, or was that how long until it does the fade-in which is always the same length? Can't remember. If so, then that should be adjusted. As for lines, well, one option that wouldn't be too much work is to make it only update every second rain (and only when it's 100% rain) drop as it iterates in the movement function, and do the same as the old weather with the extra values, doing a start and end point of the line, then use GL_LINES in the draw function (again, only for 100% rain). This won't allow smooth transitions from 100% rain to 90/10 rain/snow, which the current system does, and it'll still be using lines to create an illusion of moving points (which RL raindrops are), but if that's what it takes to get it in until the particle version works... Maybe an hour or two to code, I imagine. One gotcha to watch for is the float not always being exactly 1.0f And no, I don't have plans to do any more work on EL.

There is only one of each type of item, and they aren't marked. Players can certainly be unique, but their items can't. So there's no difference between one you buy from Aluwen's (minor nit-pick on the spelling there ) priestess, and one you make or buy from another player. It's likely possible with the quest system for it to record if you've ever bought a Ti chain from the priestess, but I doubt it (most people who get there have probably bought the wooden shields and such instead of killing monsters for them, so people should be used to it).

And all the stuff in the pinned topic about what to post? Crashing on map load is something I've seen before with some types of graphics cards.

Yup. According to the FPS Xaphier said he got with his... thousand or howevermany particles, it may still be very light-on in terms of computer power needed (although it will require a graphics card that can do shaders, which most can) They are, yes, and the alpha could always be turned up (actually, adjusting the alpha on the drops based on the camera zoom level may work... Zoom in more and you get a more opaque point... It's not as good as distance-based sizing like particles would give, but it may do the trick when zoomed in).

If you're able to compile CVS, you could always try using NEW_FILE_IO... it's newer and hence a bit more likely to have bugs, but it expects to not have write access to the datadir, even on windows (as you've seen, with Vista, that's now needed). The directory it will save all config and update data in isn't quite the same, but the client should tell you exactly where it is each time it starts, so it should be easy enough to find

It certainly shouldn't fade when you zoom in, however the points use a lot less screen space than lines, so it may just be a lot thinner (which you notice more when zoomed in). In nearly all of my testing I would have been at my FPS cap of 25, which should be possible with most graphics cards. While lines may work for rain (to simulate the appearance of motion, which, IMO, doesn't look right), they certainly won't for stuff like snow (possibly hail, since that moves quickly, but the rest are all slow enough that you can expect them to be points). To have lines for some and points for others means you either do zero-length lines (which may not even get drawn by OpenGL), very short (which would then give you vertically oblique snowflakes), or some special case code (which not only means more places for bugs, it also means the code can no longer blend snow with rain to get numbers between the two which would be like sleet). So IMO, using lines with NEW_WEATHER isn't feasible, so I guess this work is all getting chucked out, at least until someone sticks in particles or something (Xaphier's particles with shaders example was one of the things I was going to look at, it would have meant you'd see the points be slightly larger when you zoom in, as well as seeing detail on slower ones like snowflakes if they're close enough to the camera. GL points and lines don't seem to scale properly based on distance, but particles would). As for snow/sand, maybe you should have a look at that. Line 431 in weather.c: First number is the type, (0 is none, then rain, snow, hail, sand, dust, lava), second is percentage (no need to adjust).And the 'new' network protocol Ent wanted should still work, with old or new weather (it just forces it to be rain with old weather), so that could still be implemented on the server... Not that I'll hold my breath.

I added -DOPENGL_TRACE for chasing down some OpenGL problems, which is probably worth using when looking for bugs... it doesn't do a lot, and is far from exhaustive, but this (with -DDEBUG) may give some hints in error_log for some problems. Of course, if anyone wants to add more to that define to catch different OpenGL problems...

As I recall, either Ent or Roja has already said that, since the night vision mask is magical, it's not going to have the same issues as the technological version people know of IRL. Given that, I don't see that negatives when outside during day would be appropriate.

If you want to have everything under the same folder, then either that or install EL to the configdir (or a subdir). Which is probably simpler. Another option you could consider is simply putting a shortcut in each folder to go back and forth, so you only need to click in windows explorer/whatever to go to the other directory (I'm assuming that being able to get at all the files quickly is the main thing). The third alternative to storing in $HOME would be to move el.ini and el.cfg and the rest into the windows registry, which is the sort of nonsense many programs use (and why $HOME isn't more populous on the typical install). But hopefully no-one here thinks that's a sensible idea

Maybe if the gamma setting is <=0 then don't set it? (that's appropriate anyway, since the number is really out of bounds) Then just edit el.ini to disable gamma adjustment for those who need it (which doesn't require changing the limits that the scrolly goes to).

The code that you're seeing was all added after I stopped working on ELC. I did talk with Xaphier about which order the client should look for files in different directories in, but that's as close as I got to design of those parts. What I did earlier was wrapping only text files (binary was handled by Xaphier's other file handlers, and xml functions weren't wrapped until recently). One thing I can add that might help is that when I was wrapping the file opening functions, there was one type of file check that had to be direct to a specific path; that was for the autoupdate. Anything else would be fine if it's found in any of a number of directories. To deal with this, I added a special case for checking the update dirs. Now, as you can see in the file checks, it doesn't look in the configdir, except in that there may be files that have been autoupdated. I only designed it to be able to handle datadir files, since configdir files had a different wrapper (which would only use the OS specific prefix). As such, I'd suggest another wrapper or something so that any XML files in configdir are looked for differently than datadir ones (so only check configdir or datadir, never both, since they shouldn't overlap). As for absolute paths, well, being able to specify those may be useful in some cases, however expecting all paths to be relative is more flexible (although, yes, you need to have the right functions in place to be able to get the files you want)

Yup, it says that when you start the client so you know exactly where to find the files if there's a reason, with NEW_FILE_IO. This makes it the same on any OS, as well as separating the system data (install) from user data (config). While this isn't needed on the older versions of windows, MS is finally trying to imitate some of the security that *nix has had for decades in Vista, so it may become more important to properly segregate data. If you mean the config dir, then you can adjust that at compile time, but since the config dir locations are in the correct places according to the operating system manufacturer's documentation (all in appropriate subdirectories under the user's home directory), it's not the sort of thing I would want to be available to people who can't compile (not only that, but since you have to make sure your data is available under the new directory, people who don't know exactly what they're doing shouldn't be able to touch any of that). That's funky, because that's the configdir, not datadir, and if the data is found there, there are some really big problems. Perhaps Xaphier's recent changes caused an issue? Or someone else working on something besides NEW_FILE_IO? I don't know about now, but it was working properly a few months ago. Mmm, if I remember correctly, that's because the datadir is actually set in the el.ini that comes with the client, but not previously used on Win, right? If so, yeah, although detecting missing directories (and then defaulting to the current directory, for datadir) shouldn't be too hard