1. Default verb category for mobs. This would work sorta like the default_verb_category client variable, except it would apply to mobs. ie: mob/GM/default_verb_category="GM" or obj/Equipment/default_verb_category="Equipment". It would help save on space and repeat coding.
2. I'm not sure if this is a bug or what, but when you select to clean compile, it only gives you the warning the first time you do it, and doesn't get reset until you reopen DM.
3. Folder Tree. It'd be nice if we at least had the option to view empty folders in the File tree in DM. It would also be very useful if we could create folders directly from the file tree, or at least somewhere in DM. And again, being able to delete folders.
4. Links in Stat Panels: it would be somewhat useful if stat panels could handle HTML 'a href' links, they already support HTML. It can be simulated with an object, but that can provide less than desired results in certain situations.
5. I saw a recent request for this somewhere I think, but. the default file system location for BYOND is "C:\Windows\system32". Its quiet a pain having to constantly navigate out of there, It'd be much nicer if it default to the directory you install BYOND to, or at least it could remember what directory you were last in between sessions (which DM and DD seem to do but DS doesn't).
6. Instead of the little drop-downy file tree thing we get when selecting the location for a New Environment in DM, would it be possible to have the full browsing window?
7. A version of isicon() that detects if something is actually a .dmi. Right now you can check its extension, but that can be faked. Not sure if you could check some alternative internally.
8. When editing hub entry's information, the box takes both HTML and plain text at face value. This is a major pain to work with. An option for both, HTML, or plain text would be good.
9. Ctrl+A when editing a map could select the entire current z layer.
10. Ctrl+V when editing a map with an area selected could repeat-paste whatever is in the clip board inside that area until it gets full.
11. Requested Before: add an option, or just all out stop the pager notification bubbles when in a full-screen application.
12. Display the splash screen on the task bar when downloading a game, or at least make it so you can't close the pager so they stay linked together.
13. Somebody Requested This Before: Some way to determine the amount of frames in a certain icon_state and/or that icon_state's duration.
14. New features for flick() that allow you to pick a start and stop frame.
15. Interface control: pager. If I remember correctly, back in 3.4 the pager was built right into the interface of the game you were playing. It could be handy if we could do that now. We would basically just need what can be seen from the friends tab.
16. Default interface window positions. This can easily be done at login with a winset, but having options to set the default starting position for interface windows couldn't hurt.
ID:133088
 Apr 19 2009, 2:01 am
|
|
Kaioken wrote:
2. [...] clean compile, [...] it only gives you the warning the first time you do it, and doesn't get reset until you reopen DM. I find it strange that it only happens once. And the fact that it goes between projects if you open multiple ones in the same instance of DM is even stranger. Open DM Open Game 1 Clean compile - Warning Clean compile again - no warning Open Game 2 Clean compile - still no warning Well, that kinda sort-of exists. When making a new file and deciding on its location, you can create new folders in your project folder there. Doesn't work for me, always says Directory does not exist. EDIT: Oh I see you can do it from the browsey window. AFAIK, isicon() should work for this and it's for things like this. It isn't identical to istype(X,/icon). Though I can foresee a possible hoop or two you may need to jump through in order to use it on an uploaded file like you seem to want, but I think it's possible. If you can't seem to get it, post some example of what you want and I'll try to whip something up. This might be good as a suggestion for AllowUpload(), but it'll also require some extra feature like an argument in it that gives you the type path of the procedure the upload was initiated from, since you wouldn't always want a restriction like this to be global. The way it works now, it accepts any supported image format as a supposed "icon" (bmps, pngs, etc) I would like to see one that only accepts valid .dmi files. and whats AFAIK <.< 10. Ctrl+V when editing a map with an area selected could repeat-paste [...] So if you copy a house, or a tree, or some other multi-tiled thing. It will create 50 of them next to each other within the selected area. | |
Falacy wrote:
1. Default verb category for mobs. This would work sorta like the default_verb_category client variable, except it would apply to mobs. ie: mob/GM/default_verb_category="GM" or obj/Equipment/default_verb_category="Equipment". It would help save on space and repeat coding. I like the idea, but it's kind of fundamentally tied to statpanels, which are a legacy control. 3. Folder Tree. It'd be nice if we at least had the option to view empty folders in the File tree in DM. It would also be very useful if we could create folders directly from the file tree, or at least somewhere in DM. And again, being able to delete folders. I'm in favor of adding options to the tree, although the code for the folder tree is quite complex. Adding things to it isn't as simple as you'd think. 4. Links in Stat Panels: it would be somewhat useful if stat panels could handle HTML 'a href' links, they already support HTML. It can be simulated with an object, but that can provide less than desired results in certain situations. If you enable HTML for a statpanel, links should be enabled as well; if they're not, I think I'd consider that a bug. Just remember, the link will affect the entire grid cell it's in, just like a grid. 5. I saw a recent request for this somewhere I think, but. the default file system location for BYOND is "C:\Windows\system32". Its quiet a pain having to constantly navigate out of there, It'd be much nicer if it default to the directory you install BYOND to, or at least it could remember what directory you were last in between sessions (which DM and DD seem to do but DS doesn't). For many purposes my BYOND install is already reading the right locations as defaults. In which situations do you still see it starting in C:\Windows\System32? That seems like something we could definitely address. 6. Instead of the little drop-downy file tree thing we get when selecting the location for a New Environment in DM, would it be possible to have the full browsing window? I assume you mean something like an Explorer-enabled file selection box. That might or might not be doable, with the project name being an extra control in the box, but it's not simple and I suspect I'd have a hard time getting it to work very well. Compounding the problem is the fact that that selection box isn't too good at selecting directories. There is a different, non-Explorer box for finding directories that maybe we could use instead; I've never liked it but it's an improvement over having nothing. 7. A version of isicon() that detects if something is actually a .dmi. Right now you can check its extension, but that can be faked. Not sure if you could check some alternative internally. At a guess I'd say you want this for checking uploaded files. I'm not sure it'd be a simple task to check icon validity. 8. When editing hub entry's information, the box takes both HTML and plain text at face value. This is a major pain to work with. An option for both, HTML, or plain text would be good. There's more than one "the box" on that page, so I have no idea what you're asking for specifically. If you're asking for the ability to use HTML in hub entry names, then I'd have to say no. The short description could, I suppose, allow for simple comment HTML, but we'd need to alter the hub to strip it out; I'm not keen on that idea either. But most other areas, notably the long description and member benefits, already let you include HTML. There is a request I've heard that sounds related to this, which is that some users have requested an ability to run their hub entry HTML through the minimal filter instead of the full blog post filter which adds line breaks. That seems like it'd be possible. 11. Requested Before: add an option, or just all out stop the pager notification bubbles when in a full-screen application. That kind of thing is difficult to detect, and it rather defeats the purpose of said notifications. 13. Somebody Requested This Before: Some way to determine the amount of frames in a certain icon_state and/or that icon_state's duration. I'm definitely behind the concept of adding more informative procs to the /icon datum; the problem however is coming up with a good format for handling the proc arguments and returned data. The design issues are basically the main reason such procs don't exist yet. 14. New features for flick() that allow you to pick a start and stop frame. I'm not sure how useful that'd be; you can already create the icon for whatever length you want it to have. 15. Interface control: pager. If I remember correctly, back in 3.4 the pager was built right into the interface of the game you were playing. It could be handy if we could do that now. We would basically just need what can be seen from the friends tab. There was no 3.4; I assume you're referring to 3.0. I'm not sure there's any utility in mixing any pager foo back into the app, to be honest. At this point it'd also represent a major design challenge, as it would require adding a new control, new messages for the pager to communicate with the DS instance, and so on. 16. Default interface window positions. This can easily be done at login with a winset, but having options to set the default starting position for interface windows couldn't hurt. Window position and size ought to be saving already, unless I'm missing something here. Lummox JR | |
Ohhh I see what you mean by "selected area could repeat paste". If you highlight an area in the map editor and hit Ctrl+V, whatever you have copied will "flood" the highlighted area with the copied area.
I second that idea :o Would save a lot of time when making "neighborhoods" or "villages" in games ;) I just don't like the idea of getting that clean compile warning every single time. I've read it, and so I know what it says. You'd think others would read it as well, but who knows... >_> Getting that warning every time would be annoying in the long run :\ But where would we be without all those warnings from out anti-virus/anti-malware programs? ^-^ It goes both ways I suppose. | |
Lummox JR wrote:
Falacy wrote: I suppose with that feature you could make 1 icon state as opposed to many different ones, then use the flick() proc to pick the start and stop frame. So say you have 1 icon state with 2 different visual FX. The first is frame 1 (start) through frame 5, and the second is frame 6 through 10. You could then call the flick() proc with something like, flick("FX",src,6,10) to get the desired second FX. I don't really see a purpose to that either, but it'd still be nice, just in case you'd wanna only play half of your FX. That way you don't have to create a whole new icon state when you could just reference an existing one and pick and choose which frames to play. Less work I suppose? | |
Lummox JR wrote:
If you enable HTML for a statpanel, links should be enabled as well; if they're not, I think I'd consider that a bug. Just remember, the link will affect the entire grid cell it's in, just like a grid. mob/Stat() Just appears as plain text for me. For many purposes my BYOND install is already reading the right locations as defaults. In which situations do you still see it starting in C:\Windows\System32? That seems like something we could definitely address. When getting an input through DM "as file" and possibly when using the ftp() proc. Maybe some others... At a guess I'd say you want this for checking uploaded files. I'm not sure it'd be a simple task to check icon validity. Yes, for uploaded files. There's more than one "the box" on that page, so I have no idea what you're asking for specifically. If you're asking for the ability to use HTML in hub entry names, then I'd have to say no. The short description could, I suppose, allow for simple comment HTML, but we'd need to alter the hub to strip it out; I'm not keen on that idea either. But most other areas, notably the long description and member benefits, already let you include HTML. The long description box takes both... at the same time. Meaning if you put: Message 1'br' (cept with <>s) Message 2 It causes a blank line between them. It utterly destroys any type of formatting you can apply to your HTML and makes it practically unreadable - especially when trying to setup tables. EDIT: Its like trying to format a HTML layout here in a forum post, as I just found out =P 11. Requested Before: add an option, or just all out stop the pager notification bubbles when in a full-screen application. They don't even work properly over full-screen apps, they basically just flicker causing an unreadable distraction. And if you need to click something in the area where they are, it minimizes the game or whatever you were in. I'm definitely behind the concept of adding more informative procs to the /icon datum; the problem however is coming up with a good format for handling the proc arguments and returned data. The design issues are basically the main reason such procs don't exist yet. icon_state_details(icon,icon_state) returns a list of params containing whatever information you have available. There was no 3.4; I assume you're referring to 3.0. There was a 3.4 >=( I used it all through 3.5 because 3.5 sucked. Window position and size ought to be saving already, unless I'm missing something here. They save, but the very first time you login they seem to be somewhat random. Plus I always reset mine to 0,0 or wherever they need to be if its some kind of popup. A default setting would force the window to whatever position you input for it each time its opened. Spunky_Girl wrote: I just don't like the idea of getting that clean compile waning every single time. You shouldn't really be clean compiling every time <.< Only before releasing and/or after deleting various files. | |
Falacy wrote:
> mob/Stat() Just appears as plain text for me. But did you enable HTML for your statpanel? If not, the link is guaranteed not to work. Otherwise, there is a bug. For many purposes my BYOND install is already reading the right locations as defaults. In which situations do you still see it starting in C:\Windows\System32? That seems like something we could definitely address. Hrm, I can look into those at some point. The long description box takes both... at the same time. Meaning if you put: Ah, then so your request is basically the one that has already come up: being able to run hub descriptions through the minimal filter instead of the full line-break filter. 11. Requested Before: add an option, or just all out stop the pager notification bubbles when in a full-screen application. Yeah, this is sort of an inherent problem with full-screen apps in general. But then it raises the question why you're leaving the pager on during all that time if you don't intend to use it. It may be possible to detect if an app has taken over the full screen, but I don't know. If it is, I'd be very surprised to discover it's a trivial check. There was no 3.4; I assume you're referring to 3.0. No, there was a build 341; that was still 3.0. The build number has no actual relationship to the version number. Lummox JR | |
Lummox JR wrote:
But did you enable HTML for your statpanel? If you mean the "Allow HTML" check box in the interface editor then yes, its on by default <.< Ah, then so your request is basically the one that has already come up: being able to run hub descriptions through the minimal filter instead of the full line-break filter. If you say so Yeah, this is sort of an inherent problem with full-screen apps in general. But then it raises the question why you're leaving the pager on during all that time if you don't intend to use it. Because exiting and restarting the pager every couple hours would get annoying? No, there was a build 341; that was still 3.0. The build number has no actual relationship to the version number. Its all liesssssssss! | |
Lummox JR wrote:
Yeah, this is sort of an inherent problem with full-screen apps in general. But then it raises the question why you're leaving the pager on during all that time if you don't intend to use it. This thread seems to provide two approaches to it, one which is verified as working for several applications. See the bottom posts for the code tested there, which works off a pretty simple concept. | |
Falacy wrote:
Lummox JR wrote: Just because we're on build 440, does not mean we're on version 4.4 ^-^ | |
Lummox JR wrote:
Yeah, this is sort of an inherent problem with full-screen apps in general. But then it raises the question why you're leaving the pager on during all that time if you don't intend to use it. I basically agree with Falacy's reply to this, and alerts do tend to cause issues in full-screen video/games even if you're careful not to do the 'clicking problem' (sometimes varies between apps), so this is a pretty important feature. It may be possible to detect if an app has taken over the full screen, but I don't know. If it is, I'd be very surprised to discover it's a trivial check. Alathon posted about this already, but I'll just say I know it's possible (and possible to do well/reliably) because I've seen a lot of alert-causing applications provide this feature well. They even make AV ones like that now... No, there was a build 341; that was still 3.0. Meh, I faintly recall it saying 3.5 around the site somewhere at the time, but whatever. EDIT (reply to followup post): Oh, yeah, that's right, I remember. I thought before that because of that there would also have been 3.4. >.> | |
Kaioken wrote:
No, there was a build 341; that was still 3.0. Yes, there was a version 3.5. 3.5 as the series of builds that introduced the pager as a separate app, but came before 4.0. Lummox JR | |
Falacy wrote:
The way it works now, it accepts any supported image format as a supposed "icon" (bmps, pngs, etc) Well, no surprise, because those are valid as icons. Maybe or that you'll even reconsider disallowing them. :P Also, as for that format, remember that DMIs are essentially PNGs. I would like to see one that only accepts valid .dmi files. Well, while you can't do this in AllowUpload(), this is one of the things that can always be done by a means of a DLL. Yes, I know that's not really what you want. :P It might still be possible to patch something up through DM, but I dunno how well that'd work. and whats AFAIK <.< Note: More often than not, a quick Google search tends to reveal mysteries such as this. But, anyway: As Far As I Know and If I Remember/Recall Correctly are 2 [internet slang thang] acronyms with slightly different meanings I occasionally use as a quick (typing-wise) noting that I'm not necessarily sure I'm correct. Cheap & effective, as they say. :P | |
People have sometimes replied to you arbitrarily like this in a topic as a shameless-plug thingy, so I guess I can too once in a while, right?
What did you think about "...AllowUpload(), ... an argument in it that gives you the type path of the procedure the upload was initiated from, since you wouldn't always want a restriction ... to be global." AFAIK you can't normally block stuff selectively from that proc <small>(f.ex. allow admins to upload whatever they want but not players)</small> without using some workaround like a global var (which is always set manually before initiating the upload) to basically represent where the request came from. Also, on a related note I've a couple of times now come across a situation <small>(not upload-related)</small> where it seemed to me it could be useful to add a procedure var (just like usr and '.') that contains the type path of that proc. Copying the type path of the proc manually for every proc is not fun. Is that feasible and what do you think? Sorry for not being able to recall good use examples at the time, some memory tends to sometimes elude me when it can be useful, so I'm just throwing it out there. | |
Kaioken wrote:
What did you think about "...AllowUpload(), ... an argument in it that gives you the type path of the procedure the upload was initiated from, since you wouldn't always want a restriction ... to be global." AFAIK you can't normally block stuff selectively from that proc <small>(f.ex. allow admins to upload whatever they want but not players)</small> without using some workaround like a global var (which is always set manually before initiating the upload) to basically represent where the request came from. I don't see why not. Its a normal client/proc, you should be able to use src.mob to figure out any adminy stuff. And you can read the file (or at least its name) beforehand to do any type of checks on that. | |
Falacy wrote:
I don't see why not. Its a normal client/proc, you should be able to use src.mob to figure out any adminy stuff. Ideally that stuff will be on src there IMO, but nevermind. :P You're right, it was just a bad example. But let's just say I want different limitations for different actions/verbs. One verb I may want to only accept an icon (pwnzor-admin or not), and another anything, or only sound, etc. And you can read the file (or at least its name) beforehand to do any type of checks on that. Like you've alluded yourself, while not completely useless this is very very limited. | |
Falacy wrote:
1. Default verb category for mobs. This would work sorta like the default_verb_category client variable, except it would apply to mobs. ie: mob/GM/default_verb_category="GM" or obj/Equipment/default_verb_category="Equipment". It would help save on space and repeat coding. I'd much rather interface etc. updates; info controls are old school now. 3. Folder Tree. It'd be nice if we at least had the option to view empty folders in the File tree in DM. It would also be very useful if we could create folders directly from the file tree, or at least somewhere in DM. And again, being able to delete folders. New directory and delete directory would be nice, and that's all that's really needed. 4. Links in Stat Panels: it would be somewhat useful if stat panels could handle HTML 'a href' links, they already support HTML. It can be simulated with an object, but that can provide less than desired results in certain situations. Again, old school. 7. A version of isicon() that detects if something is actually a .dmi. Right now you can check its extension, but that can be faked. Not sure if you could check some alternative internally. The cliet allow_upload() (or whatever it is) proc gives you file information, though I don't know how specific it gets. 11. Requested Before: add an option, or just all out stop the pager notification bubbles when in a full-screen application. Then add real full screen in BYOND! 12. Display the splash screen on the task bar when downloading a game, or at least make it so you can't close the pager so they stay linked together. I like this one, the splash screen bugs me sometimes. 13. Somebody Requested This Before: Some way to determine the amount of frames in a certain icon_state and/or that icon_state's duration. This would be nice. 15. Interface control: pager. If I remember correctly, back in 3.4 the pager was built right into the interface of the game you were playing. It could be handy if we could do that now. We would basically just need what can be seen from the friends tab. This would be a decent control, though you could probably emulate this with SendPage(), if that proc still works. | |
Kaioken wrote:
What did you think about "...AllowUpload(), ... an argument in it that gives you the type path of the procedure the upload was initiated from, since you wouldn't always want a restriction ... to be global." AFAIK you can't normally block stuff selectively from that proc <small>(f.ex. allow admins to upload whatever they want but not players)</small> without using some workaround like a global var (which is always set manually before initiating the upload) to basically represent where the request came from. I don't recall seeing that in the initial post, but here's my reaction: I think the concept itself sounds decent, although possibly limited in value. The problem however is that AllowUpload() currently works based on information the server already has available at the time the upload begins. At that point it knows the filename and size of the incoming file. It might be feasible to add in a way to deal with this via input(), but for verb arguments it'd be way more difficult. Also, on a related note I've a couple of times now come across a situation <small>(not upload-related)</small> where it seemed to me it could be useful to add a procedure var (just like usr and '.') that contains the type path of that proc. Copying the type path of the proc manually for every proc is not fun. Is that feasible and what do you think? Sorry for not being able to recall good use examples at the time, some memory tends to sometimes elude me when it can be useful, so I'm just throwing it out there. I think it'd be pretty cool to have a means of pulling the current proc's path, not to mention any caller info. To the best of my knowledge it's all doable; I just couldn't give you any kind of timetable on it. Lummox JR | |
Sounds like a very good idea, methods of saving multiple-sets have been requested before and object oriented methods are good. (But when you say 'mob' there, you pretty much want 'datum' instead.)
Dunno, seems pretty normal.
More than that, some whole slew of some basic file/folder management features would be handy. Even just drag and drop support could add a lot.
Oh, and they should add a (perhaps turn-off-able) warning to the rename feature, so after you input the new name and press OK, if you're changing the extension of the file, put up a confirmation alert. So many noobs have made threads because of how it works now because they're not used to working with file extensions, and don't put any in the rename box. Not BYOND's fault, but other programs do this confirmation thing.
Well, that kinda sort-of exists. When making a new file and deciding on its location, you can create new folders in your project folder there.
Sounds reasonable, didn't even know they didn't support it.
Enough said.
I'm not sure what kind of window you want here, but that's the standard Windows 'select-folder' window there. It sounds like you might want the 'select-file' kind-of window, but I think that can't actually select folders.
AFAIK, isicon() should work for this and it's for things like this. It isn't identical to istype(X,/icon). Though I can foresee a possible hoop or two you may need to jump through in order to use it on an uploaded file like you seem to want, but I think it's possible. If you can't seem to get it, post some example of what you want and I'll try to whip something up. This might be good as a suggestion for AllowUpload(), but it'll also require some extra feature like an argument in it that gives you the type path of the procedure the upload was initiated from, since you wouldn't always want a restriction like this to be global.
Probably requested before, good idea. 'Both' should probably be named something like 'Normal' for the sake of noobs/newbs.
?? Repeat-paste?
Thirdad.
Similarly to #3, I'd prefer a whole slew of features that allow you to access/read and manipulate various dir/frame/animation-related stuff about an icon through DM. Basically so you could handle an icon with DM like you can with the icon editor. This could be an expansion to the /icon dat- object.
Nice idea, but I don't feel it'll be too useful without an expansion like mentioned in the one above.
Provided I get you correctly, I'm not sure there's any easy way to get that done right. Not as an interface control at least, but maybe as something more internal to DS (but controlled by the developer) it could be.