[DGD] LWO

Sun Aug 9 15:03:27 CEST 2015

I noticed 2 bugs in the code I posted (not handling ranges properly when
beginning or end not specified, and not handling the difference between 0 and
nil in the | operator), both fixed.

As to open-sourced libraries for DGD, Iirc Shentino is maintaining an
open-sourced lib (or 2 actually?), and there is klib of course (also
maintained by Shentino nowadays if I'm not mistaken), and Felix maintains a
lib called cloudlib, which is very interesting codewise, but seems rather
incomplete for as far as building a mud goes.

Every so often, when people ask about things, I'll post some examples (if
possible as public domain, so they can be used by everyone without licensing
concerns).

Beyond the things mentioned above, I don't think there is anything
open-sourced that runs on modern versions of DGD and can take advantage of at
least some of the features that make DGD special.

In general, you'll have to make some choices. Current Gurbalib seems to aim at
simplifying the codebase to provide something that is relatively easy to
understand and use, but at the expense of some of the complexity,
infrastructure and restrictions needed to run DGD as a persistent server and
for example support for a verb based user interface.

This doesn't have to be an issue if you want to use it for a classic lpmud
style lib for example, but may be limiting if you aim for a 'new' persistent
mud with a persistent world and managed in-game economy. 

Picking between those 2 styles or consciously deciding on a mix (and on
solutions to the various conflicts this causes) is very important, doing so
much later on will involve lots and lots and lots of extra work, and depending
on the size of your codebase, may not even be a feasable option (trust me on
this one, I went this way with Way of the Force, and it took about half a
decade to find and address the more prominent issues). 

At any rate, Gurbalib is your best starting point when wanting to run
something lpmud alike, and has an active maintainer and a small but active
community, but its not a very good starting point if you aim at something that
isn't very lpmud like. 

Bart.

On Sat, 08 Aug 2015 19:38:53 -0400, Littlefield, Tyler wrote
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> This is cool, thanks. I got what I was trying for working today.
> Are there many different systems open-sourced in LPC? I'd like to see
> how things are done, most especially with DGD.
> 
> Thanks,
> On 8/8/2015 10:19 AM, bart at wotf.org wrote:
> > An example LWO can be found at:
> > 
> > http://wotf.org/downloads/lpc/kvset.c
> > 
> > It should work on gurbalib directly (and with little or no
> > modification on about every other lib).
> > 
> > It implements a variation on the mapping type that adds support for
> > &, | and - operators.
> > 
> > Bart
> > 
> > On Sat, 8 Aug 2015 12:05:05 +0200, bart wrote
> >> Creating an LWO is easy:
> >> 
> >> object src; object lwo;
> >> 
> >> src = find_object( "/path/to/some/object" ); lwo = new_object(
> >> src );
> >> 
> >> lwo will be the lightweight object, src is a blueprint object
> >> used as a template for the lwo.
> >> 
> >> Note that an object does not have to do anything special to be 
> >> usable as lwo, but there are some differences between a clone of
> >> a blueprint object and an lwo:
> >> 
> >> Very important: lightweight objects do not get destructed
> >> explicitly, they simply are forgotten when nothing references
> >> them anymore. This means (very important if you are trying to do
> >> any kind of object management or data storage on destruct) there
> >> will be NO calls to the lwo informing it that it is going to be
> >> destructed. This is a simple fact and not something that you can
> >> code your way around, it is a consequence of the nature of LWOs.
> >> 
> >> LWOs can *NOT* have call_outs. Again, this is a consequence of
> >> the nature of LWOs. Do not use LWOs for code that must use
> >> call_outs or move the call_outs to some other bit of code not in
> >> an LWO.
> >> 
> >> LWOs are kept in the storage space of the object that created
> >> them (did the call to new_object()). ALL the things that apply to
> >> arrays and mappings that are passed by reference from one object
> >> to another also apply to LWOs. This means they will only be
> >> shared until the end of the execution round, after which a copy
> >> will be made and both objects involved will end up having their
> >> own copy of the LWO.  For example, you might want to keep track
> >> of some centralized counter for something. You decide to stick
> >> this in some object, and let everything that needs this counter
> >> call the object. So far so good, and this works with blueprints
> >> (as you can simply use find_obect() and are guaranteed to end up
> >> at that blueprint) or clones (you have to pass the object
> >> reference to code that needs it). Doing this with an LWO however
> >> may or may not work depending on exactly how you implement this:
> >> - pass lwo reference to other object, which uses it to reference
> >> the counter and then forgets it, all in the same execution round:
> >> this works - pass lwo reference to another object which stores it
> >> and then later on (as the result of a call_out or other user
> >> action) tries to use it: this will not work as expected as the
> >> LWO is no longer the one that was stored originally, it is a copy
> >> of it.
> >> 
> >> Also important, LWOs support features that regular clones do not,
> >> especially operator overloading (see the git commit log for dgd,
> >> look for the keyword operator).
> >> 
> >> Anyway, there are things for which LWOs are an absolutely
> >> brilliant solution, things like building advanced data types (for
> >> example mappings that can contain a lot more then 16384 key/value
> >> pairs), but also things for which they are a very cumbersome
> >> solution that is best be avoided.
> >> 
> >> So.. creating them is easy, making good use of them however
> >> requires some more careful thought really, they are not 'just an
> >> alternative for clones', rather, they are something totally
> >> different then clones, and generally things that need clones
> >> cannot easily be done with LWOs and the other way around.
> >> 
> >> Bart.
> >> 
> >> On Sat, 08 Aug 2015 03:33:39 -0400, Littlefield, Tyler wrote
> > Hello all: I've been looking for examples. Is there a syntax for
> > creating an LWO? Any help appreciated. Thanks, - -- Take care, Ty
> > twitter: @sorressean web:http://tysdomain.com pubkey:
> > http://tysdomain.com/files/pubkey.asc
> 
> >>> ____________________________________________ 
> >>> https://mail.dworkin.nl/mailman/listinfo/dgd
> >> 
> >> -- http://www.flickr.com/photos/mrobjective/ 
> >> http://www.om-d.org/
> >> 
> >> ____________________________________________ 
> >> https://mail.dworkin.nl/mailman/listinfo/dgd
> > 
> > 
> > -- http://www.flickr.com/photos/mrobjective/ http://www.om-d.org/
> > 
> > ____________________________________________ 
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> >
> 
> - -- 
> Take care,
> Ty
> twitter: @sorressean
> web:http://tysdomain.com
> pubkey: http://tysdomain.com/files/pubkey.asc
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQEcBAEBAgAGBQJVxpMNAAoJEAdP60+BYxejo5wH/iatnZXyhqU2+p0WbZBnXJWI
> QxOTC35kNHGfQJjd1B/+DZ+WGTeG3lrgJadDHwOu/kPs3fEGZsHvioT0jDxQomnB
> F5aNw3/QT0XCIt0xQ4gjRFbBQ18Q9Ffd22RFriIh9y3EXBSKXwaazx5YD172CRgH
> /jhyxfVIgtjRzs6bgtpkdyUAkivwU7dH3Xkf9AcPf71zHwD36vmJyvQEDhvt+zjU
> 7W+KG5KaO03/pPEqk+YXf4M+etMXcnMVlpZqgYkcqQNmKW2KWa8T5AFkKG/A5Bzj
> abUmxPOT0PV7EIA5HmTEmC8m/okqFkAz4jm6VzVPchOy5a0ZX9SL/ynbyIipsCc=
> =iaK9
> -----END PGP SIGNATURE-----
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd

--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/