Basicly, the primitive would copy the properties and all
sub-properties from the specified propdir on one object
into the specified propdir on another object.
I'd suggest something like:
copyprops ( d1 s1 d2 s2 i1 -- i2 )
d1 - Source object
s1 - Source prop(dir)
d2 - Dest object
s2 - Dest prop(dir)
i1 - If 1, recurse into propdirs. If 0, don't recurse.
i2 - Number of properties copied
An example use would be:
#100 "/_godprops/" #1 "/" 1 copyprops pop
Logged In: YES
user_id=340748
Blah, I forgot to log in before submitting. This was mine, by
the way.
Logged In: YES
user_id=42132
Hmn... Is there inherent advantage of doing it in-server
verses via MUF? It's not -that- complicated of a MUF routine
to copy props, and with MUF, it's guarenteed not to hang the
server while copying 1000's of props like it could in-server.
Considering all the permissions checks something like this
entails (Just look at your typical copy-props MUF program to
see what I mean), this would be a more complicated C
function to write than it may initially seem.
Not certain, but I don't think I'll write this prim myself. I have
no problem with someone else taking care of this though.
-Akari
Logged In: YES
user_id=340748
Mainly, I believe in doing as much as possible in-server. MUF
isn't very efficient when it comes to resource-intensive tasks,
not as efficient as it would be to do it directly in C, since not
only do you have to do everything in MUF that you would have
to in C, but the MUF compiler/interpreter adds work as well,
plus, it makes the user's program either larger, or rely on a
seperate library program (I despise libraries to no end), which
adds even more inefficiency (instructions to load the library
program, instructions to jump to the function in the library
program, etc).
If somebody could explain how the properties stuff works, I'd
do this (been trying forever, but have no clue where to start).
Logged In: YES
user_id=42132
In adding the @clone command to Fb6, they also added an
internal prop-copying function that might be of use for you in
trying to make a copyprop prim. The new function can be
found at:
http://cvs.sourceforge.net/cgi-
bin/viewcvs.cgi/fbmuck/fbmuck/src/create.c.diff?
r1=1.11&r2=1.12
I don't plan on adding an in-server @clone command,
personally, so I don't think I grabbed those functions the last
time I was playing catch-up with FB6.
-Akari
Logged In: YES
user_id=340748
I went ahead and wrote the primitive and implemented it in
p_props.c and inc/p_props.h on the CVS. Test it and look it
over and let me know what you think, and I'll add the
manpage and close this feature request if you appove.
I've attached the proposed manual page, SourceForge has a
bad habit of stripping formatting.
Proposed manual page
Logged In: YES
user_id=42132
Looks good.
Maybe while we're at it we can add a moveprops prim that
works just the same except that it removes the props from
the original object as it copies them.
Could add another bool parameter to the copy_props()
function that tells it to remove the props after it copies them, I
think, and then write a moveprops that would look pretty
much like the copyprops prim, other than the different bool
sent to copy_props().
Just a thought. :)
Otherwise, it looks good. Don't worry about updating the
man.txt, I usually keep that up on my home computer, since
I'm always doing little corrections and updates to it. I'll add
the entry that you attached.
-Akari
Logged In: YES
user_id=340748
Good idea, I'll work on that next.
I fixed a small bug I had missed before I uploaded it earlier.
Mainly, it was skipping sub-properties of propdirs with values,
but it works alright now.
And so that's why the manual on the CVS is never up-to-
date...
Logged In: YES
user_id=463729
@set #0=_defs/moveprops:5 pick -4 rotate 5 pick -4 rotate
copyprops pop remove_prop
??
Logged In: YES
user_id=463729
@set #0=_defs/moveprops:5 pick -4 rotate 5 pick -4 rotate
copyprops pop remove_prop
??