This is something I've figured out and want to share, if others haven't yet figured it out (no obvious posts came up about it from a search on 'return type').
(These are with BYOND 4.0 version 420.986)
I read some posts before making this which indicated that there was no way (and never would be any way) to specify the return type of a proc, or to make it possible to do things with the return value of one. However, there are some things that work, like, for instance, << when the proc returns a mob.
Another:
If we have client.screen -= or += stuff, we can try to replace it with something like foo.client.screenOrBackup() -= or +=, but the DM compiler throws a fit about that. If we put parens around (foo.client.screenOrBackup()) it compiles fine, however. (The error was 'cannot assign a proc!')
Example:
(src.client.screenOrBackup()) -= src.contents
For this example, screenOrBackup is a proc that always returns a list:
/client/proc/screenOrBackup()
if (src.mob!=null)
if (src.mob.currentDrone!=null)
return src.mob.currentDrone:savedDroneIcons
return screen
(In the code that was pasted from, savedDroneIcons is never null if currentDrone is non-null)
The other thing was << on mobs:
someMob.client_mob() << "some text here"
or
user.client_mob() << browse(dat, "window=radio")
It's probably important that client_mob() and screenOrBackup() never return null, hmm?
Edit: Unfortunately, although the += and -= appeared to be valid at first - the first error in the list of compiling errors had vanished after I added the () - once I had converted the other 80-or-so instances of it to having ()s, they all had errors again.
ID:133561
 Jun 4 2008, 5:12 am (Edited on Jun 4 2008, 7:21 am)
|
|
Trafalgar wrote:
This is something I've figured out and want to share, if others haven't yet figured it out (no obvious posts came up about it from a search on 'return type'). I see what you're getting at, and it makes some sense. The problem, to put it in C terminology, is that BYOND is treating the results of the proc as an Rvalue instead of an Lvalue. If it accepts this syntax as valid, though, it can merely throw a runtime error if the left side is not in fact a list or a var reference or some such. Unfortunately I don't think this would be such an easy change. On the bright side, it's easy to work around. var/list/L = client.screenOrBackup() Lummox JR | |
Alas, it appeared to actually be working for += and -= (the first error of it went away when I added the ()s), but after I changed all of them to having ()s, the errors had come back. Hm.
Yeah. For working around it, though, I've got 81 lines to change to whatever I use as the workaround. Ideally I'd like to not have to change it from one line to two in any of those, since that would make it easier to replace them all. So now I'm thinking I could just make two procs on client called screenOrBackupAdd and screenOrBackupRemove, and have those do that. Then I would be able to mass-replace src.client.screen += stuff with src.client.screenOrBackupAdd(stuff), etc. | |
Falacy wrote:
I'm not sure exactly what youre trying to accomplish here, mainly due to the fact that the "screenOrBackup" makes no sense to me. But you could always just do something like proc/ScreenAdd(whatever) and then have the proc itself take care of adding to the screen... In short, I've been making something that allows players to take control of a remote mob and move it around without changing the client's mob or the mobs' client. Movement, clicks, topics, etc, are all being forwarded properly already. ScreenOrBackup only returns screen if the client is not controlling a remote mob. When the player takes control of a remote mob, their current screen contents are stored in a backup, which later gets restored when they release or lose control. The purpose of ScreenOrBackup is to return the backup if the player is controlling a mob, allowing things which change the appearance of the player's original mob to continue to work without causing equipped junk to reappear on their HUD. The client_mob() << stuff is also related to this. It's a proc on mobs. If the player's mob (let's call it "Foo") is controlling another mob (let's call it "Bar"), then: Foo.client_mob() returns Foo. Bar.client_mob() returns Foo. If Bar is not being controlled by anyone, Bar.client_mob() returns Bar. Essentially, it ensures that if a controlled can see/hear an event, or receive a dialog, it is passed to the client's actual mob so it sees them. Perhaps changing their client and using Login/Logout stuff is a better way of handling this, but I figured I'd try this first since it shouldn't screw up the code which counts how many players are still alive, and other similar things. | |
Trafalgar wrote:
Ideally I'd like to not have to change it from one line to two in any of those, since that would make it easier to replace them all. So now I'm thinking I could just make two procs on client called screenOrBackupAdd and screenOrBackupRemove, and have those do that. Then I would be able to mass-replace src.client.screen += stuff with src.client.screenOrBackupAdd(stuff), etc. That sounds like a good idea. I'd probably simplify the name though. If you use "screenOrBackup" a lot, I'd just say "screen". If that causes some confusion with cases where the backup isn't involved, I'd just use a new term like "screenbuf" or such. Overcomplexified proc names have a tendency to Microsoft you to death. Lummox JR | |
I'm not sure exactly what youre trying to accomplish here, mainly due to the fact that the "screenOrBackup" makes no sense to me. But you could always just do something like proc/ScreenAdd(whatever) and then have the proc itself take care of adding to the screen...
that works fine for me, though I dont see a reason youd ever need a proc to return somebodys mob in the first place
Either way, both of these procs/examples seem to be completely useless code that just run you in a circle back to some variable you could already reference... you want to call a proc on the client that returns client.screen? doesnt sound like the most usefull thing around <.<