ttlanhil

*Bump* Is there any more input on this, or are we about ready for the final list to be made?

Yeah, I contributed to that thread, hoping it'd happen soon. But it hasn't, and we've gone into new-FEATURES mode, which I don't think we should be doing yet. Just a personal opinion, of course. But considering the trouble with the large list of FEATURES, I'm just about ready to start doing it myself. I think I'm the most active client-side dev, considering the longer term. According to berlios, the CVS commit ability belongs to:drakos7 grum lachesis learner n0nane raduprv rei torg_el ttlanhil vegar xaphier Grum and Vegar have done a bit lately, but haven't been (re)active for as long as they used to. Karenrei seems to be doing some map editor work, but isn't too active on the client (and is one of the newer people). You're a little bit newer as well, IIRC, though you've recently been active also. Learner mostly works on the server and his own projects (ie ants). Same for radu. 0ctane/n0nane is mostly busy trying to fix for OSX all the things the rest of us break. and Xaphier has been quiet for quite a while, and is now adding a heap of sometimes broken code to CVS. If it's what it takes to clean up CVS, I'm willing to get yelled at and have to revert some changes. But hopefully the cleanup will actually happen soon as an organised group effort. ----- As far as CVS, the default FEATURE set should now compile for anyone not using MSVC, I expect Torg will be finishing that soon. Currently I'm going through the FEATURE list and testing (individually, the combinations of features would be too massive) those that I think actually should be on the list (NEW_FILE_IO should. Some of the old broken ones should not). That only goes for actual FEATURES ones, the platform and 32/64 bit ones I can't really test too well

Some of the errors below should have been fixed by other coders. Torg is going to look at the sound code. I'll do a mass-semi-fix for the rest. Semi fix? Well, it'll compile again, at least for me, but the original authors of the code will have to un-semi-break it in order to use those features. Personally, if CVS doesn't compile, then new features can go jump in the lake (no matter how shiny the water gets. Nifty water is one of the things Xaphier has been doing. And the new FEATURES not getting commented out is also his doing. Just so Learner knows who to yell at ) My mass-semi-fix may make the code slightly slower or use more memory. It is not intended to be permenant, just enough so that people can use it and fix it. I'll post again when I'm done. NEW_FILE_IO should be reasonably stable now, I've been doing work on it and have been trying to get people to test. But I know there were problems with it earlier. USE_SHADER is new as of a few hours ago. So's USE_TR1, which is even worse, since the TR1 is about experimental support for the next standard of C++... ie you can expect to not have it. Testing with all option combinations is simply not possible. There are too many. However, yes, a compile and run with a toggle for the features that it touches on is good (or worse yet, when you see really obvious errors in someone's code that show they didn't even test with the FEATURE they added the check for).Yes, new features should be commented. I can only think of one person who hasn't done that recently, most coders seem to be reasonably good at testing. Most of the larger changes also have the threads in forums... sometimes so do the smaller changes. Lets first get the list of FEATURES down. That was supposed to have happened already. Now is the time to do that, since it makes development and testing for the next version easier.IIRC, Ent said we'd have a major cleanup in CVS after the last update... I'm still waiting to see this, as everyone seems to be in feature mode (including myself, to a degree, although what I'm doing is mostly like Torg, fixing up or finishing other work)

"It's not realistic!" ... Puhlease. There are satellites and a GUT book in the Portland library. Don't suggest that it has to be believable to be in EL, because it doesn't. A good storyline and set of quests comes second to providing 'cool' features. Ent's blog has said that he believes more players want new stuff than quests. (Possibly true on average for the current denizens of EL, but certainly not true for all, I know. Of course, that doesn't consider how many more people EL might get/keep if story/quests were worked on, or if there might actually be interest in RP were the story side not a second rate dept. (Sorry to the people who have been working on storylines/quests, I don't mean any offence to you, but I was there too, for a while.))

Please don't use colours. If you must, use them properly, like to highlight one word. In a colour that isn't hard to read. Which yours is. The rules about not overusing colours and fonts and sizes are there for a reason.

Well, there weren't, so I did. Now to wait for people who use the latest code without getting involved in threads like this to find obscure errors and report them Apart from adding the ability to set configdir at compile, I haven't changed it. The TODO list above still stands. But I'd rather not keep updating vs CVS when people change stuff Please do test it further, and report (or fix!) any problems.

Uhm, you're OSX, right? Nudge Grum, he's been doing the notepad and related stuff recently, and that code should all be #ifdef'd so only linux users (IIRC) get it.

Eww Yay! Because according to the C89 standard, it's not legal to declare variables in amongst your code.In the C99 standard you can, but few compilers fully support it. There's one that I believe does fully support the standard, but I wouldn't be suprised to hear that no other supports it. On the other hand, there are some things (like C++ style comments, // as opposed to C comments, /**/) that are widely supported. Unless you state to the compiler that you with to use the C99 (or GNU99) standard, it should present a warning that your code is not conformant to the spec, and hence less portable Yup, I was mostly just wondering why that wasn't used; whether it was because you didn't see it or because there was some other reason (execution speed? but SDL takes care of portability stuff, which is generally a win) why you didn't use it Fair enough, and the smaller size would make it less visable as well (I wonder, does the same problem exist with the shrunken inv window for small resolutions?) I can imagine double the speed being too much... I was thinking more around 1.5 sec.Still, I'm partial to the idea of it flashing faster at the end, to make it more obvious just how close it is to done.

Perhaps a failure to connect to the server could reset them... If you're only offline for a few seconds then it makes sense to continue, but if you're off for a few hours then it doesn't (at least to me).

Okay, I've been through the code Emajekral sent me a few times; I've fixed some bugs, changed some things around, made it work with NEW_WEATHER, etc. For those who want to test it, see: https://developer.berlios.de/patch/index.ph...p;group_id=1256 That's against current CVS as of about now. You'll also need to extract http://users.on.net/~gingerman/sky_cursor-textures.zip into your datadir/textures folder. To enable first person view (FPV): alt+f To enable mouse-grab: alt+g Note that it's not finished. There are a number of problems; some of which I can fix, and some I can't. Some of them I may have caused myself or may have been caused by the changes to CVS since Emajekral was actively working on this. I've fixed at least one segfault because of such changes. The biggest problem is that this seems to have even more "Ooh, pretty! Okay, Ima sit here and watch and not be productive" factor than perhaps even karenrei's eyecandy. The rooftops in VotD and similar places will probably be crowded for a while as people look for vantage spots to watch the sunrise/sunset. Bugs that I've seen/experienced: - middle-click drag is funky, resetting itself to straight above, etc. - alt+g, mouse-grab, doesn't seem to work correctly ATM. moving the mouse does move the view, but the mouse can leave the window. I can probably fix this with a few hours work, though. - character slide, when the camera is moving. Not sure why. - position of camera on mapload isn't where we start; and it shouldn't pan to the player on map entry. - clouds, stars & sun go from north to south. funky. - you can see parts of yourself when spinning the camera in FPV. Possibly because I was sitting, and an attempt to turn fails when sitting. Oh well. maybe we should hide the player's actor in FPV TODOs and related issues: - the lightning is seen on clouds (at least in -DNEW_WEATHER, where the flash is more noticeable), which isn't really going to be correct. - the shadow system in EL only works for a certain distance; after that the shadows look funky. The new view here will make players more likely to be looking long distances, so it is becoming more of a problem. - actor animations, when viewed from a low angle (such as horizontal) seem a lot more robotic, no bounce, etc. - again with being able to see further, you can see when actors disappear. It might work okay if we alpha blend people out at a certain distance, because currently they just pop in/out on actor add/remove from the server. And possibly other issues I haven't found yet. Please test and report bugs... Even better, provide fixes ed: Meh, wrong thread, I should have posted on the original thread. Oh well, it's close to being the right one

Assuming dev-cpp isn't completely different (I haven't used it, but what I've heard suggests that it's not too different); edit make.conf and either add or remove the octothorpe (#) in front of ALUT_WAV

Note on the sound errors, people who get an error there when the compile is otherwise correct (including link instructions) should try to toggle ALUT_WAV; as this define changes the way WAV files are loaded and OpenAL is initialised.

Okay, well, unless someone else is working on this already, I'll have a go at it. The alt+d thing, that is. Unlike Learner's exclamation marks, I don't see windows being open above the map as that big a problem.

I don't mean that much faster, but as it is now, it's not that noticeable (An increase in the range of colours would do the same thing to make it more visible). And yes, that may be a good thing; but then why make it change colour at all?

Okay, I've just tried it out, and I have a few comments - Please don't declare your variables in the middle of a block of code (MSVC won't allow it. gcc should give you a warning). - Is gettimeofday() needed? Would SDL_GetTicks() (which returns milliseconds since the program started) suffice instead? - It only does the items in inventory, not quickbar (which may not be a bad thing). - The speed seems to be a little on the slow side, for my tastes... What do you think of it getting a bit faster as it reaches the end (Hey, look, I'm nearly ready!)?

The MP3 file format is patented, and may become public use in 2011 (or it may not), until then you are legally required to have a license to encode MP3 files (and possibly to distribute software/hardware that decodes it). I'm not sure of the exact details, but it's lower quality than ogg/vorbis as well as being licensed. And we already have code to use ogg/vorbis to boot. I suggest you talk to Roja about all this; either before you do much work, or not far into it (if you have a few samples that show the quality, that may help. But Roja may want a different style or whatever, and you don't want to waste a lot of time). It would probably be a good idea to talk to Torg, as well, since he was going to work on the code for more sound effect support and all. Until that's finished and tested we won't have much need for more sound files. As of the last I saw, the next client update is planned to be around Oct., so there isn't a real rush to get the sound files ready ed: For more info on MP3 licensing, see Wikipedia

We won't be using MP3 because of the licensing issues. Currently the sound effects are saved as Wav, but if we're going to have a lot of them, it may be worth looking at Ogg/Vorbis (or even FLAC). For now I'd suggest you just use Wav and you (or someone else, if need be) can convert later.

Heh. As if an admin would use a hotmail account. or ask for your password. Or spam with a copy'n'paste of the rules. No, it's totally bogus. It always is. ed: One thing though, don't delete it yet, if Ent or someone wants to follow it up it may come in handy.

This happens in all inside storages? It's a known problem for PL (not a new one, it has been talked about a few times on the forums before), possibly others... Please post details such as which maps with bug reports

This is true, and it may seem odd; however... There are more recent threads than this one about sounds (and hence are likely to have more relevant and interesting information), and he didn't have anything material to add (someone who can provide the sound files, or volunteer for coding, or anything like that can add important points to the discussion).We only have limited developer time, and as has been stated in other forum posts, sound is being worked on. Apart from TheComet getting bumped, bringing this thread back probably hasn't done much to progress EL. Oh, and to those people (I know it's not everyone, but there are some out there) who think that if they ask for something often enough, they'll get it sooner... No. Asking more often annoys devs and wastes time answering forum posts. If you want something that's already being worked on, let us finish it or offer suggestions/information where appropriate ("We want sound!" isn't. "I think fighting sounds would be okay, but walking would get annoying, so I'd suggest having levels of environmental sound effects" certainly is (though don't suggest this, as that's already on the list ) ). This isn't in any way linked to this thread, any more than it is to other threads about popular development issues. I'm not suggesting it's a comment on the people who have posted here, or those who want sound. I just felt the need to say that, and this was the thread that was open

Considering that messages are capped at 160, which includes the name you're PMing... That's 2 messages worth, right there.

That'd be ttl thenAs far as working on, it was keeping a window above others I was trying to do (I've since changed tack and will do something else in place of that for the minimap).The pin to ignore alt+d was really simple, just another function call to check if the variable is set (or a variable, if you want to think about it like that; I just have functions to grab a bit from an int to save on variables), and if so, refuse to close on the alt+d event (the handler for that). Being able to remember which windows were open when alt+d was pressed should be possible... There are two ways I see this being done: - Make a list of the windows that were opened when you alt+d, and then if none are open when you alt+d, restore that list. We could either do this with a linked list or an array, both of which have advantages and disadvantages. - Some trickery with the existing code/numbers, such as setting a high bit in the display order variables to indicate "this was open". - As an alternative to the above, a new variable used for this (which is possibly a little cleaner, but isn't really necessary and would waste memory).

Fair enough, but with unique items you have to store the properties with the item. Right now, the properties are known per item type outside of the storage list. So even if your suit is one piece, you would still end up needing a lot more space to save storage data.

It sounds nice, but it's completely the opposite of the mass-production scheme currently used in EL. As such, it would likely require huge amounts of reworking code and data files. And of course, each unique item needs its own inventory slot (with a lot more data per slot, so you may end up with 5 slots being taken by each unique item).

That's because you're on Windows, and ELC doesn't get use your home folder to save stuff (it will in the future. And since Vista is finally learing some security from *nix, this may not be just something nice to have, it may be required).