ttlanhil

Well, I find the idea somewhat scary, considering how much I've broken... Other than that, I don't have any issues with this idea... My silence is tacit acceptance Unless objections do pop up, or there are problems in the code, I'll be happy to stick it in CVS in a lil while. Although while you're at it, people have asked about harv deaths and events... Not sure if that's offtopic for this thread; if not, what would you think about that as well?

Well, auction's over, it will be sold (not yet collected) to the person who bid 33kgc in-game

Another in-game bid of 33k now

first off, I'll need to tell you a bit about this all. I talked to entropy about this idea a few months ago, to get permission. he liked the idea (I'm hoping that this video server may get 'official' hosting once it's well checked... we'll see on that) a while later I did some work on it now and then... recently I rewrote a lot of it, and today I finished that off. so far it has been working well as far as I can tell... which means it needs more testing it's not a movie like an MPEG or AVI or anything like that... it's recorded EL (the actual network traffic is recorded to be sent later as a movie)... what does this mean? well, with this setup, you can have a bot recording a PK match, and then anyone can later view it... not only is it available, but you have total client control when watching the movie. that means you can zoom, pan, etc (none of the normal server commands work, although being able to pause matches and the like will be of interest) that also means that since people don't have to be there at the time to see the action, there's less lag for the fighters... while they'll probably enjoy having a bit of a crowd, this will be an advantage (the fact that you won't see much of a crowd in the videos either is perhaps the one downside) and since it's recorded EL traffic, it's light on the networking... if you can normally play EL on dial-up, you should be able to watch the movies on dial-up as well (note: if there are a lot of people at the event, etc, it'll be higher than average traffic. you need to consider if you'd be able to be there, rather than if you can normally play) right now, AFAIK, only vakana/yaelbot is set up to record anything, but the saved movie file format is simple enough (skip it if you're not interested in coding): optional 'description' as the first line (cannot start with a number), ended with EOL then repeated until end: a timestamp, tab, packet length, tab, packet, EOL the timestamp is in millisecond resolution... what it starts at doesn't matter, only the difference between them. packet length is the number of bytes in the entire packet (if the packet holds exactly one message, then packet-length will be the message-length plus two (EL protocol says you don't count the length bytes when making the message length)) the packet is a byte-wise copy of what was received from the EL game server over the network. the video server and file format are perfectly happy for a single message to be spread over many packets, or for a single packet to have many messages (which happens at the moment) as of right now, only linux has been tested... if you have gnu-make and gcc/g++ then I assume any *nix system should work... windows is probably not going to work, at least at the moment... there are 3 platform issues; listing a directory (it uses the same code I wrote for ELC, so that part should be windows ready), signals, and networking (that won't work on windows). right now it uses SIGUSR1 to indicate re-reading the movies (there's no admin mode once logged in... the only things you need to do as an admin are reloading data and shutting down... unless an IP blacklist is added). the signals parts could probably just be removed for windows builds, they aren't needed. if you want to port the networking to windows (convert the BSD sockets to winsock or whatever), feel free. MSVC won't work. ported gcc like in cygwin, dev-cpp, code::blocks, etc may or may not. the intended target is *nix (linux and *BSD, mostly), however, so I don't have much interest in the porting to other platforms you should need only the normal C++ development environment (make, gcc, g++, stdc++, glibc) to compile and run (well, and tar/bzip2 to extract from the archive ) part of the work I've been doing has been to get it to compile without warnings (g++ -Wall -pedantic -Wextra), and to run under valgrind without error... I expect it could be made more efficient in places, but it shouldn't be too bad as is. I don't have a static IP, so I don't want to run a server from this computer... and I'm not too interested in running it on someone else's server at the moment (I'm hoping there will be a number of improvements to make, which is a lot easier if I have control over it) today's archive is here. download, unzip, make, run. then start an EL client pointed at localhost:1999 (or if you run it on another computer on your network, use that, naturally) I won't tell you more about what happens next, because the usability of the commands is one of the things that needs testing now, a warning: there's one included test movie... it's a recording from vakana logging in and waiting a bit. vakana, when not in video-only mode, checks a bunch of stuff on login. you will be spammed. after the initial tests, I (ttlanhil) checked inventory. then a while later, you'll see people walking around. and that's it until the end (no, it's not exciting or even that interesting) stuff like rewind, fast forward, etc won't work. stuff like statistics might, but I'm not too interested in that. as far as the server itself, I'm pretty happy with the options available, though I will consider suggestions for more features... I'm mostly looking at fine-tuning what it currently does so... questions, comments, patches?

Building a snapshot setup would be possible, but it's a lot more complex than simply replaying what the real server sent to the bot... At the least, it'd probably look like a resync to change to next image... If not a full new map-load... And any chat from before the snapshot won't be showing on-screen, because while the client displays it for a while, it's only sent the once. On the up side, if I did have that working, I could make it automatically snapshot each minute, so people can jump forwards/backwards a minute at a time. And if that were done, and I could build lists of movies with offsets (as to the difference in when each started) then I could add a command to jump from one camera to another at the closest snapshot... Mind you, that's again at least a resync, and probably a full map-load. Some people's computer speeds will mean they miss a heap. The alternative to that is combining the video logs from several bots, which would look better, but would be more work again (just adding #jump would probably be more work than building the recording into the bots and the playback server was). Of course, for it to be worth my time to do all this, I'd need to be doing a fair few showings, which means having a number of camerabots approved to go to a wide range of events. I did have a short test video before, but this was the first real test of how it worked (as far as I can tell, it all worked as it should, although some people seem to have trouble with a double-login which is in some logs). As some people may have noticed, my 'Net connection dropped out earlier today (Ever since we upgraded to ADSL2+, there have been dropouts now and then, once per 2 weeks or so, on average. The 1.6MB/sec is nice, but still), and I have dynamic IP anyway; so it's no-where near being ready for many EL residents to be able to use.

Okay, best offer so far was 30k in-game. Still a little while left to bid!

Okay, well, since I recorded the EL Gala, I may as well have this open. It's currently running with a server address of "ttlanhil.homeip.net". Please test it out

I'm sure this was a learning experience for a lot of people IMO, it turned out really well. Right at the start I realised I could record stuff, so I quickly got approval from Roja to bring on some bots... unfortunately, it took a while to get them into place and all, so the first half hour is missing, but the rest was recorded from 4 places (of course, since the action was generally only in 1 or 2 places, half of that isn't too exciting). If anyone's interested, and can compile C++ (or has a friend who can), you can grab my movie server software and the movie files from here: http://users.on.net/~gingerman/el-vidserv-EL_gala.tgz Mind you, that's 2.5-3 hours long for each of 4 camerabots, and there was a lot of activity, so the files aren't tiny (a total of about 1400 KB in movie files. For about 10 hours, and with the quality you can get, that's pretty good! The code and the rest is only like 50kb, so the package isn't that large). There's a quick readme in there, but as long as you can manage to compile the beast, you probably won't have too many problems beyond boredom in the slow parts. It comes with the ability to pause (though no fast forward/reverse), so please make the most of it and pause in the good scenes, pan around (afterall, you use the EL client to connect to the movie server, you have no control over the character, but the camera is free to move), and take screenies to share! ed: The movies are all uncut, mind you, and I haven't checked over them to make sure there wasn't anything inappropriate said. Which there probably is. You'll see PMs between ttlanhil and the bots, and you'll see a lot of spam from players. If you do want to try this out, don't complain about what you saw (only give feedback to me in private or the movieserver thread in programming (I think) if there are issues with the server) ed2: If anyone feels like hosting the server, feel free. If so, please spread the word so other can see as well (my computer has the uptime, 1278 hours and counting, but I don't have a static IP or dyndns set up ATM). You'll just have to allow connections from the 'Net on port 1999 and explain to people how to use your server instead of the EL server. Scratch that! I've set it up on my own computer. Hopefully it'll all work fine (you can still download and play locally, which will give a terrific ping, but not needed). To connect, do something like: ./el.x86.linux.bin -sa=ttlanhil.homeip.net or edit your el.ini to use that server address. Once connected, use any username and password you like (preferably not your real password, since you shouldn't trust me as much as the EL server, but as long as your client sends the login message it'll succeed) ed: Now should work on port 2000, so only address to be changed to connect to movie server. ed: Discussion about the server should go over here Heh, yup!

In that case, the posted times are wrong, so it'd probably be advisable for someone to try to get a mod to announce it... But on the up side, being earlier than was stated means I'm more likely to be able to stay for the whole thing As for the times thing... UK time has daylight savings. So it's currently 17:35. UTC/GMT does not, and is currently 16:34. That's correct as of the time I posted this message

We've just had a bit of a discussion about all this on @@4 in-game... So now I want to make sure... The GMT times are correct? That means it starts in about 2:20 from when this message was posted? Some people are confusing UK time (which is daylight savings adjusted) with GMT (which isn't) and think it's in 1:20.

Not only is this problematic for the economy, because it messes up the prices (the prices would be reasonably stable if things kept in circulation, they go up now and will drop later... Probably pretty quickly once it starts), it's also risky... What happens once a few of the hoarders sell or Ent increases the rate? The price will fall (and hence many other hoarders will see it's time to sell, and down goes the price). Much of the real world isn't applicable to EL, but some of it is. We can draw a few conclusions from that.Ent has said the rate will go up again later. If hoarders don't sell a heap by then, that's when the price will drop. Unfortunately, price fixing in the form of limited supply isn't, IMO, good for the economy... But the economy wasn't that great anyway

Unique or levelled items have come up before. It's not really feasible to do with EL's current design, beyond the existing rares (there are probably a few pages of explanation somewhere on the forums )

A life? It's a type of ore. You make material points from it. Or the intention could have been life essences...

That can also mean he made a second post quickly... If you make another post after your own within... 5min or so, and no-one else has yet posted, the forums will merge the two.Not only does it avoid the edit info, it also means you can slip in more

AID. From years ago until a few months ago when it folded (sigh). Since then, IRON. My alts have been in more guilds... in order: SILK, GARD, the RP guild (before it was decided that only mains could join), NULL (yes, that's a current guild), and possibly others in between I forgot about

Given that the rules tab is part of the encyc window, and people need to see right away if they get sent the rules, I'd say it's a feature

CST. Oh, wait, I actually know I should explain it. That'd be central Australian standard time. (mutter, mutter, silly people assuming everyone will know it's the same as them. Dare I say that'll mostly be Americans, giving misleading answers like eastern time (Gee, how many eastern time zones would there be in the world?) with no qualifier?) ed: Even better, as far as clarity... I'm in UTC+9:30. During summer, it's UTC+10:30 ed2: And for those who might not catch on, summer here is officially December 01 through February 28/29, with daylight savings extending a month and a half or so either side.

*shrug* Okay, I just expect nearly everyone will change to extended camera reasonably quickly. Yeah, house insides are easy to do, they tend to be roughly square and not give access to anything else through use of TPTR. Dungeons are another matter, such as people being able to jump rivers or walls. It will work okay if the obstruction is thin, but if it's more that the padding we expect, the other side of a river or whatever will no longer even be seen (although people may still be able to TPTR across).

Whoo, got a phys stone in the toads today (not that it should suprise people I got it there. I probably spend half my EL time on toad runs...)

So we'd have to look into the map to see if the tiles there are water or rock or whatever as well? That gets complicated.Perhaps it would be simpler to raytrace into the walls when inside. As soon as you hit a wall, don't draw anything further along. That allows places that don't have walls but are still unwalkable (such as rivers) to be seen past (for that matter, we're actually looking at the same requirements as archery would have... perhaps we could use the same formula as would be used for archery ) Hmm, okay, we can do that, I just don't see why we'd want a checkbox (and hence spend screenspace in ctrl+o ) to lift the camera a meter

Yes, the only reason why one would possibly want to store it in the map itself is the fact that map loading is already quite slow, and I'm not sure how much extra time is needed to compute the extra bboxes on load.Well, I was thinking about extra data structures to hold a list of 2D boxes, but adjustments to how the bboxes work should be good too. Yes, loading the maps faster would be a good thing, however it's the need to change the format I was looking at (then again, you can probably whip up a script that can update all existing maps as well as updating the map editor anyway ) No, I don't think so, it should just mean that all maps need to be checked with the new behaviour before being released. However, the FPV option already means that minor mapbugs are a lot more visible, so the maps will probably have to be closely investigated anyway (hence why I stuck it in CVS when there are still all these known bugs) ...but this is something we should preferably take into account right away.Right. However I don't see why it would be too hard to do, just disable the check for the local area, since you can't without an actor (to indicate which map you're in) anyway.Actually, there's a thought. This could cause issues with certain mapbugs, like if there's a single walkable tile several steps away from the cave-proper; or where there is no valid data (I don't know how nomap.elm is set up, for example, if everything or nothing is walkable). Of course, we want to be rid of all bugs anyway, but they could cause a problem. Which then gives me another thought... Where TPTR or teleplatforms are currently used to jump (disconnected) sections. The platform in Tarsengaard's mage school, for example... It's probably close enough to other walkables to be okay, but it serves as an example (the rest of the map also serves as an example of being able to see other rooms and all )

Oh, I know, just saying that the introduction of perspective settings is what caused the problem in the first place, extra zoom would just make an existing problem a bit worse. Yes, my vote would be to make the higher camera focus the default. I think it's only the middle-click vs middle-grab that's worth being configurable. It can be done without needing a change to the map format, by just growing a 2D bounding-box (several boxes or a polygon would work better, to be able to cover non-rectangular map-sections, see maps like vermor castle for why a single box would include separate rooms, but that's more complex) per contiguous region as you check the height-map for where you can walk to when loading the map.One thing on this, the lighting will change in some cases. A light a long way down the hallway would then be used instead of the light close-by in another room (not directly connected). Probably a good thing, but it may cause some areas to become unlit until someone fixed them. This would, however, make creation of custom tabmaps harder, as you don't see more when you zoom out (and consequently it would also need a special case when the EL rendering engine is used in map creation; but since you don't have an actor position that would happen anyway). ed: As for the camera, I assume that someone properly versed in the use of the bbox trees could apply the appropriate culling without too much work (say, that should also make performance inside a lot better).

The only way to do this is by checking the dungeon flag, which means that houses as well as true dungeons and such would be limited zoom. However, some caves and castle insides and such are pretty large, perhaps as large as some outside maps (as one block you can travel around in, as opposed to separated rooms).The ideal solution, IMHO, is for it to only display the current contiguous area (with a tolerance of a few tiles, so that you can see through iron bars to another room if you would be able to use-click something to go through (but not walk straight there); but although that's more flexible (as long as mapmakers know the tolerance of pseudo-contiguous regions for when designing maps, they shouldn't break anything. Heck, with this, you could design maps with the padding between rooms of only, say, 5 tiles instead of 20, so you could pack it a lot tighter) it'd also be more work to code. As for seeing into other rooms, we've had that since at least the update that added perspective, many moons ago. The extended camera does a few things. It lifts the camera focus from the character to a meter or two above. This gives a bit more visible range in camera-forwards, but I don't think it's that significant a change. It also affects things like the range of freedom for the camera. I suspect players will prefer that anyway, so an option to reduce camera freedom (ie disabling ext cam) wouldn't be used much. And finally, ext cam is required to use mouse-grab (the middle-mouse to enable. As opposed to the old style of hold-middle to pan. Mouse-grab also requires non-SDL cursors, although this is just so that you can have decent crosshairs and could be worked around). But this is the only one where I think it's worth being configurable, so I think it'd be best to make the above two the default, and label the mouse-grab option.

One thing on this... If every walk-click went through the client pathfinder, we may be able to take more load off the server's pathfinder by having the client send shorter walks (the greater the distance, the more calculations needed, and all that)

When he gave it to me, it had the greater range of camera freedom... However, non-FPV with low angles didn't have the same LOD adjustments, and got really slow (especially on large maps). So it can be done, but it will take more than just changing the limits.However, I'm starting to wonder what extended-camera is really for. I'm inclined to remove the option, and make it the default. Of course, the next thing people will want is more zoom when not in FPV, so they can see further... However, now that we need to make sure it looks okay in FPV, I'm not sure that we have as good a reason to say no Both. First the jitter, which becomes worse, the completely stuck.Okay, so, you move the mouse, and it moves and them jumps back? And eventually it doesn't move at all, and you have to middle-click again to release the mouse? Where does it finish at, top of allowable mouse range? Bottom? Middle (exactly)? Do you still have left/right when up/down doesn't work?