Kaioken's site

Text procs renamed

Fri, 08 Jan 2010 12:10:58 +0000

(http://www.byond.com/docs/notes/462.html)
Only one word: why?

...Also, that page says "A view text procs".

Google Chrome OS

Fri, 20 Nov 2009 01:47:48 +0000

http://www.engadget.com/2009/11/19/ live-from-googles-chrome-os-project-announcement/
http://www.engadget.com/2009/11/19/ googles-chrome-os-revealed/
[...]

So, details on Google's approaching OS are out. It's basically going to be an almost entirely web-based, browser-based OS (almost seemingly Google Chrome itself expanded into an OS) that's designed for internet use only, and only on notebooks, with specific, certified hardware, at that (they are considering making it for PCs as well in the future, though).
Somehow, Google "took" the silly assumption that nowadays, all everyone does on their computer is surf the internet, and decided not to compete with Windows or any other OS at all. Even though I wasn't extremely interested in their coming OS, this is a big disappointment from it, to say the least.

Discuss.

Various suggestions

Tue, 03 Nov 2009 02:22:39 +0000

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...

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) (ID:722402)
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.

Special tag in browsers

Mon, 17 Aug 2009 21:48:10 +0000

Could browser controls (and popups) be made to support the special DM-based <IMG> tag properties (the iconstate, icondir etc attributes)? They're supported by seemingly every HTML-supporting control (output, grid, info) but not actually by the browser itself, funnily enough (oversight, perhaps?).
Just earlier I answered a newbie that could use this feature in browsers, and thought why shouldn't the browser have it as well, like the other controls. If not for misc usefulness, then it should be added at least for completeness' sake. =P If possible.

Server communications client (aka 'Export()/Topic() client'

Sat, 06 Jun 2009 08:31:12 +0000

Could the dummy temporary client (discussed in ID:701868) used to transmit server topic messages be made DM-inaccessible? Namely by means of a for() loop (for(var/client/C)), since it's otherwise properly inaccessible (AFAIK). Since it's not exactly even a whole or proper client and is only used for internal stuff, we should have no business accessing it; I suggest the ability to do that to be removed, since it could only cause problems when this client isn't taken into consideration (which should currently be the case for a lot of projects and programmers), since it doesn't behave like one would expect a client to, and requires validating every client ever being looped through in order to completely prevent potential (though not necessarily common) problems (normally AFAIK, you don't have to bother with validating clients/their mobs if you don't mess with client/New() in the project).
So yeah... this isn't a very important suggestion, but I feel it should be implemented, which hopefully should be simple and pretty quick to do. :P
Note: The minority of this isn't worth adding on to the back-burner! >_>

(Quick and easy clarification for people that haven't read the other topic: this code-

world/Topic()
    for(var/client/C)
        world << "Found client: ([C]) key ([C.key]) mob ([C.mob])"

mob/verb
    Communicate()
        world.Export("127.0.0.1:111?abc")

...gives this output after Communicate() is ran:

Found client: (Kaioken) key (Kaioken) mob (Kaioken)
Found client: () key () mob ()

I'd like not to get that 2nd client.)

world/IsBanned() modification

Sat, 31 Jan 2009 02:13:01 +0000

Could world/IsBanned() be changed so it's always called for a logging-in player? Currently it isn't called when the host logs in, which is inconvenient as it makes it more annoying to test-run IsBanned() overrides (it even often confuses newbies into thinking their code doesn't work, when it normally would) and that functionality could also be useful for cases like preventing players (including the host) from multi-keying through IsBanned().

Also, (if and) while you're going about implementing that, you could also spice up world/IsBanned() a bit. I leave you the thinking.
Yeah well, I do have some things in mind. :P

Maybe it could include additional useful info in its arguments that is unavailable in the phase of IsBanned()-callage, such as the connecting player's BYOND version (this would alternatively let you if the player connected from telnet), gender, OS, and maybe as a complement or shout-off to control_freak, if that player is using a custom (or altered) interface of the world (this is already available in the mentioned var, but you could for example discriminate and do this dynamically in this way, by allowing 'kool' people like staff and the owner custom skins but not the other players), and maybe even if that player is using some altered snazzy DMS scripts or something, or a DMS script from the BYOND site (ok, I ran out of things to list).

This would conveniently grant you the ability to, for example, quickly ban all females, or all *nix users. xD Joking of course... so maybe it wouldn't be as useful for rational people (other than the byond_version), but for the sake of completion perhaps? (but one may still do want to ban all neuters, for instance)
Could the result of IsBanned() be somehow forwarded on to client/New() if the player is granted connection, so it can be known without calling IsBanned() again? I cite this from the Reference as the clarification:

[...] Tom was banned through some other means, and he has been allowed to login, even though he is banned. (Code in client/New() might then check IsBanned() and somehow limit his activities in the game.)

This is potentially a pretty good idea, but you can't actually do this without manually re-calling IsBanned() with the right arguments for the player (which is kinda silly), or other methods consisting of more-roundabout-than-it-should-be silliness. If possible, client/New() should have an argument that is in practice what IsBanned() returned for that player (which could be a list with a bunch of info, or just a value like 0). Or if this is tricky for some reason, then at least a flag that is set to one value if the "Login" = 1 parameter was set (to allow a banned player to login), and to another if it was set because of a pager-ban, for completeness.

Thank you for reading kind sir, and have a great day.

Disclaimer: I wrote this up at 4 AM. This is without sleeping of course, since I'm a kool guy.

Quick suggestion: Use default interface as template

Fri, 29 Aug 2008 03:25:40 +0000

Well, when creating a new interface file in Dream Maker through File->New, if possible, it would be handy to have a checkbox appear when 'Interface File' is selected ("Use default interface as template" or something to that extent) that will cause the default skin file to be copied from the BYOND directory to the project's, and be renamed to the given name, instead of a new file to be created.
This is useful as it's handier than digging for it in the BYOND folder, copying it, clicking Refresh etc, and could be a common action to do in projects where you don't really use a custom interface, but you just need to tweak a few controls/parameters. While presently not too difficult, this feature would both make it easier to do for newbies and cause them to be aware of the ability to do so (copying the default interface) more obviously and have it integrated into the program. Well, I just thought this would be nice to have after copying it for like the 5th time or so. =P

Firefox screwup?

Fri, 08 Aug 2008 00:55:36 +0000

So, I finally got around to installing Firefox 3, and now I noticed I have this (ID:642434) problem: code boxes on the forums stretch the whole page itself instead of having scrollbars and not stretching anything. This didn't happen with Firefox 2, did Mozilla up? Or did the site break just when I happened to install it (=P), or do other FF3 users not experience this? It's quite annoying, like someone is posting a huge image on every developer topic. =(

Hiding atoms' names

Sun, 13 Jul 2008 13:07:16 +0000

I thought it could be nice if we had a var like mouse_opacity, but that only accounts for the atom's name display when the mouse is hovered over it (or have this implemented as flags into the existing var), meaning when it is set to 0, the name is not displayed*, but mouse actions (right-clicking, Click()) still work. Just a quick, not essential suggestion to add to the List if you guys like it.

*: As per mouse_opacity, the name of the object under that atom will be displayed instead, if any.

True/false values in the DM Reference mistake

Tue, 01 Jul 2008 02:52:29 +0000

I noticed that in the DM Reference, apparently all entries (except for the one on null) regard false values as equal to 0, or more commonly, regard true values as "non-zero"; CTRL-F for this "true (non-zero)" in the DM Reference. Basically all entries that have this or similar, are misleading and should be fixed. This may be a big factor in the "== operator abusage" in checking for 0/1 values.
Most importantly, this is also wrong in the entries for things like the if statement and the ! operator.
I'm not sure if this was left unupdated or not or is there for some other reason, but the reference should be more accurate for the sake of DM-newbies that don't know what true/false values in DM are.