- 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. - 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 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. - 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.
- 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. - 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.
- 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()).
- 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().
- 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
//... - 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. - 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. - 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]) - 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. - 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)
- 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. - 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. - 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.
- 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.
- 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. - Reference entry for /world fix: although there isn't much benefit in doing so, you CAN declare procs on it, unlike what it says.
- 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.
- 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.
- '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. "". - 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]. - 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. - 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 - 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.
- 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 - 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. - 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) - 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.
Also, what's waitfor? >_>