ID:2145003
Sep 7 2016, 9:38 pm (Edited on Sep 14 2016, 3:32 pm)
|
|
Step 1: Draw a pentagram in your project using ascii.
Step 2: Say the unholy incantation: /client Step 4: PROFIT! I keep expecting SOMETHING to break, but some very basic tests show this works to make vars and procs defined on /datum exist on your client objects, as well as make client's pass an istype(client, /datum) simplifying some code, with no observed issues so far. Update: /tg/station has been running on this setup for a while now, and no issues or oddities reported. | |
|
Sep 7 2016, 9:40 pm (Edited on Sep 7 2016, 10:34 pm)
|
|
Optimumtact
 |
Fool! You meddle with forces byond your ken. You will be struck down by the old ones for your insolence in warping the fabric of their creation.
|
 | |
 | |
Man rewrites byond with one simple trick! Find out how!
| |
Man rewrites byond with one simple trick! Lummoxes HATE him!
| |
Just got merged. It's official, /tg/station13 is ran on dark magic.
| |
Or you could ask Lummox to put a istype() proc in for client...
| |
That doesn't help for object inheritance. If I make a var or proc on /datum/ for some wide reaching subsystem, I'd want it to work on anything that can hold programmer defined procs and vars. so far, client is the only thing that didn't get defined datum procs/vars
(also, you can istype clients with istype(blah, /client)) | |
Won't that anal client/Topic()?
| |
byond built ins don't conflict with each other because they aren't actually "defined" like user vars/procs are. it's just a switch tree
And our client topic has been working perfectly (trust me, any issues with it would become extremely apparent, we use the fuck out of it) | |
I'm just curious what kind of overhead attaching all the stuff from /datum to /client entails, but it's not like it's attaching the stuff from /atom/movable, so it can't be too crazy.
| |
builtins add almost no overhead because they use a jump table, and every builtin in datum already exists in clients.
so it's whatever user side code is attached to datums, and iirc builtin's are checked first, so those won't slow down internal procs like Click or Move or Topic. on /tg/station we have more attached to /client/s than we do /datum/s proc wise, and we don't add new vars to datum when we can avoid it to avoid slowing down every var access in datums like atmos. it's mostly procs that have it | |
