ttlanhil
-
Content count
4943 -
Joined
-
Last visited
Posts posted by ttlanhil
-
-
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).I guess what they really want to use it for is giving different prices for the enemies, not banning them. Banning is easy, and can be done at the 'point of sale'.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)Would this mean you'd use an actual texture for the particles of rain, snow etc? So you can use, for example, particle0.bmp in the textures folder as a snowflake?
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).With the rain in new_weather, is it actually moving in 3d space? If so it may be that as you zoom in the particles appear to be less because there are less in the area that you see. The problem is is that they are barely distinguisable from the background so it looks like there's no rain. -
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).set_weather_ratio(1, 100);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...Yes, and it takes only one missing glEnable() call in a routine that's supposed to only temporarily disable a certain feature, and something may get messed up in an entirely different part of the code. That's why I'd like people experiencing such problems to compile with only the most basic options, turn off any fancy extensions, and see if the problem remains.
-
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.i'm using winXP, and when I tried out the new CVS client it placed all the custom data files in the user/applicationdata/etc etc... long windows directory place.
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).Are there plans to make it available for windows too? (I always like to keep that custom data in the install directory, not in window's directories).
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.btw one other thing about this. When I first tried running the CVS client I got the starting/load screen then it immediately crashed. I had to change the dir. in the .ini to this:C:/Documents_and_Settings/MainUser/Application_Data/elc
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 hardAs for the crash, it is a known problem. I mentioned this to ttlanhil (who wrote the patch) when testing this code under Windows and it was decided that rather than hack a fix into the client, people would just be notified when updating that this variable needed to be set (or it would be automatically set in the install, which is the correct way to handle this). For those testing the CVS client it was considered they would know enough about the things to know it needed to be set up, and how to do it. -
7? Hmm, yeah, I don't think that's a common occurance, but I can see the issue.Well given I've logged into EL with 7 characters on my old linux box, and the list of files that grum gave. I can see it could get crazy.
Well, apart from exploration data (which in the old system is stuck in data_dir/maps IIRC, and with NEW_FILE_IO is moved with mapmarks into config_dir/maps) the number is limited... However, if there are many characters played on the one computer then it may be quite handy.Data like spells, counters, quest logs, exploration maps, and perhaps notes, all of which are per-character data.I think the big problem you'll face is how much to split out.
Exploration data? Probably (with newer options, it's stuck in a directory only with mapmarks, and I think it'd be somewhat rare for users to have any reason to mess with any of those files, apart from maybe looking up coords in a mapmarks file, so a clump there isn't as bad (the number of mapmark files is already a large clump)).
Data already split is easy enough.
Logs? If so, which ones (chat_log, but not srv_log, connection_log or error_log? Is there a reason to split those as well?)?
Notes? (of course, you could have it made so the notepad has both all-users and this-user notes, if you want the added complexity).
Ignores and filters? I'd be inclined to leave them global.
el.ini and el.cfg? Probably global (although it could also check a player-dir to see if one exists there first, so a user can manually create a new location for their config; when saving it checks if the file exists before saving to ~/.elc)
I don't think thered be, as long as we only use config_dir and not data_dir (which we should be doing anyway).I just hope that there won't be problems with permissions and stuff like that, especially with supporting multiple operating systems.We won't be able to run on system without directories (some old filesystems...) anyway, I can't think why we would be able to create normal files but not directories (although having code in place for a can't-happen isn't that bad either), and apart from non-NEW_FILE_IO on windows, we already created data_dir/.elc, and change the files there or even add new ones regularly, so it'd be suprising if we couldn't make a new dir.
-
Why should the time have to change (Whitestone standard time is used by all people across the known world, or some such)?
Just have it so sunrise/sunset/etc is offset by a half hour or whatever when you change continents (for bonus points, the new sky can be adjusted, not just for where it's up to in rotation, but also offset north/south).
I had a patch to do the first part years ago (it's really quite a simple change, just messing with the sun position table), the main thing would be deciding where the continents are, globally.
-
Data like what?
If you split logs on date or channel then there's enough for a logs dir, otherwise just sticking it all in $HOMR/.elc/ is generally enough.
I doubt there's enough per-player files that splitting that out will make much of a difference (those who can find the files can handle sorting those few, I would at least hope).
If NEW_FILE_IO is enabled, then even windows users have a home dir used as well (and a subdir of that for map marks and minimap data).
-
There are patches on berlios for adding the name (when set in ctrl+o) and/or the date (as above) and/or the channel number (ditto). It's handy stuff in some cases, but some people would have trouble searching through the files to find something someone said between 2 and 3 weeks ago
-
You don't really have to bid, it's non-exclusive, anyone can rent my opinion
-
What is the exact error? Do you have disk space spare (you can check with the terminal command 'df')? Is there anything interesting at the end of ~/.elc/error_log.txt?
Incoming event message filter
in Programming
Posted · Report reply
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.