ID:132775
 
Status: Open

Issue hasn't been assigned a status value.
Thought I'd throw in some new features that I had on my mind for a while now, to be added at the Staff's leisure, so, without further ado...

  1. Find Node feature: a new kind of Find feature (or more like 'Jump to...' or 'Go to...', if you will) that instead of just searching for text, parses the code tree and searches only in node definitions. Meaning e.g. I'd type in /mob/proc/DeathCheck, and I'd be taken straight to the DeathCheck() declaration (even if it was defined using indentation instead of with the / path operator). If I type /mob/player, I'll be taken to the definition of that.
    This should have all the standard features of Find as well (Find Next takes you to the next occurrence of the node, if any), and there should also be a checkbox for "Include overrides", which, when checked, would include overrides in the search (with the previous example, it could find the override nodes /mob/DeathCheck(), /mob/player/DeathCheck(), etc).
    Needless to say, the normal Find feature doesn't make finding node definitions and declarations so easy; you always tend to find instances of the proc is called or type path used instead.
  2. New procedure vars (like . and usr): a procedure var (or even special preprocessor macro) that contains the procedure's own type path would be handy to avoid manual work and increase manageability when you want to use that path.
    If an additional var that contains call stack data was added as well, that would be very nice.
  3. A way for client/AllowUpload() to tell where the file request came from and the nature of it (e.g., a method to pass a "reason" argument to it). At the moment there's no actual built-in way to differentiate between different upload situations, and obviously you could want different restrictions for different situations. If call stack info accessibility is added, this could be automatically semi-satisfied.
    When using input() to initiate a file upload, you can use workarounds to pull this off; so I guess it's more important to fix something up for verb-argument-initiated uploads.
  4. Access resource files dynamically: at runtime, you should have the ability to access resource files by using dynamically-made names. This could be just added in the form of adding an argument to file() that makes it look for the file in the RSC file(s) instead of the filesystem.
  5. A real option to manually include resource files in the RSC would be nice - including whole folders (and maybe wildcard file names?).
    For example, this could be done with a preprocessor directive:
    #includeRSC "myfont.ttf"
    #includeRSC "icon.dmi,script.js,help.txt" //easy syntax for multiple files
    #includeRSC "extra resource files/" //include all the files in a folder (and subfolders)
    #includeRSC "infopage_*.htm" //include all filenames conforming to the wildcard filename

    Of course, the main need for this is to have the ability to conveniently and flexibly mass-include resource files, by including folders or batch-including using * and ? wildcards.
  6. Mouse control for interface controls, in the form of more on-event commands, similarly to JavaScript: e.g. onclick, onmouseover, onmouseexit parameters for all controls.
  7. Icon processing expansion
    • Allow opening specific frames using /icon datums; IIRC you can already Insert() specific frames, but it seems you can't actually access/edit specific frames...?
    • Allow editing (delays) and forming animations
    • Add an /icon proc and a global proc that returns an animation's total duration in ticks. Something like this is a pretty fundamental feature that is long overdue.
    • Give a parameter to icon datums that makes the icon they create NOT be added to the resource archive. I don't actually remember the original scenario where I needed this, but this could be useful when you're making temporary icons for some reason, icons that aren't intended to be viewed by players at all (for example, perhaps you're generating an image to be stored on the hard disk), or icons that are only needed to be sent to one or a handful of players (which might be using browse_rsc()).
  8. flick() expansion
    • Allow the flick()ing of areas.
    • Fully allow flicking using objects (/atom, /image) instead of icons or state names, which would take into account all of the object's visual properties (dir,layer,text,pixel_* and maybe more, such as name).
      At the moment you can flick using objects, but all visual parameters except icon and icon_state are ignored. Supporting this would add functionality and flexibility to flick().
  9. Saving on mouse control bandwidth: presently, if one doesn't override a specific mouse control function in his project (e.g. MouseDrag()), then the clients of that project don't bother flooding the server with mouse status messages about that event. Perhaps that could actually be expanded in an atom-specific manner? So if I've overridden only /obj/button/Click(), the clients don't send any click messages for other objs and mobs, etc.
    This would require that either the /client versions of the procs automatically make all atoms generate the messages, or that they'd need to be modified so the usage of them doesn't do so; meaning that for client/Click() to be called at all, even if you override it, you'd need to override atom/Click() on the types you want it to be called for. Obviously that wouldn't be so backwards-compatible, but you could keep the old behavior for projects compiled in older versions, and any newer projects that want the old behavior can restore it very easily merely by including a few lines such as this in their project:
    atom/Click() //we override this, meaning all atoms generate click messages
    atom/DblClick() //same
    atom/MouseDrop() //same
    //...
  10. A procedure similar to client/Command(), but one that is processed for ALL commands, irregardless of whether they correspond to verbs or not. If overridden, this procedure should be the first thing that is processed when a command of a player is retrieved by the server, and the command would only continue to be processed as normal by the server if this proc calls the default function.
    Back in the day I would have simply suggested for client/Command() to be modified to be like this, but that wouldn't be so good for backwards-compatability, especially now that the proc is documented and so used more.
  11. world/IsBanned()should be called for the host as well
    Really, why is it not like this? world/IsBanned() not being processed for the host isn't even documented, nor is there much sense in it when you think about it. The only advantage I can see it brings is that "stupid" hosts are protected in the case they "accidentally" pager-ban themselves.
    This would make testing IsBanned() implementations easier and would prevent confusion, as currently, if you test it by test-running the world you would get the initial impression that the proc is broken.
    Also, world/IsBanned() can be used for things not only directly involving banning as well, such as multi-key prevention, that the host shouldn't be relieved of.
  12. Using for()'s built in object filter using a dynamic type
    Self-explanatory. Perhaps currently the only limitation here making this impossible is the syntax to use? In that case, you guys just need to come up with a syntax that allows using a dynamic type (a variable or even a full expression) in this. Using the existing 'as' clause feels suitable, but it needs to be somehow differentiated from the hardcoded settings (e.g. as mob).
    Maybe a new keyword, "of" can be added for this, perhaps used in conjuction with 'as':
    var/TypeVar = pick(/mob,/obj)
    for(var/A as of TypeVar [in Container])
  13. Labels should support displaying atoms (preferably fully supporting pixel-offset under/overlays, as no other control presently does so, other than the map control(s)).
    First reaction to them not doing so is "why the heck not?", though logic suggests you guys may have had a specific reason for doing that, perhaps that it's not feasible.
  14. In addition to any of the new suggestions suggested here that would be implemented, further features that aren't currently documented (in the References) need to be. Some random undocumented features off the top of my head:
    • Using output() to execute JavaScript functions - Tom "documented" this in the release notes when it was added, but it's not anywhere else!
    • waitfor procedure setting
    • 'to' syntax in if() statements, 'to' syntax in for(), 'step' syntax in for()
    • eval(), perhaps it should be documented, saying it's incomplete but can do some things well (like basic arithmetic)

  15. atom.alpha (and image.alpha) ([link])
    I already mentioned why I think this should be added in that topic, and I've ran into situations where this would be useful. It would also be nice if this was fully incorporated, for example you could add atoms with modified alpha vars to overlays and have them transparent.
  16. More control over atom drawing is often needed in certain projects, and could be done by expanding the concept of invisibility and /images.
    With invisibillity, a finer control over who can see which invisible objects is really needed and was requested many times.
    With /images, it would be nice if the ability was added to make an image attached to an atom completely replace that atom's natural appearance, instead of being tacked on to it as an under/overlay. Meaning you'll be able to make an atom appear completely differently to different players.
  17. The receiving of topic messages sent to worlds should be changed so a dummy "ghost client" doesn't appear in the process, if a loop through /client objects happens to occur during that time.
  18. In hub entries, the "hosted by [world.host]" part shouldn't appear on the server entry if world.host is blank - that just looks bad.
  19. Modifier keys status sent with verb commands to the server
    It would be nice if a way was added to let a verb know if modifier keys were held down when the player activated it (in whatever method, input control, macro, info control). For example, my verb should be able to know if SHIFT was held down when the player activated it, so if so, it could behave a little differently. This could be implemented in the form of a new procedure var, modifier_keys or modifiers or something of the sort, that includes a list or a string that contains which modifier keys were held, if any. Another option is to implement it as a special verb argument type, meaning the keys are only sent to verbs that actually use them - possible syntax and use example:
    mob/verb/Heal_Spell(list/K as keys)
    var/mob/target
    var/mob/mob_in_front = locate() in get_step(src,src.dir)
    if("shift" in K) target = src
    else if(mob_in_front && "alt" in K)
    target = mob_in_front
    else target = input("Heal whom?") as mob in view(src,3)
    src.Heal(target)

    As you can see, this feature could be very convenient for developers and players and has many possible uses.
  20. Reference entry for /world fix: although there isn't much benefit in doing so, you CAN declare procs on it, unlike what it says.
  21. A hasvar() procedure, which would be similar to hascall(), would be nice. It should support taking a type path instead of object reference, and while we're at it so should hascall() (even though the procs available to an object can change at runtime, by means of the verbs list). This was requested before once.
  22. Reference entry change for icon arithmetic operators; we all know they're not actually being "phased out"; we figured that out by now, since that was written there for years. Rather, the entry should just include that bit about how /icon objects are the the newer, more flexible option and that; people shouldn't be wary of using icon arithmetic in cases where they only need to do a quick, single icon operation, where using /icon is a little superfluous.
  23. 'Resource libraries'; there should be the ability to psuedo-#include folders outside of the project's folder, in which files could be conveniently used as resource files, as if they were in the project's folder.
    For example, instead of having every project of mine include duplicate copies of resource files such as black.dmi, white.dmi, kaioken_logo.png, myscript.js, etc, I could have single copies of those files in a central location on my drive, for example D:\BYONDresources, then simply put #use_resources "D:/BYONDresources" in my DME (or a .DM) - then whenever I use a file in single quotes and Dream Maker goes to look for it when I compile, it would check not
    only the project's folder and subfolders (according to FILE_DIR settings), but also that extra
    folder I designated for it.
    For this to be flexible and supported in actual libraries, the path taken should be flexible,
    of course: it could be either an absolute path, relative path, or the #include 'library path' (which automatically finds the library inside the BYOND folder), e.g. "".
  24. Give the /world object a vars list: this would simply behave like any other object's built-in vars list.
    This could be useful in certain cases, even though most of them would likely be logging and generating debug output.
    Like with other vars lists, one of the possible applications could be to robustly and conveniently save and load all/certain vars [of the object].
  25. Make a vars list that contains the global vars: this would behave as any other vars list too, except it would be unique in that instead of storing all of an object's vars, it would store all of the project's global/top-level vars (I suppose that this most probably shouldn't include global vars defined on objects using the global modifier).
    The applications for this would be mostly similar to those of the above suggestion. At the moment, I and at the very least several others work around the lack of this feature/ability by declaring global vars on a dummy datum instead, which is stored in a global var:
    vartracker
    var
    gamemode
    current_round
    player_count
    var/vartracker/Glb = new
    //then using Glb.vars

    But seeing as this approach is less clean (in several ways), I would prefer it not to be necessary.
    This could be in the form of world.global_vars.
  26. Free-form object type filter in the built-in object selections
    ... meaning you can limit verb arguments' and input()'s choices' object-type to e.g. /mob/player or /obj/item instead of just /mob or /obj.
    This is a pretty common-sense-ish feature that must have been already suggested many times, so this is just a friendly reminder, because if you implement this, it could share the syntax with feature #12. Also, if the client isn't currently aware of atoms' full type path, if you add #9 then it will be, enabling this feature. >:P
    Another trial at suggesting random possible syntaxes for this is to include the word 'type' itself in it, making it clear. It might look like any of these different options (demonstrating different contexts as well):
    input() as type:/mob/player
    mob/verb/destroy(o as of type:/obj/item in contents) //(or obj/item/o in contents)
    for(var/A of type:TypeVar [in Container])
    //and maybe
    input() oftype /mob //or astype:/mob
    input() astype /mob //or astype:/mob
  27. Reference entries should include all the possible usages of whatever they're explaining
    At the moment this is not always the case, and various usages are undocumented, for example:
    • missile()'s Reference entry doesn't mention the fact that it can be used with an object reference instead of a type path.
    • The entry for the src setting lacks various other possible settings for it, for example using client.screen or mob.group.
    • image()'s entry fails to mention that some of the arguments it takes (at least those named pixel_x and pixel_y).
    • The reference entry of new() should include a list of the different built-in object types it can be used with at the bottom, including info about using new() with each one. Mainly, that info should be what arguments it takes for each of those types (in some cases, that should just be a link to a parallel entry, e.g. image(),icon()). Currently, it covers the atom types only, and you have to go elsewhere for other types - which could be an impediment in certain situations (for example, a newbie may not know to which other entry he should go). Then there's also the basic idea that the reference entry for new() should (fully) explain how to use new(). :P
    • A lot of the "vars (X)" entries don't actually contain a full list of the vars X has. Often, some vars that you're less likely to use on that type are omitted - but for the sake of documentation, they should be included, perhaps as an appendix.
      Examples of missing vars in the documentation: lists and clients also have a tag var, images have all (IIRC) the vars objs have, /sound has all the vars of /datum, all the non-datum objects except /world have type and parent_type vars (and those vars are sometimes not included in the ref even for datums), etc.

      Also, a reference entry about the "Appearance" object (the object inside overlays) would be nice, detailing what vars it has and any other info that could be useful.
    • The reference entries for the verbs list and typesof() don't mention that in addition to receiving types as type paths, they also support receiving them as text strings; a useful ability.
  28. Being able to access the input type bitflags and dynamically feed them into input() would be nice. It would be useful for those situations when you need to provide a wrapper procedure for input() (examples: making a wrapper proc set a global variable that lets AllowUpload() know for what it was called, making timed inputs). Currently, when doing so you'd need to manually cover all the input type combinations yourself, which is, needless to say, unclean, unrobust, unflexible... you get the point.
    Not sure what the syntax for this should be... maybe using 'as' once more:
    mob/verb/input_number()
    MyInput(src,as num)
    //or
    MyInput(src,as null|num)

    //or, using a dummy proc for this could look better
    MyInput(src,INPUT(null|num))
    //or
    INPUT(as null|num)
    //or
    input_type(as null|num) //...
    proc/MyInput(target,input_type,list,...)
    world.log << "input of type [input_type] started for [target]"
    //(^embedding in text would give the number, I suppose)
    input(target,...) as input_type //... could use similar syntax to those in #26, I guess
  29. Being able to modify world.host: the purpose of this is twofold: being able to change what appears in server entries after "hosted by" (e.g., "hosted by Main Server","hosted by Supernatural Productions" or whatever) and being able to change who your code (and libraries', etc) treats as the host, by setting it into a different key.
    If manually set, it shouldn't automatically reset when the host logs in/out. However, manually setting it to null (or maybe 0) should immediately restore that behavior.
    Now that I think about it, a potential exploit with this could be that if you set it to say "Main Server", someone with the key "Main Server" could log in and accidentally be regarded as the host... so that usage should be pulled off differently, by adding a new var that overrides world.host in the hub display, so it's similar to status... perhaps "world.host_status". While we're adding this, that var should also replace the hardcoded "hosted by" part on the hub page, so you're able to use different wording or grammar if you want.
  30. Either make the path procs (ispath(), text2path()) support procedure type paths (/mob/proc/Attack) and 'procedure declaration paths' (/mob/proc,/mob/verb), which typesof() supports, or document the fact that they're not supported.
    (All of the following return either 0 or null:)
    ispath(/mob/verb)
    ispath(/mob/verb/Test)
    text2path("/mob/verb")
    //( text2path("/mob/verb/Test") works fine)
  31. Add the ability to designate a .dm file to always load first, by a compiler preference (stored in the DME). This file should always be compiled first (before libraries as well), and should appear at the top of the file list (if it's in a folder, it might be better to make it only the first inside that folder, then) irregardless of name, and have a marked display (e.g. name underlined or in bold). Why this would be useful is obvious, and it would also add the ability to intuitively include a file before libraries are, which is sometimes needed (for example, in the case where you can enable features or change the behavior of a library by #defining something before it's compiled).


Some ideas are more fleshed out, and others are a little more at the 'brainstorm level', so I'd value any constructive input you may have. Discussions of the features should probably be kept concise though, seeing as this thread would quickly become a garbage dump if ~20 separate verbose discussions were to start.
I support many of these, mostly the documentation part and the mouse control part.

Also, what's waitfor? >_>
These are good suggestions, and (for the next round of features) rest assured we'll give them some thought. We have a bit of a backlog on requests at the moment but I always like to see the ideas flowing. In a project of this size it is hard to keep up with the demands of the userbase, but when a feature is requested often enough (eg, better mouse procs on the UI), we try to take care of it.

I'm not sure what happened to the documentation. I am certain I documented javascript output() in the reference, at least, but it seems to have been overwritten. We'll clear that stuff up with the 455 release.
In response to Tom
Tom wrote:
These are good suggestions, and (for the next round of features) rest assured we'll give them some thought.

Glad to hear. =)
I understand your requests backlog and all that, so there's no problem if you guys take your time with this. Obviously, other things such as finalizing 455 and life come way first.

I'm not sure what happened to the documentation. I am certain I documented javascript output() in the reference, at least, but it seems to have been overwritten.

Ah, makes sense; I actually didn't expect this to be missed either, as you had always added new features to the reference a short while after they were added. The documentation of some obscure past features is what needs a bit of work on.
Kaioken wrote:
In addition to any of the new suggestions suggested here that would be implemented, further features that aren't currently documented (in the References) need to be.

We should create a separate topic and start compiling a list of features that seem to have been forgotten, so that they can be added to the reference on the new 455 release.
As an example, POST support ;)
Kaioken wrote:
Find Node feature: a new kind of Find feature (or more like 'Jump to...' or 'Go to...', if you will) that instead of just searching for text, parses the code tree and searches only in node definitions. Meaning e.g. I'd type in /mob/proc/DeathCheck, and I'd be taken straight to the DeathCheck() declaration (even if it was defined using indentation instead of with the / path operator). If I type /mob/player, I'll be taken to the definition of that.

I think this could be a bit difficult to add since it basically requires some advanced parsing, but it's probably not impossible. I definitely like this idea.

New procedure vars (like . and usr): a procedure var (or even special preprocessor macro) that contains the procedure's own type path would be handy to avoid manual work and increase manageability when you want to use that path.
If an additional var that contains call stack data was added as well, that would be very nice.

A way to support call stack data would definitely be good, as would a better means of error handling.

A way for client/AllowUpload() to tell where the file request came from and the nature of it (e.g., a method to pass a "reason" argument to it). At the moment there's no actual built-in way to differentiate between different upload situations, and obviously you could want different restrictions for different situations. If call stack info accessibility is added, this could be automatically semi-satisfied.
When using input() to initiate a file upload, you can use workarounds to pull this off; so I guess it's more important to fix something up for verb-argument-initiated uploads.

A call stack won't take care of that because AllowUpload is initiated separately, like a verb would be. But there may well be a way to work in some additional information about the upload request.

For uploads initiated by verbs I think it would also be helpful for the verb's path to be available.

Access resource files dynamically: at runtime, you should have the ability to access resource files by using dynamically-made names. This could be just added in the form of adding an argument to file() that makes it look for the file in the RSC file(s) instead of the filesystem.

That's an intriguing concept. file() just converts a string reference to a file reference, but there's no inherent reason (I can think of) that the .rsc couldn't be searched for a certain filename and then convert the result of the proc into a cache reference instead.

A real option to manually include resource files in the RSC would be nice - including whole folders (and maybe wildcard file names?).
For example, this could be done with a preprocessor directive:
#includeRSC "myfont.ttf"
#includeRSC "icon.dmi,script.js,help.txt" //easy syntax for multiple files
#includeRSC "extra resource files/" //include all the files in a folder (and subfolders)
#includeRSC "infopage_*.htm" //include all filenames conforming to the wildcard filename

Of course, the main need for this is to have the ability to conveniently and flexibly mass-include resource files, by including folders or batch-including using * and ? wildcards.

Not a bad idea. For a while I've also favored the idea of a #package directive that would work much like some current .dme directives do to tell the compiler what gets packaged where, except this would be a little more stable since those .dme directives are lost if Dream Maker is closed unexpectedly (such as by a crash or by an OS command).

Mouse control for interface controls, in the form of more on-event commands, similarly to JavaScript: e.g. onclick, onmouseover, onmouseexit parameters for all controls.

Adding more mouse support across the board has been on our wish list for a while now, like say being able to drag a button to another button. That kind of fits in with this, although your suggestion is really more command-based. I like that too.

Allow opening specific frames using /icon datums; IIRC you can already Insert() specific frames, but it seems you can't actually access/edit specific frames...?

You can do that already using the arguments in icon().

Allow editing (delays) and forming animations

This is possible with Insert(), except that you don't yet have control over the loop var, so user-created animations will loop indefinitely.

Add an /icon proc and a global proc that returns an animation's total duration in ticks. Something like this is a pretty fundamental feature that is long overdue.

Hrm, that's an interesting idea. I think if I did that I'd work it into a more comprehensive solution that would allow access to other info, like for instance the aforementioned loop parameter. When I added Width() and Height() for 455 however I felt those were worth doing separately since they're really a whole-icon thing.

Give a parameter to icon datums that makes the icon they create NOT be added to the resource archive. I don't actually remember the original scenario where I needed this, but this could be useful when you're making temporary icons for some reason, icons that aren't intended to be viewed by players at all (for example, perhaps you're generating an image to be stored on the hard disk), or icons that are only needed to be sent to one or a handful of players (which might be using browse_rsc()).

Generally speaking an /icon is never added to the .rsc file unless you call fcopy_rsc(), assign it to atom.icon, or do a few other things that require the equivalent of fcopy_rsc() to proceed.

I think browse_rsc() is one of those issues where an /icon has to be added to the .rsc file, and it's because of the way we transfer files. But I do like the idea of using a simple temporary file instead of the temp cache for that, if it's feasible.

Allow the flick()ing of areas.

That's been requested a lot. I think it's probably pretty doable.

Fully allow flicking using objects (/atom, /image) instead of icons or state names, which would take into account all of the object's visual properties (dir,layer,text,pixel_* and maybe more, such as name).
At the moment you can flick using objects, but all visual parameters except icon and icon_state are ignored. Supporting this would add functionality and flexibility to flick().

That could be on the tough side, I think. But probably more of a boon to developers would be properly syncing animation ticks (within overlays and such), something the code doesn't do right now. That is, a flick cares more that it's on frame F of the animation instead of tick T, so overlays whose images might differ in their delay rates will look weird.

Saving on mouse control bandwidth: presently, if one doesn't override a specific mouse control function in his project (e.g. MouseDrag()), then the clients of that project don't bother flooding the server with mouse status messages about that event. Perhaps that could actually be expanded in an atom-specific manner? So if I've overridden only /obj/button/Click(), the clients don't send any click messages for other objs and mobs, etc.

I don't think the client would really have knowledge of that sort of thing, so that could be on the difficult side to implement. But I can see it having pretty significant value, since you could for instance only respond to MouseEntered() and MouseExited() for a certain kind of obj, etc.

However we'd probably also want to be able to allow the messsages for any object in cases where the developer wants that.

A procedure similar to client/Command(), but one that is processed for ALL commands, irregardless [sic] of whether they correspond to verbs or not. If overridden, this procedure should be the first thing that is processed when a command of a player is retrieved by the server, and the command would only continue to be processed as normal by the server if this proc calls the default function.
Back in the day I would have simply suggested for client/Command() to be modified to be like this, but that wouldn't be so good for backwards-compatability, especially now that the proc is documented and so used more.

Hrm, so it could be something like client/PreCommand() that might return a true value if it processed the command. That could be quite interesting, although it'd definitely modify client-server communication. The process would be non-trivial but I think I can envision how it would work.

world/IsBanned()should be called for the host as well
Really, why is it not like this? world/IsBanned() not being processed for the host isn't even documented, nor is there much sense in it when you think about it. The only advantage I can see it brings is that "stupid" hosts are protected in the case they "accidentally" pager-ban themselves.

It's always been the case that the host is never checked against a ban (nor are any players on the local loopback address), but I agree this should certainly be documented.

Also, world/IsBanned() can be used for things not only directly involving banning as well, such as multi-key prevention, that the host shouldn't be relieved of.

Well, if you really want to check the host there you can always do the check in client/New() instead.

Using for()'s built in object filter using a dynamic type
Self-explanatory. Perhaps currently the only limitation here making this impossible is the syntax to use? In that case, you guys just need to come up with a syntax that allows using a dynamic type (a variable or even a full expression) in this. Using the existing 'as' clause feels suitable, but it needs to be somehow differentiated from the hardcoded settings (e.g. as mob).
Maybe a new keyword, "of" can be added for this, perhaps used in conjuction with 'as':
var/TypeVar = pick(/mob,/obj)
for(var/A as of TypeVar [in Container])


"as of" feels kind of clunky to me; I think the as clause in general is a poor fit for this. You're right that syntax is a major limiting factor though. The other factor is that this involves a little complex compiler foo I'll have to parse out. Seems like it's plenty doable if the syntax issue can be resolved though.

Labels should support displaying atoms (preferably fully supporting pixel-offset under/overlays, as no other control presently does so, other than the map control(s)).
First reaction to them not doing so is "why the heck not?", though logic suggests you guys may have had a specific reason for doing that, perhaps that it's not feasible.

I'd be fine with that. Basically it just involves similar code to what we do in grids and such, although pixel offsets in the overlays and underlays are not currently handled there either. They can be done, just not quite as simply.

waitfor procedure setting

I think this is undocumented largely because it's deprecated, but I might be mistaken.

'to' syntax in if() statements, 'to' syntax in for(), 'step' syntax in for()

Those would be good to have documented.

eval(), perhaps it should be documented, saying it's incomplete but can do some things well (like basic arithmetic)

Until recently eval() was actually quite buggy and it still only supports a bare minimum of DM code. I'm not sure it's so feasible to document this without opening up a can of worms.

atom.alpha (and image.alpha) ([link])
I already mentioned why I think this should be added in that topic, and I've ran into situations where this would be useful. It would also be nice if this was fully incorporated, for example you could add atoms with modified alpha vars to overlays and have them transparent.

I like this idea, particularly in light of isometric mode, but I'm not sure what it would take to pull it off. Integrating that with our display code would not be particularly pleasant, I think.

More control over atom drawing is often needed in certain projects, and could be done by expanding the concept of invisibility and /images.
With invisibillity, a finer control over who can see which invisible objects is really needed and was requested many times.

I don't think modifying the invisibility var would work so well as far as backward-compatibility. Perhaps something else could work, but I've personally never thought highly of the "invisibility channels" concept, so I think something more robust would have to be designed to be worth implementing.

With /images, it would be nice if the ability was added to make an image attached to an atom completely replace that atom's natural appearance, instead of being tacked on to it as an under/overlay. Meaning you'll be able to make an atom appear completely differently to different players.

I'd like this too as an option. Syntax is again probably the most limiting factor, though it'll probably take a little work (hopefully not a lot) on the client side to work this out as well.

The receiving of topic messages sent to worlds should be changed so a dummy "ghost client" doesn't appear in the process, if a loop through /client objects happens to occur during that time.

I don't know if that's possible. What might be easier is marking whether a given client is a DS client, telnet, CGI, or some other thing like a topic request.

In hub entries, the "hosted by [world.host]" part shouldn't appear on the server entry if world.host is blank - that just looks bad.

Agreed. If it's doing that on the website now then I'd say that's a bug.

Modifier keys status sent with verb commands to the server
It would be nice if a way was added to let a verb know if modifier keys were held down when the player activated it (in whatever method, input control, macro, info control). For example, my verb should be able to know if SHIFT was held down when the player activated it, so if so, it could behave a little differently. This could be implemented in the form of a new procedure var, modifier_keys or modifiers or something of the sort, that includes a list or a string that contains which modifier keys were held, if any. Another option is to implement it as a special verb argument type, meaning the keys are only sent to verbs that actually use them - possible syntax and use example:
mob/verb/Heal_Spell(list/K as keys)
var/mob/target
var/mob/mob_in_front = locate() in get_step(src,src.dir)
if("shift" in K) target = src
else if(mob_in_front && "alt" in K)
target = mob_in_front
else target = input("Heal whom?") as mob in view(src,3)
src.Heal(target)

As you can see, this feature could be very convenient for developers and players and has many possible uses.

I suspect our bit flags don't have a lot of room for an "as keys" but it's something I could look at. I kind of like the idea of having it available as a special var though.

Reference entry for /world fix: although there isn't much benefit in doing so, you CAN declare procs on it, unlike what it says.

Noted.

A hasvar() procedure, which would be similar to hascall(), would be nice. It should support taking a type path instead of object reference, and while we're at it so should hascall() (even though the procs available to an object can change at runtime, by means of the verbs list). This was requested before once.

If taking a type path isn't required, then this can be accomplished simply by using the object's vars[] list.

Whether equivalents can be done with type paths is something I'm not as sure of.

Reference entry change for icon arithmetic operators; we all know they're not actually being "phased out"; we figured that out by now, since that was written there for years. Rather, the entry should just include that bit about how /icon objects are the the newer, more flexible option and that; people shouldn't be wary of using icon arithmetic in cases where they only need to do a quick, single icon operation, where using /icon is a little superfluous.

That makes sense.

'Resource libraries'; there should be the ability to psuedo-#include folders outside of the project's folder, in which files could be conveniently used as resource files, as if they were in the project's folder.
For example, instead of having every project of mine include duplicate copies of resource files such as black.dmi, white.dmi, kaioken_logo.png, myscript.js, etc, I could have single copies of those files in a central location on my drive, for example D:\BYONDresources, then simply put #use_resources "D:/BYONDresources" in my DME (or a .DM) - then whenever I use a file in single quotes and Dream Maker goes to look for it when I compile, it would check not only the project's folder and subfolders (according to FILE_DIR settings), but also that extra folder I designated for it.
For this to be flexible and supported in actual libraries, the path taken should be flexible, of course: it could be either an absolute path, relative path, or the #include 'library path' (which automatically finds the library inside the BYOND folder), e.g. "".

I kinda like that idea. Might take some mulling over to figure out how best to implement it.

Lummox JR
In response to Schnitzelnagler
Schnitzelnagler wrote:
We should create a separate topic and start compiling a list of features that seem to have been forgotten

I do believe we had that once upon a time on the Bwiki.
In response to Lummox JR
Lummox JR wrote:
I think this could be a bit difficult to add since it basically requires some advanced parsing, but it's probably not impossible. I definitely like this idea.

Glad you like it. Yeah, thought it would be a bit difficult to do. Maybe you can skip the bunch of the work by reusing the existing code, i.e. making it run an actual psuedo-compilation-process (to build the path tree) when you use this feature?

Allow opening specific frames using /icon datums; IIRC you can already Insert() specific frames, but it seems you can't actually access/edit specific frames...?

You can do that already using the arguments in icon().

http://www.byond.com/docs/ref/beta/info.html#/proc/icon
AFAIK, the format is icon(file,state,dir); I'm essentially looking for icon(file,state,dir,frame), so I can isolate specific frames in animations.
(IIRC, new /icon() might already have an undocumented 4th argument though, which may be in the way.)

Allow editing (delays) and forming animations

This is possible with Insert()

Good to know, thanks. (Change that to having the ability to control looping, then. =P)

Add an /icon proc and a global proc that returns an animation's total duration in ticks. Something like this is a pretty fundamental feature that is long overdue.

Hrm, that's an interesting idea. I think if I did that I'd work it into a more comprehensive solution that would allow access to other info, like for instance the aforementioned loop parameter.

Are you thinking about a winget()-style proc for icons? >_> Well, that works just fine as well, I was just kinda hoping for something a little more quick/intuitive, like get_duration(icon,state,dir=SOUTH), rather than something like get_icon_data(icon,"duration","iconstate='[state]' dir='[dir]'"). Guess if that's what you have is mind, I can always turn that into a short #define, though.

But I do like the idea of using a simple temporary file instead of the temp cache for that, if it's feasible.

Yeah, there are certain situations where that would be very good, especially if that still allows displaying the icon to a player or three as I've said (meaning it's sent only to them, and temporarily at that; should be gone after the session). An example situation is allowing a player to freely customize his character's hair color while giving him a visual preview of the end result; in the process, the player could try a lot of different colors, all of which end up as separate icon files - and it's a waste for those to be stored in the dynamic cache or potentially sent to other players, since we only really care about that last single icon the player chooses. Then there's also the hinted situation where you want to display a temporary graphic to a player in a browser control (showing a specific icon_state comes to mind, as like we've discussed previously, you can't use the special <IMG> tag there), tho you said browse_rsc() could be problematic here.

Fully allow flicking using objects (/atom, /image) instead of icons or state names
That could be on the tough side, I think.

Hmm. I thought it would be somewhat easy to use the same behavior as with icon and icon_state, but the nature of the other vars might make that more difficult.
At any case, I encourage you to look into it; it would really enhance flick(). At the moment, flick() can't even be used to properly display an explosion animation on a turf without using a dummy obj; with this feature in, that would have to go somewhat like this:
obj/gfx_effect/explosion
//name = "explosion"; dir = SOUTH
icon='effects.dmi';icon_state="explosion"
text="<font bgcolor=red>E"
layer = MOB_LAYER + 3

turf/proc/Explode(...)
flick(/obj/gfx_effect/explosion,src) //support type paths like missile(), while we're at it - otherwise, use new()
...

The above flick() would cause the following temporary visual-only (vars are unaltered) changes on the turf while the animation plays: its visible (on mousehover) name will be "explosion", (dir of the displayed icon SOUTH,) its text-mode name will be an E with color, and it will visually appear above mobs (the most essential change in this example).

I don't think the client would really have knowledge of that sort of thing, so that could be on the difficult side to implement.

Yeah, I assumed it doesn't as well, so it would be needed to be sent to it once upon login.
I think the client may well already have data about atom types paths, though.

But I can see it having pretty significant value, since you could for instance only respond to MouseEntered() and MouseExited() for a certain kind of obj, etc.

Yeah, that's the bulk of the point; a lot of the mouse functions constantly generate a lot of unneeded network messages which the server doesn't do anything with, so it's a good idea to remedy it.

However we'd probably also want to be able to allow the messsages for any object in cases where the developer wants that.

Yeah; I already covered this in the feature description, along with a possible implementation suggestion (did you miss it?).

A procedure similar to client/Command(), but one that is processed for ALL commands, irregardless [sic]

Hey, that's a word!

Hrm, so it could be something like client/PreCommand() that might return a true value if it processed the command.

That's good as well, though having the ability to determine whether the received command was actually interpreted a verb could be useful at times, and I thought a good way to handle it would be by using ..()'s return value:
client
var/list/action_log = new
PreCommand(cmd)
. = ..() //process the command like normal
if(.) //if it was caught as a verb
src.action_log[cmd] = world.realtime
else
src << "this means client/Command() was called by now"


It's always been the case that the host is never checked against a ban (nor are any players on the local loopback address)

Why, though? If the programmer wants to ban the host for some reason, he can still do so anyway. As I said, the only benefit of this is that hosts don't suffer from accidentally pager-banning themselves, which doesn't strike me as a worthwhile reason to make the proc less useful and less easily-testable.

Well, if you really want to check the host there you can always do the check in client/New() instead.

Of course, but world/IsBanned() is preferred since it prevents login overhead and the needless calling of any overrides of client/New().

"as of" feels kind of clunky to me; I think the as clause in general is a poor fit for this.

Hey, you can use just 'of', then. =P
I only suggested using 'as' because that would be more familiar and fit the pattern, since both the existing 'as X' feature and the "of TypeVar" feature serve the same purpose of overriding the type used in the filter (even if the looping var is typecasted).

You're right that syntax is a major limiting factor though. The other factor is that this involves a little complex compiler foo I'll have to parse out. Seems like it's plenty doable if the syntax issue can be resolved though.

I leave it to you, Lummox. ;)

I'd be fine with that.

<_< So there wasn't a reason that wasn't the case from day one? I call oversight! Ha, caught you - what do I get?

Basically it just involves similar code to what we do in grids and such, although pixel offsets in the overlays and underlays are not currently handled there either. They can be done, just not quite as simply.

At least you'll have an interesting time. Also, the same thing of course applies for the new 'big native icons' feature, which is really almost the same as atoms with pixel-offset under/overlays (but different).

waitfor procedure setting

I think this is undocumented largely because it's deprecated, but I might be mistaken.

It still has some use nowadays - although you can achieve the same effect using spawn().
You may think it's deprecated because in the past, the default value of the setting was 0, so to get the current, nowadays behavior you had needed to explicitly set it to 1, but in current versions you don't. However, the setting can still come in use for the less-common cases where you want the old behavior.

Until recently eval() was actually quite buggy and it still only supports a bare minimum of DM DM Script code. I'm not sure it's so feasible to document this without opening up a can of worms.

I hear that one. I'm kinda torn between that and the necessity of every var/proc at least having an entry in the Reference so its existence is known.
You can probably get away with writing an un-detailed reference entry about it, that quickly explains its usage but simply says it's incomplete and basically 'use at your own risk'. A similar thing is pulled off in the under/overlays Reference entries, only in the reverse; it says you can't individually access the elements in it, but you actually can and occasionally it's very useful. It's just that the access is limited and read-only.
(You may want to reword those reference entries, too)

atom.alpha
I like this idea, particularly in light of isometric mode, but I'm not sure what it would take to pull it off. Integrating that with our display code would not be particularly pleasant, I think.

Oh well; at least it could be somewhere down The List, and it may become easier to integrate later on.

I don't think modifying the invisibility var would work so well as far as backward-compatibility.

Yeah, I didn't mean that. You could do things like add more syntax/usage options to see_invisible, or add a new var that functions like invisibility but is much more controllable.

Perhaps something else could work, but I've personally never thought highly of the "invisibility channels" concept, so I think something more robust would have to be designed to be worth implementing.

As far as I'm concerned, it could be something as simple and unwitty such as setting see_invisible to a list of atoms and/or type paths - so long as the feature is in.
Really, if you allow the reuse of lists (meaning that, unlike the other built-in list vars, the var can be assigned to a reference to a list, and keep that reference instead of being set into a copy of that list), that could even be quite simple and easy on resources, e.g.:
var/list
demons=new
angels=new
ghosts=new
demon/New() demons += src
//repeat for the other types (Del() not necessary but recommended)

mob/player
BecomeAngel()
src.see_invisible = angels
BecomeDemon()
src.see_invisible = demons
Die()
src.see_invisible = ghosts


With /images, [...]
Syntax is again probably the most limiting factor, though it'll probably take a little work (hopefully not a lot) on the client side to work this out as well.

That's very good, especially considering finding a syntax for this would be very easy, heh.

Topic() ghost client stuff
I don't know if that's possible. What might be easier is marking whether a given client is a DS client, telnet, CGI, or some other thing like a topic request.

Well, that ghost client is already marked by having all its identification vars set to null (key, computer_id...). The main point behind this request is simply having the client not appear in the loop; it doesn't matter if it's still there. You wouldn't need to do anything special here if you can give it a unique type path, such as /topic_client, so I'm hoping that is possible to do.

I suspect our bit flags don't have a lot of room for an "as keys" but it's something I could look at. I kind of like the idea of having it available as a special var though.

Well, whichever method goes. The "as keys" was a little preferred since it could inherently save a little bandwidth in the odd cases where modifier keys were held when the verb didn't use them, but those would use little total bandwidth, and besides, you could achieve the same effect with an extra procedure setting, set listen_to_keys = 1 (or something better named).</_>
In response to Kaioken
Kaioken wrote:
A procedure similar to client/Command(), but one that is processed for ALL commands, irregardless [sic]

Hey, that's a word!

Nope, it's actually one of the most common grammatical gaffes known to the English language. The actual word you're looking for is "regardless". The other is not a word.

Lummox JR
In response to Kaioken
Kaioken wrote:
Allow opening specific frames using /icon datums; IIRC you can already Insert() specific frames, but it seems you can't actually access/edit specific frames...?

You can do that already using the arguments in icon().

http://www.byond.com/docs/ref/beta/info.html#/proc/icon
AFAIK, the format is icon(file,state,dir); I'm essentially looking for icon(file,state,dir,frame), so I can isolate specific frames in animations.
(IIRC, new /icon() might already have an undocumented 4th argument though, which may be in the way.)

icon() supports named arguments so you don't need to worry about argument positioning.
In response to Lummox JR
Lummox JR wrote:
Nope, it's actually one of the most common grammatical gaffes known to the English language. The actual word you're looking for is "regardless". The other is not a word.

No, it is, and the people that say it aren't are as backwards and inane as people who say "ain't" isn't a word. This has no effect on how people using these words are interpreted, though.
Added #24-#27
EDIT: Reworded and expanded #27
EDIT 2: Another, small suggestion: the Developers menu at the top should include a link to the Skin Reference as well. This would actually be even more beneficial than you'd initially think, one of the reasons being that not everybody is even aware that there is a Skin Reference.
EDIT 3: Added #28-#29
EDIT 4: Added #30, expanded #27
EDIT 5: Added #31
Kaioken wrote:
Give the /world object a vars list: this would simply behave like any other object's built-in vars list.
This could be useful in certain cases, even though most of them would likely be logging and generating debug output.
Like with other vars lists, one of the possible applications could be to robustly and conveniently save and load all/certain vars [of the object].

Here's a better idea: finally make all objects children of /datum. It's been in the reference that eventually all objects would be made datums, so it should finally be done; that's probably one of the oldest things on the to-do list!
In response to Jeff8500
Not sure whether /world is even a possible candidate for being turned into a /datum, since it's one of those built-in types you can't do much with (only declare procs on), unlike datums. The same applies for types with similar restrictions.
Also, sometimes distinction between datum and 'non-datum' is actually needed (and changing this could be backward-incompatible): you wouldn't typically want datum/New() to run when /world or a /list is created, for example. So maybe the types better actually stay how they are... though it would be interesting to have more control over the non-datum types like /savefile and /list (at least the same amount of control we have over /client, New() and Del() and declaring vars and procs).
Besides, the only difference between adding vars to /world and making it a datum is that in the latter, /world would get a bunch of extra vars that are useless for it (type, parent_type, tag). Well, it would also receive Read()&Write(), which may or may not work with it (and are only a slight plus).
I found something nice from about 3 years ago, so I'm shamelessly plugging this here as a reminder, in case it has been forgotten: ID:132775. There are 31 feature requests/ideas over there. Wonder if they're still relevant and how many have been covered since.
In response to Kaioken
Looking at your list, I don't believe any of these feature requests were addressed.
I'd think some have been. Actually, I just found one that have: /image part of suggestion #16 (ID:112608). Dunno for the invisibility part or the others, yet.