Menu
▾
▴
uglycode-coders — UM1 Coders
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(22) |
Dec
(53) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(56) |
Feb
(12) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Peter C. <pet...@ne...> - 2002-01-14 13:10:38
|
> From: J.P. King [mailto:jp...@he...] > > I think the bigger problem is how do we use it? The code wouldn't > > be particularly efficient if every access went to an out-of-process > > call. > > No, it wouldn't. Is this really a problem? Yes. Users have come to expect the site to be fast. > Does this problem outweigh the potential benefits? Yes. Witness the number of times I've seen MUSH databases go tits-up. However, see later. > Yes, although ideally we'd like ways of atomising operations, or > supporting rollback. Quite. [Below] The modern C++ object stores can do transparent, transactional persistence and object caching in-process. If there's a free one, it would certanly be worth investigating. But we shouldn't try to roll our own. - Peter |
|
From: J.P. K. <jp...@he...> - 2002-01-14 12:44:50
|
> I think the bigger problem is how do we use it? The code wouldn't > be particularly efficient if every access went to an out-of-process > call. No, it wouldn't. Is this really a problem? Does this problem outweigh the potential benefits? For example the ability to have the engine crash but the DB stay up, in principle the posibility for the DB to crash, but the game to stay up (long enough for the db to reload). > I suppose if we had a write-through cache it wouldn't be too bad. > At least then we'd get semi-fault tolerant data. There are all sorts of options, although there is still the issue of finding the object store which works for us. > We'd need a decent sanity-checker that could fix problems like the > contents lists being mangled due to a crash whilst moving an object. Yes, although ideally we'd like ways of atomising operations, or supporting rollback. > Adrian. Julian |
|
From: Adrian S. J. <AS...@pa...> - 2002-01-14 12:20:44
|
> From: Peter Crowther [mailto:pet...@ne...] >=20 > > From: J.P. King [mailto:jp...@he...] > > Would it be feasible to create an object store, and detach=20 > > the code engine from the object store engine? >=20 > Yes. >=20 > > I personally am convinced that this would be a technically=20 > good thing > > to do (given an object store), but I don't know how the game engine > > accesses the objects - is it directly, or is there an=20 > interface layer > > which can be mangled? >=20 > The database is an object with operator[] defined,=20 > specifically so that we > could do this. I think the bigger problem is how do we use it? The code wouldn't be particularly efficient if every access went to an out-of-process call. I suppose if we had a write-through cache it wouldn't be too bad. At least then we'd get semi-fault tolerant data. We'd need a decent sanity-checker that could fix problems like the contents lists being mangled due to a crash whilst moving an object. Adrian. |
|
From: Peter C. <pet...@ne...> - 2002-01-14 12:11:28
|
> From: J.P. King [mailto:jp...@he...] > Would it be feasible to create an object store, and detatch > the code engine from the object store engine? Yes. > I personally am convinced that this would be a technically good thing > to do (given an object store), but I don't know how the game engine > accesses the objects - is it directly, or is there an interface layer > which can be mangled? The database is an object with operator[] defined, specifically so that we could do this. - Peter |
|
From: J.P. K. <jp...@he...> - 2002-01-14 12:05:22
|
Question for people who know the current code: Would it be feasible to create an object store, and detatch the code engine from the object store engine? I personally am convinced that this would be a technically good thing to do (given an object store), but I don't know how the game engine accesses the objects - is it directly, or is there an interface layer which can be mangled? I am guessing, based on what I do know of the code, that there is no interface - would there be any objections, in principle, if one were added? I'm not offering to do this just yet, but I am interested in thinking about it. Thoughts, comments welcome, Julian |
|
From: Chisel W. <ch...@he...> - 2002-01-12 04:04:01
|
do we ignore this? :-) -- Chisel Wright (ch...@he...) Typer of code; tearer of hair. |
|
From: ReaperMan <re...@re...> - 2002-01-12 02:25:01
|
--
----------------------------------------------------------------------
re...@re... www.reaperman.org +44 7976 696 407
----------------------------------------------------------------------
|
|
From: J.P. K. <jp...@he...> - 2002-01-04 13:55:32
|
> No, the first parameter shouldn't be there. Ok, well with that change, and so long as I don't use the compilers which come with DeadRat 6.2, it compiles cleanly on all three standard platforms. Hmm, we're getting a MacOS X box soon, must port it to that too, should be fairly easy. > Adrian. Julian |
|
From: Adrian S. J. <AS...@pa...> - 2002-01-04 13:15:11
|
> From: J.P. King [mailto:jp...@he...] >=20 > Found a moment to test the cross platform compilation, and I think > there is a small problem: >=20 > (modified layout of) line 2779 in interface.c: >=20 > snprintf (wizard_string, sizeof(wizard_string), > " has been created from %s]\n", > db[get_player()].get_name ().c_str(), > hostname); >=20 > there is one %s but two parameters. I suspect that the first=20 > parameter > shouldn't be there, but it isn't my code. :-) No, the first parameter shouldn't be there. Fixed in CVS, but I'm not going to make a new release over that just yet... > Julian Adrian. |
|
From: J.P. K. <jp...@he...> - 2002-01-04 13:10:19
|
> Since nobody has found anything wrong with the test code, I'm
> going to commit the changes I've made and tag it as release
> um1_015
>
Found a moment to test the cross platform compilation, and I think
there is a small problem:
(modified layout of) line 2779 in interface.c:
snprintf (wizard_string, sizeof(wizard_string),
" has been created from %s]\n",
db[get_player()].get_name ().c_str(),
hostname);
there is one %s but two parameters. I suspect that the first parameter
shouldn't be there, but it isn't my code. :-)
> Adrian St. John
Julian
|
|
From: Adrian S. J. <AS...@pa...> - 2002-01-04 12:57:21
|
Since nobody has found anything wrong with the test code, I'm going to commit the changes I've made and tag it as release um1_015 Changes: * context::do_HARDCODE_COMMAND now takes 2 CString's instead of const char* * CString & String have been tightened up so that the compiler doesn't try to second guess what we mean when we use them incorrectly. i.e. operator=3D is now defined for all the types it should be operator int() is private (to catch comparison with NULL) * All the code that I moved over to CString and String before that was potentially using the classes in a dodgy manner has been fixed. I think that is all. -- Adrian St. John Software Engineer Pan Security International Ltd. T 0121 780 0619 as...@pa... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Pan Security International Limited, Vienna House, International Square, = Birmingham International Park, Bickenhill Lane, Solihull B37 7GN United = Kingdom. Registered company number 3965174=20 This message may contain information which is confidential and subject = to legal privilege. If you are not the intended recipient, you may not = peruse, use, disseminate, distribute or copy this message. If you have = received this message in error, please notify the sender immediately by = e-mail, facsimile or telephone and return and/or destroy the original = message. Pan Security International Limited accept no responsibility for = any changes made to this message after it has been sent by the original = author. |
|
From: Chisel W. <ch...@he...> - 2002-01-04 09:36:27
|
On Thu, Jan 03, 2002 at 08:12:45PM +0000, Chisel Wright wrote: > Tarka's seems to be random; different colours for same leves of admin: Cheers to Grim for pointing this one out: @listcolour tarka = players Player Set colour(s) --------- ------------- moves abstract Yellow, Highlight chocolate moonunit Green, Highlight Korridor Kyris Magenta, Highlight Barny K Green Taly Magenta Luggage Blue, Highlight Quinny Red, Highlight Russ Green, Undefined Mutley Brandybuck Red In Da Corner Dragor Green Rincewind Red, Highlight Can anyone spot a connection with her 'random' colours? -- Chisel Wright (ch...@he...) Typer of code; tearer of hair. |
|
From: Adrian S. J. <AS...@pa...> - 2002-01-04 09:35:20
|
> From: Chisel Wright [mailto:ch...@he...] >=20 > Tarka keeps mentioning this; fifi has mubled something about=20 > colours, but > isn't as helpful as Tarka. >=20 <SNIP LOTS> >=20 > Player-Specific colours aren't listed; maybe for debugging we could > add "@listcolour <player> =3D all". @listcolour <victim> =3D players is already in the code > Any ideas on why this seems so random? It's not a big deal to me, > but it does cause confusion for others. As I pointed out, it is so random because Tarka has player colours set up for the mentioned Wizards. Adrian. |
|
From: Chisel W. <ch...@he...> - 2002-01-03 20:15:34
|
Tarka keeps mentioning this; fifi has mubled something about colours, but isn't as helpful as Tarka. Omally: http://www.herlpacker.co.uk/images/connect_colours.jpg Tarka: http://www.herlpacker.co.uk/images/tarka-colour.jpg Tarka's seems to be random; different colours for same leves of admin: ex *mutley Owner: Mutley Brandybuck(#43877 PBC#LWX); Key: Mutley Brandybuck(#43877 PBC#LWX); Flags: Builder Colour Fchat LineNumbers Listen Wizard XBuilder Male Referenced Coloured Items? Wizard, XBuilder ex *rincewind Owner: Rincewind(#49664 PBC#LwW); Key: *UNLOCKED*; Flags: Builder Colour Fchat LineNumbers Listen Prettylook Welcomer Wizard Male Referenced Coloured Items? Wizard, Welcomer ex *dragor Owner: In Da Corner Dragor(#47059 PBC#LW); Key: *UNLOCKED*; Flags: Builder Colour Host LineNumbers Listen Wizard Male Referenced Coloured Items? Wizard ex *omally Owner: Day2 Omally(#24235 PABC#LwW); Key: Day2 Omally(#24235 PABC#LwW); Flags: Apprentice Builder Colour Connected LineNumbers Listen Prettylook Welcomer Wizard Male Referenced Coloured Items? Wizard, Apprentice, Welcomer @listcolour Tarka Attribute Set colour(s) --------- ------------- TellMessages Yellow NatterTitles Highlight, Green Apprentices Revert, Green Builders White, Highlight XBuilders Red Welcomers Magenta ChannelNames Flashing, Highlight, Red Tells Cyan @listcolour Omally Attribute Set colour(s) --------- ------------- Commands Revert Shouts Revert, Back Red, Yellow Natters Green NatterTitles Revert, Yellow God Cyan Descriptions White ChannelNames Highlight, Red ChannelMessages Cyan Player-Specific colours aren't listed; maybe for debugging we could add "@listcolour <player> = all". Any ideas on why this seems so random? It's not a big deal to me, but it does cause confusion for others. Chiz -- Chisel Wright (ch...@he...) Typer of code; tearer of hair. |
|
From: Peter C. <pet...@ne...> - 2002-01-03 10:24:09
|
> From: Adrian St. John [mailto:AS...@pa...] > 1. Anyone mind if I strip out the concentrator code from the source? As long as we still have a version with it in, yes --- it's an interesting fossil. > 2. Anyone mind if I put support in for handling multiple ports? Go for it. We might want to alter the syntax for starting the driver so that it can take multiple -p/--port arguments; this might also be a good time to change the argument parsing so that everything is prefixed rather than positional. The configuration is beginning to be sufficiently complex that we should probably also add a config file reader sometime soon. Anyone got any recommendations? - Peter |
|
From: Adrian S. J. <AS...@pa...> - 2002-01-03 10:19:07
|
Couple of questions: 1. Anyone mind if I strip out the concentrator code from the source? I seem to remember we never got it working properly, and it hasn't been maintained in any way since we moved to wyrm. 2. Anyone mind if I put support in for handling multiple ports? Julian's suggestion on the admin list (which I thought was the most appropriate place to ask in the first place) was that rather than just supporting 6239 and the telnet port (23), that we could have an arbitrary number of ports open. Adrian. -- Adrian St. John Software Engineer Pan Security International Ltd. T 0121 780 0619 as...@pa... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Pan Security International Limited, Vienna House, International Square, = Birmingham International Park, Bickenhill Lane, Solihull B37 7GN United = Kingdom. Registered company number 3965174=20 This message may contain information which is confidential and subject = to legal privilege. If you are not the intended recipient, you may not = peruse, use, disseminate, distribute or copy this message. If you have = received this message in error, please notify the sender immediately by = e-mail, facsimile or telephone and return and/or destroy the original = message. Pan Security International Limited accept no responsibility for = any changes made to this message after it has been sent by the original = author. |
|
From: Adrian S. J. <AS...@pa...> - 2002-01-02 16:02:46
|
> From: Peter Crowther [mailto:pet...@ne...] First off, I apologise for quoting a private mail back to a 'public' list, but since it is a single line, I though that Peter wouldn't mind too much... >=20 > > From: Adrian St. John [mailto:AS...@pa...] > > The features: > > * Has more features than version um1_010 >=20 > Er... right. >=20 > - Peter >=20 Ah. Thats right, I was forgetting that I hadn't sent out updates on what release um1_011, um1_012 and um1_013 do. um1_011: * Chat code overhauled. There was much joy, and some gnashing of teeth. um1_012: * [foo has connected] overhauled, with pretty colours (tm). * @rem added to the hardcode, because calling a softcode command to do nothing is stupid. um1_013: * First bug-fix for the overhauled chat code. It lasted a whole minute before I triggered a totally unrelated bug in another piece of code not a million miles from the bug. * Version string is now dump to stderr instead of stdout so that the = logs include it. um1_014: * Fixing the bug I triggered in the chat code. |
|
From: Adrian S. J. <AS...@pa...> - 2002-01-02 15:52:32
|
After much wailing and crashing and being lost in the wilderness for 40 hours (or so), I am please to announce the release of version um1_014. The features: * Crashes less than versions um1_011, um1_012, um1_013. * Has more features than version um1_010 * Less likely to hang than version um1_010 And thats about it. On the 'convert all char* to String' front, I'm about to start another test engine on port 9999 for people to test. Please do so. Adrian. -- Adrian St. John Software Engineer Pan Security International Ltd. T 0121 780 0619 as...@pa... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Pan Security International Limited, Vienna House, International Square, = Birmingham International Park, Bickenhill Lane, Solihull B37 7GN United = Kingdom. Registered company number 3965174=20 This message may contain information which is confidential and subject = to legal privilege. If you are not the intended recipient, you may not = peruse, use, disseminate, distribute or copy this message. If you have = received this message in error, please notify the sender immediately by = e-mail, facsimile or telephone and return and/or destroy the original = message. Pan Security International Limited accept no responsibility for = any changes made to this message after it has been sent by the original = author. |
|
From: Adrian S. J. <AS...@pa...> - 2001-12-21 13:49:03
|
Ok, I've fixed a few bugs that I accidentally put in with the code. It appears to be stable, but I'm going to leave the test database running until Thursday (27th December) before I commit the code. Please try and find problems before then. Adrian. -- Adrian St. John Software Engineer Pan Security International Ltd. T 0121 780 0619 as...@pa... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Pan Security International Limited, Vienna House, International Square, = Birmingham International Park, Bickenhill Lane, Solihull B37 7GN United = Kingdom. Registered company number 3965174=20 This message may contain information which is confidential and subject = to legal privilege. If you are not the intended recipient, you may not = peruse, use, disseminate, distribute or copy this message. If you have = received this message in error, please notify the sender immediately by = e-mail, facsimile or telephone and return and/or destroy the original = message. Pan Security International Limited accept no responsibility for = any changes made to this message after it has been sent by the original = author. |
|
From: Peter C. <pet...@ne...> - 2001-12-18 09:55:06
|
> From: Adrian St. John [mailto:AS...@pa...] > If you *INSERT* a line, it doesn't flush the cache. D'oh! > I think I've fixed it now. I've also cleaned up the If_scope > parser so that it doesn't know about BACKWARDS commands any more, > and when you try to use a BACKWARDS command you'll be told it > can't be used and must be updated. Sounds good. - Peter |
|
From: Adrian S. J. <AS...@pa...> - 2001-12-17 14:14:13
|
Ok, I think I've found the problem. When you run a command for the first time, it creates a cache of where the @if/@elseif/@else/@endif/@for/@with/@end lines are. If you re-describe the command, it flushes the cache. If you re-describe a line, it flushes the cache. If you *INSERT* a line, it doesn't flush the cache. I think I've fixed it now. I've also cleaned up the If_scope parser so that it doesn't know about BACKWARDS commands any more, and when you try to use a BACKWARDS command you'll be told it can't be used and must be updated. Adrian. |
|
From: John A. <jo...@sp...> - 2001-12-13 16:14:42
|
On 2001-12-13 at 15:37:06, Adrian St. John warbled:
> Apart from Splange, everyone seems either happy of indifferent to the
> change, so I'm going to commit the code tomorrow morning.
I didn't say I was happy or unhappy with it. I think everyone knows my
opinions by now; don't put words in my mouth (it's already full of them).
You should work on what you want to work on, and do what you think is
right. That's all I do, and all I can ask of anyone else.
--
"I wrote a few children's books... not on purpose."
- Steven Wright
_________________________________________________________________
I prefer encrypted mail (see headers for PGP key)
Why encrypt? http://www.heureka.clara.net/sunrise/pgpwhy.htm
_________________________________________________________________
|
|
From: Peter C. <pet...@ne...> - 2001-12-13 15:40:47
|
> From: Adrian St. John [mailto:AS...@pa...] > I know that splange is unhappy about any work done to get the chat > stuff working better than before. I appreciate that he wants to > make the game a more lively place, but on the other hand I am just > trying to keep what we've got working. Quite. A relatively crash-free game (as it has been at various points through its life) will retain more users than one that doesn't work, almost (note *almost*) no matter what its feature set. - Peter |
|
From: Adrian S. J. <AS...@pa...> - 2001-12-13 15:36:19
|
> From: Adrian St. John=20 >=20 > Ok, after a bit of work, I've cleaned up the chat code a bit. Apart from Splange, everyone seems either happy of indifferent to the change, so I'm going to commit the code tomorrow morning. One addition that has been made is that a channel can now be set 'censored', which goes through the normal censoring code. Any comments, requests, flames? I know that splange is unhappy about any work done to get the chat stuff working better than before. I appreciate that he wants to make the game a more lively place, but on the other hand I am just trying to keep what we've got working. BTW for those who are curious, my next task is to convert context to use CString/String for the implementation of the hardcode commands. Fun! Adrian. |
|
From: Peter C. <pet...@ne...> - 2001-12-13 12:57:54
|
> From: J.P. King [mailto:jp...@he...] > Tested, not really understood, but implemented cos it blatantly > works. Changes committed. It's a gross hack to trick the compiler into discarding a const without giving a warning. Nothing more, nothing less. The fact that we have to use it at all is worrying, but that's up to the library implementors. - Peter |
