Dynamic Paths

ID:135032
 
May 2 2005, 3:31 pm
The ability to make new paths, like a /obj/buildable/customobjectdancer at runtime (i.e., make paths that weren't defined in the code)
May 2 2005, 3:54 pm
You shouldn't need this. If you can't define a type at design-time, you can't do it at runtime. Not can't as in don't have the the technology to do so, can't as in you specifically don't have the ability to do it.
May 2 2005, 7:05 pm
In response to Jp
Jp wrote:
You shouldn't need this. If you can't define a type at design-time, you can't do it at runtime. Not can't as in don't have the the technology to do so, can't as in you specifically don't have the ability to do it.

That's why it's a suggestion. Although you shouldn't have to do it, as he said.
May 3 2005, 1:13 am
In response to Yota
Maybe you didn't understand me. I don't mean, you can't do it as in BYOND doesn't let you, I mean you can't define it because you don't know what variables to put in, you couldn't know what variables to put in at run-time too.

Of course, you could just derive something from a base atomic object and modify it's vars list. Then all you couldn't do would be to attach procedures to it.
May 3 2005, 2:39 am
In response to Jp
Jp wrote:
Of course, you could just derive something from a base atomic object and modify it's vars list.

<font size=-2>Except that the vars list can't be modified at runtime. ;-)</font>

I really don't see why you'd want to create dynamic type paths. If you want to construct objects with different properties at runtime, just create the object and change its properties. Adding vars and procs at runtime is, even if it were possible, a pretty useless thing to do, seeing as vars and procs need to exist at compile-time or you can't refer to them (except using the vars list, in which case why not use a normal associative list; and using call(), which is just dodgy [because it bypasses compile-time checks]). How do you propose to construct new procs at runtime, anyway? (You could define them in the code ... but wait up, that's what you do already. =P)

No matter what your reason is for wanting this, I can guarantee that there's a much better way of handling it. =)
May 3 2005, 10:23 am
In response to Crispy
Crispy wrote:
No matter what your reason is for wanting this, I can guarantee that there's a much better way of handling it. =)

client/proc/create_new_type(new_type as type)
    register_new_type(new_type)
    update_code_for_type(new_type, input("")as message)

mob/game_master
    verb/create_new_type(new_type as type)
        client.create_new_type(new_type)

mob/npc/blacksmith
    AI()
        if(on_the_job&&nothing_else_to_do)
            var/new_type=pick(typesof(/obj/weapon)-/obj/weapon)
            craft(new_type)

mob/summoner
    verb/summon(new_type in typesof(/mob))
        var/mob/M=new new_type(loc)
        M.AI()
    verb/origin_of_species(new_type as type)
        client.create_new_type(new_type)

Short of creating your own sub-language parsing functions, how would you go about this? Assuming you don't go to the trouble of creating your own language withing the DM language, you would not be able to do many of the great things at runtime that you could do here.

I'm not saying I think it would be worth the programmers' time to update Byond to include something like this, but then on the other hand I don't think it would be near useless either. Then again, updating the eval function that is already existent so that we could program at runtime is something that has been suggested and that would be extremely helpful, moreso than just this type-at-runtime-creation, as it would include that and more.
May 5 2005, 1:00 am
In response to Loduwijk
*sigh*

Okay, let me rephrase that: No matter what your reason is for wanting this, I can guarantee that there's a much better way of handling it provided you're not trying to modify the game's code at runtime, which would be better implemented using eval() if/when it arrives. And if it does arrive, it will certainly so do before this. =)