- Editing text files from the BYOND Members File Space Management page - Being able to edit text files such as .html and .txt files from the members file management page would be great. You wouldn't have to delete/re-upload a new file every time you want to change something small in said text files.
- Optional Separator Arguments for
params2list()
andlist2params()
- An optional separator argument would allow developers to use params2list() and list2params() for all of their explode() and implode() needs. This argument would be set to "&" by default.
Example:proc/explode( text, sep )
var/l[0]
var/pos = findtext( text, sep )
while( pos )
l += copytext( text, 1, pos )
text = copytext( text, pos+1 )
pos = findtext( text, sep )
l += text
return l
proc/implode( l[], sep )
for( var/x = 1 to l.len )
. += ( l[x] + (x < l.len ? sep :null) )
mob/verb/test()
// Instead of this:
for( var/x in explode( "HI_THERE_NOOB_FACE", "_" ) )
src << x
// We could do this:
for( var/x in params2list( "HI_THERE_FREAK", "_" ) )
src << x
// And instead of this:
var/m = implode( list("1", "2", "3", "4", "5"), "_" )
// We could do this:
var/m = list2params( list( "1", "2", "3", "4", "5" ), "_" )
// And since params2list() and list2params() are built in,
// the process would be significantly faster this way. isvar( varname, path )
- A proc which would allow us to tell whether a certain variable belongs to a certain datum type would be great. This would allow a developer who wants to write a small, customizable scripting language inside DM to do more thorough error checks.
Example Scenario:
- DS is parsing a script
- The parsing proc recognizes a variable reference of a certain datum type.
- The parsing proc wants to check whether said datum actually has said var. ( isvar( "powerlevel", /mob/monster ) )
- If said datum doesn't have said var:
-- Stop parsing script, return error.
- Otherwise continue parsing script.
And apart from the stated scenario, it could be put to many other intuitive uses.- Joining multiple dreamseeker instances at a time - The way BYOND let you join games before was exactly like this. What happened? Why can't we open other instances of dreamseeker while joining another instance any more?
ID:132854
![]() Sep 9 2009, 2:09 am (Edited on Sep 9 2009, 4:01 am)
|
|
Metamorphman wrote:
Editing text files from the BYOND Members File Space Management page - Being able to edit text files such as .html and .txt files from the members file management page would be great. You wouldn't have to delete/re-upload a new file every time you want to change something small in said text files. That's an interesting idea; I see some merit in it. Optional Separator Arguments for <code>params2list()</code> and <code>list2params()</code> - An optional separator argument would allow developers to use params2list() and list2params() for all of their explode() and implode() needs. This argument would be set to "&" by default. Since both of those procs do more than simply adding and parsing separators, the use you're describing would be inappropriate. These procs are designed specifically for converting data to and from URL-encoded forms. You're better off simply having a utility function to do implode()/explode() for you. <code>isvar( varname, path )</code> - A proc which would allow us to tell whether a certain variable belongs to a certain datum type would be great. This would allow a developer who wants to write a small, customizable scripting language inside DM to do more thorough error checks. Since we do have a hascall() proc, something like hasvar() would seem to make a lot of sense and is probably not too hard to do. Joining multiple dreamseeker instances at a time - The way BYOND let you join games before was exactly like this. What happened? Why can't we open other instances of dreamseeker while joining another instance any more? It's still perfectly possible to do that; but since there is only one splash screen, you kind of have to live with the fact that the pager will get a little confused between the two DS instances. That was a design decision that was made when the splash screen was first put in, and while it's something we can (and most likely will) change at some point, it's a low-priority issue. Lummox JR |
This may suffice for an "explode" proc. Though it only splits on a single character, unlike params2list() which sets up associated lists with =s and &s. "Imploding" would be a pretty basic for loop.
proc/Split(var/text2split,var/SplitBy=",") Lummox JR wrote: Since we do have a hascall() proc, something like hasvar() would seem to make a lot of sense and is probably not too hard to do. Based on what hascall() does, it would be easy enough to just do if(Variable in source.vars). If you're going to make a proc that can actually read from a path, could the same be applied to hascall()? It's still perfectly possible to do that; but since there is only one splash screen, you kind of have to live with the fact that the pager will get a little confused between the two DS instances. That was a design decision that was made when the splash screen was first put in, and while it's something we can (and most likely will) change at some point, it's a low-priority issue. Uh, go re-prioritize your list then. This is not only a major hindrance for players and developers, but yet another thing that's been "broken" since 3.x. I have a pretty fast connection, and this still causes problems for me on a somewhat regular basis. I can't imagine how bad it would be for anyone with dial up, maybe even with low-speed dsl. At absolute least you could make it so you can join games that you already have the resources for - while you're waiting for another game to download. Or at absolute least least! Joining things from build->run without having to wait for something to download (which is where I have most of my problems). EDITS: Wouldn't it be possible to just open up a new splash screen for each seeker, they all lead to a new seeker in the end anyway. Taking a few basic things into account, like if you're already downloading that game, or already connecting to it, and if you are - then instead of opening a new one it would just bring the related one to the front. What I'd really like to see done is discussed here: http://www.byond.com/developer/forum/?id=712751 |
Falacy wrote:
This may suffice for an "explode" proc. Though it only splits on a single character, unlike params2list() which sets up associated lists with =s and &s. "Imploding" would be a pretty basic for loop. > proc/Split(var/text2split,var/SplitBy=",") I don't understand why you wrote that ( sorry, but ) very messy snippet. Did you not see the explode() and implode() proc I posted in my initial post, or do you think it's a bad algorithm? Lummox JR wrote: I second this notion. |
Metamorphman wrote:
I don't understand why you wrote that ( sorry, but ) very messy snippet. Did you not see the explode() and implode() proc I posted in my initial post, or do you think it's a bad algorithm? Oh yea, didn't see it. Also, how is it messy? They're almost exactly the same except mine uses longer variable names =P |
// Practically uses no whitespace, makes the proc look crammed and hard to read. |
Metamorphman wrote:
> // Practically uses no whitespace, makes the proc look crammed and hard to read. |
Metamorphman wrote:
Also, wtf is with <code>SplitList+=copytext(text2split,CurPos,0) > </code>? Catches anything after the final comma. So 1,2,3 - 3 doesn't get left off. |
Metamorphman wrote:
Yes, but you're calling it after if( curPos <= length( text ))! Preposterous! lol cause you might have something that's like 1,2,3, |
Based on what hascall() does, it would be easy enough to just do if(Variable in source.vars). If you're going to make a proc that can actually read from a path, could the same be applied to hascall()? By the way, just wanted to let you know this is possible without hascall, though I would still like the functionality for hascall. proc/isProc( proc, path ) |
I'd just like to point out that you can't download anything using the pager, when the pager is already being used, it's not just for games.