bluap

I can easily change the client to reflect that. Any opinion on the user interface I've produced? Oh yes, one thing to mention is that the server message you get when you successfully make some items always says you made one item. Can that be updated on the server end?

Looks like interest is waning but I've worked some more on this and have a, hopefully, "best of both worlds" version for you to consider. Here's the screen-shot. This version includes the spin box to allow you to set the quantity to make, but also includes minimum "<" and maximum ">" quantity buttons which set the amount to 1 or 9999. The spin box value now also decreases as you manufacture items. This allows you to easily resume making the number of items you want, if you stop manufacturing for any reason. I've also tried to minimise the window space used. Setting the number via an inventory-like quantity widget would not allow you to resume making the number you need. Therefore, I think this method is better and is a simpler change too. So what does everyone think?

I've just had a look at reusing the inventory quantity selector (I didn't know you could change the quantities ). Anyway, the selector stuff is a bit tied in with the rest of the inventory window code and will take a bit of refactoring to before it can be used. That's fine, I game to try but its probably only worth doing if that's really the way people want this to work. I must admit to preferring the checkbox version myself. The spin box is OK but a bit overkill really. I'll post a screen shot of the checkbox version later. Here's the screenshot.

I've just been trying out an alternative control. Instead of a spin box to set the quantity, I have a check box to enable manufacture of multiple items. If it is not checked, only one item is made. If it is checked, manufacture continues until one of the stop conditions occurs or you press the mix button again. This is similar to what The_Piper suggested with the added option to make just one item. It still uses the new server addition but just sets the number of items to either one (uncheck), or something large (checked). I'll try to make the mix button change to stop or some such. It's still a very simple client change. Any views?

May be so. However, what if you wanted to make different items that use the same ingredients. A contrived example would be three iron bar followed by three steel bar, you'd have to be careful to stop at the right time. The code change I've tried was rather trivial (just adding a couple of lines) as all the clever stuff is already available in the spin widget (nice work who ever did that). In use it feels quite natural.

Really nice to have this feature If no one else is picking this up I'd be happy to give it a go. I've already had a quick play and its working fine. Just needs to be tidied up and tested a bit more. Here's a screen shot. Let me know if you want me to do a proper patch. Suggestions for where on the window, the label, max number of items etc obviously welcome.

OK. I've updated the patch anyway. Moved string_contains_substr() to asc.c as suggested by crusadingknight.

strstr() was all that was needed until I did the case insensive bit. Also, I was thinking of adding some regex type options into string_contains_substr() but decided against it. I have checked asc.c now and agree it should go there. I probably could use get_string_occurance() but its doing other things with space and equals and looks more compex than I need; I'd rather keep string_contains_substr() if thats OK. Should I move the function and update the patch?

I did wonder if there was a general function kind of module. If you want I'll move it. I can check the other function in case I can use that.

Now you make me feel like I've beaten you into submission Anyway, we have a consenus. I've not contributed a patch before but I have read the pinned message so I guess I just sumbit it to berlios and hope for the best. Thanks to everyone for the lively debate and support (Patch #1567 submitted to berlios)

Yes it's case insensitive, its the catch all way and I didn't think this type of function would benefit from a case sensitive match - it would just be confusing when things didn't match. Yes, exactly as I was considering. I have also considered "fruit|veg" to match marks containing either "fruit" or "veg" substrings. Along with "fruit&veg" for the "and" case. Also matching the end of the string with "$". The only thing stopping me pursuing this is the added user complexity. What if you want to search for "$$", you would need to delimit. The actual code change is very small though I had to impliment my own case insensive code which could be reused. I quite like to sound of working on a search function for the chat log. May be if this patch gets accepted...

That is how it works currently. However, next typing "e" would leave you with just Red Snapdragons, Red Roses and Tree Mushrooms. Next typing "d" would leave you just Red Snapdragons and Red Roses. etc. The big advantage to my mind is that this way, "Fruit and red roses" will still get matched with a filter of say "red r". Even the initial "r" search helps see what you're looking for. Just cutting down the clutter on some of my maps would allow me to see what I need even if many unrequired marks are still visible. Indeed I do This debate is rather fun, its great to see how different people view such a simple function. That's exactly how it works.

Thanks everyone for the feedback. However, I've just checked several editors and the Firefox browser and none of them only match words starting with the search string. They all behaviour as I have stated so I'm assuming I have misunderstood what's being said here. Or you have all misunderstood what I have explained. Either is likely as, although English is my first (and only language), I'm not too good at it. In use, the way I have it currently coded works really well and is very intuitive - I think. So let me try to check what you're saying. Paste the above first paragraph into your favourite text editor. Then search for the string "he". If I understand what you're preferring, the one and only match will be the start of the word "here", in the third sentence. That's not how the text editor I use works - it matches the end of the first "the". If you type another letter into the search string, making it "her", then sure enough only the word "here" matches. At the end of the day, I'd really like to get this patch accepted. If I have to make it work in this (to me) odd way, so be it.

If I have understood you correctly, then sunflower would not match when you start by typing an "f". Well, that would be an easy change but I prefer it matching anywhere in the text. This way it behavours more like a filter (as intended). As you type more letters, it quickly resolves to what you're after. Also, this way, you can find mark text like "veg & fruit" not just "fruit". Another option would be to have a start anchor such as "^" so "^f" would match only text starting with "f", typing just "f" would match any mark text containing an "f".

I do now With the filter active and the letter "f" typed. Then typing the rest of the word fruit.

Looks like ttlanhil has helped you sort things out. In case you didn't know, there's a Linux guild for the game if you fancy mixing with like minded folks. We have a forum website too which includes a help section. You can subscribe and make use of the forum even if you don't want to join the guild. Enjoy the game!

Yes, you're now going to tell me you can already do this I presume.

Are you using Xgl? I had many problems with that on Ubuntu. Also have you seen this thread which appears to be a similar problem?

Try turning sound and music off then on again in the config window, should save exitting.

I've just checked and that version is the stable Debian version (as from the sound of it you know, stable/testing/unstable can be mixed due to the excellent dependency/package management of Debian). It includes the alut headers and Makefile.linux does not link against alut so I guess its all included in the openal library I'm using. The testing package version for openal is 1:0.0.8-1 so I don't easily have a choice of a 2005 version. But anyway, like you said, I doubt this is the problem.

I didn't have the problem and after the patch, still don't. Works for me. I'm using Debian GNU/Linux with nvidia drivers (1.0.8762-2).

Debian operate several repositories for packages, stable/testing/unstable/experimental. Testing/unstable is just a bit more cutting edge than stable. Debian is very conservative with new versions of packages, testing/unstable is actually very stable and more like you'd get with any latest version of a particular distro like the latest release of Ubuntu. My system is not unstable by nature or by the versions of packages I'm using.

GNU/Linux Debian testing/unstable. libopenal-dev & libopenal0 version 0.2004090900-1. Yes, the CVS version now includes the changes I suggested. This does allow you to toggle the music option on/off. For the non-NEW_SOUND build this works fine, just like before your NEW_SOUND commit. When I applied your additional changes the non-NEW_SOUND build works up until you exit when it hangs. For the NEW_SOUND build, the sound effects work and you can toggle the music option, but no music ever plays. I am not sure what I was going when this build hung sorry. I'll try to collect more information when I have time. The CVS version is looking good, for me at least, without the NEW_SOUND define. My only concern is that the original commit of d000hg's NEW_SOUND changes disabled the LOCK_SOUND_LIST() and UNLOCK_SOUND_LIST() macros in sound.c. This does not appear to be a problem but I can't help wondering why it was disabled and if they should not be restored. May be the original author might be able to help... I'll do some testing with them enabled anyway.

If built from CVS then yes, for me, the non-NEW_SOUND build is completely fine. I tried patching in your changes posted above with a non-NEW_SOUND build. These also work OK but I get a complete hang on exit. This may be a mutex problem, I have not investiagted it yet. However, I could not apply the patch automatically having already updated to a newer version from CVS so I may have messed up somewhere (I've checked several times though). I still have many problems when built with NEW_SOUND, even with your changes posted above. The sound effects work most of the time but I get quite a bit of lag and have had a complete hang. Most significantly, I cannot get any music to play at all. If you want my opinion, leave sound in CVS unchanged until the update has been done. Just my humble opinion though.

Thanks folks, the latest CVS version now works fine for me when compiled without the NEW_SOUND option. I hope that is the same experience as Roja noted. I have not yet retried with NEW_SOUND enabled. (My Internet connection was down all day yesterday along with my TV due to a severed cable). I'll have a go tonight.