Lummox JR wrote:

Apparently that confusion extends to color as well, since the atom is red, not orange. :)

Er... well, looking at it now (I have new stuff on my homepage right now) it is indeed red, but has yellow rotating stuff. I blame the fish people. :(

The atom shouldn't become red again though when you visit another page, unless new alerts have in fact appeared. You will see it remain red when you hit the back button on your browser though.

I don't know, but a while back it was going red every time I visited any other page. Even hitting F5 wouldn't help.

The search would actually need considerable modification to handle games without hub entries. The fact that they don't exist in the database means a database search geared around hub entries can't, by definition, find them.

Couldn't you make a small database which contains these entries which is stored on a different page altogether?

That would require privileges the user may not have on their system, and also most users don't have the games structured that way in their file system. But in general, this violates the KISS principle: Anyone you'd want to ban from one game, you'd certainly want to ban from all of them.

Wrong; a player I ban from one game I may not necessarily want banned from all games -- there was a time back when I was hosting a Space Station 13 server on Kalrath's Windows Server. This used terminal services to run the server. If functionality described like above were available, my host wouldn't be complaining to me because Player X was not only banned from my SS13 server but from all servers, including his own.

A lot of 24/7 hosts are hosting games on their Windows machines, and there are also Windows servers out there instead of Linux. I believe a seperate ban control is a must because of the instance where multiple people share a computer.

No. The list of bans stored in Dream Daemon should not be accessible to DM code. This is a potential breach of security and privacy. It also serves to enable game authors whose desire to control all aspects of hosting borders on fascism.

I don't see a breach of security and privacy with this idea. I'm not saying that developers should have the ability to alter the hosts' own ban lists, but rather that the developer should have it's own hub-based ban list which can be modified through the game or perhaps even via the hub entry.

This ban list would be visible in the ban control and the host can choose to disable this altogether or to disable specific bans.

The list can only be used to banish people. It can't be used to magically remove a ban put on the author, and if the author uses this to ban people the host doesn't want banned, the host can simply disable this.

The functionality can be used to make it so when someone with Moderator status in the game bans someone, it gets added to a list in DreamDaemon so the host can maintain it along with the rest of their bans.

Also I'd like to bring up the KISS principle: why make banning functionality in the game which can only be accessed by moderators and potentially locks the host out when you can give the list to DreamDaemon and have it manage it for you? It would save a lot of time!

EDIT: Perhaps the user can specify their favorite banlist? When the "All" tab is selected (which shows all bans, perhaps in a colored list of keys where 'red' would be the color for DEVELOPER, 'green' would be user, 'purple' would be game-only and 'blue' would be parent directory or something) it would use the selected banlist as the one to modify from the All tab.
This eliminates some confusion as by default it could be set to USER and any changes made via the All tab would by default ban from all servers as it is now.

It'd be one thing to store the "Allow this function" question for a trusted .dll and only re-ask whenever the DLL changes due to an upgrade, because that's sensible. But doing this for shell() and run() and such would be a major security breach.

Well the idea for shell() was allow the host to use regexp stuff to allow the developer to perform basic actions on their computer.

The defaults for the shell() exclusion would permit the developer to do something like shell("mkdir savefiles") and shell("copy mysavefile.sav savefiles/mysavefile.sav"): actions taken within the same directory as the game and specific commands allowed.

Obviously this does not seem like much of an advantage at first as the functionality above (creating a directory and moving files into it) is already available through fcopy(), but other commands may be of better use:

shell("xcopy *.sav savefiles/") or shell("cp *.sav savefiles/")

Or UNIX commands: shell("chmod 666 savefiles/*")

I'm not sure I see the utility in this. It's an interesting idea, but it'd be an organizational nightmare internally and would radically alter the skin editor interface. The cost/benefit ratio seems high.

There is a big benefit to be gained by doing this: it would be possible to group windows/panes together so that the final list becomes less cluttered.

items
        remote_controls
                tv
                vcr
                dvd
                universal
objects
        generator
                generator
                control_panel
        blackboard
main
        mainwindow
        mapwindow
        outputwindow
        rpane
        browserwindow
        infowindow
...

win* commands would need to use [groupids].windowid.elementid instead of windowid.elementid (where [groupids] could be group.anothergroup.window.elem), the .dmf files would need to be adjusted to make use of the new functionality...

I can see the problems with this, but the benefits would be far greater than the cost to implement it in my book.

Alternatively, it could be possible to just leg it by allowing multiple .dmf files; then the same thing can be done with less work, because all you'd need to do is combine the .dmf files at compile-time and complain if there are duplicate names.

Android Data wrote:

But as it turns out, these DLLs are in fact malicious and were named after John Doe's DLLs exactly so people would execute them.

Problem is, if you want to make it more fool/dumb-proof, you're going to need to do much more than that, anyway. Example: John Doe's original DLL file was soundlengen.dll ( ;) ), but the malicious koder's malicious DLL is called "soundlengen2.dll"/"soundlengenv2.dll"/"soundlennew.dll" or any other variation thereof that would make the system fail miserably.

The database sounds like a nice idea (but that depends on whether the BYOND Staff wants to go that way), if the game you're running uses an unknown DLL you'd get a big red security warning in DS (Options & Messages) or DD. There could also be a blacklist - list of known malicious DLLs, which would promptly disable running that game rather than just put a warning (at least by default, but something more than that is something else), for the sake of users. Though what Lummox said and I agreed on is that you should have the possibility of storing commonly used DLLs in a personal whitelist, no problem with that, what we were against was the option to allow shell() or run() in automatically in cases such as safe-mode - that would no longer make 'safe mode' be considered safe, and would be bad. The reason is that ultimately, the Regex checking will not save you. You've even suggested to allow certain commands by default, but then, all someone will need to do to successfully run their virus without user consent, is name it "mkdir.exe", for one example.

Masterdan wrote:

This has been a trend ive seen in byond games, when you make a game or apparently it applies to anything, people who play it from the early stages get a nostalgic attachment to it and never appreciate the changes made to it. The truth is though, byond has come a long way and while i think the site is as good as it needs to be, all thats left is to fill it up with a new generation of original games. So im hoping to see some updates to DM that focus on bugs and stability. I really think the interface update in 4.0 and the new icon format have been absolutely wonderful upgrades that allow game makers to go much further than they ever were able to, now its a matter of making people leave their comfort zones and make epic games.

I completely agree. From an outside standpoint 95% of the changes have been good ones.

Kind of picky-ish, was it not?

Android Data wrote:

Dragonn wrote:

From an outside standpoint 95% of the changes have been good ones.

You're not an 'outside standpoint'

Of course he isn't. He's a person.

because you're using BYOND on a day-to-day basis just like the rest of us. A true outsider would've just joined BYOND this very day.

Which doesn't mean it's impossible for a non-XYZ to think out of the box and from what seems for him to be the probable point-of-view of a XYZ*. It's just harder by some amount (depending on XYZ), but nothing unaccomplishable at all.

*: Replace "XYZ" in that sentence with "outsider", or most other nouns/adjectives/words for that matter, because it's a generally true statement.

Android Data wrote:

The search would actually need considerable modification to handle games without hub entries. The fact that they don't exist in the database means a database search geared around hub entries can't, by definition, find them.

Couldn't you make a small database which contains these entries which is stored on a different page altogether?

My point was that these raw games don't have hub entries, hence any search that's based on hub entries would need substantial modification so it could read a completely different table in these cases. Creating a new db table wouldn't accomplish anything because there already exists some info in the db--it's just not in the same form as actual hub entries.

No. The list of bans stored in Dream Daemon should not be accessible to DM code. This is a potential breach of security and privacy. It also serves to enable game authors whose desire to control all aspects of hosting borders on fascism.

I don't see a breach of security and privacy with this idea. I'm not saying that developers should have the ability to alter the hosts' own ban lists, but rather that the developer should have it's own hub-based ban list which can be modified through the game or perhaps even via the hub entry.

This ban list would be visible in the ban control and the host can choose to disable this altogether or to disable specific bans.

A hub-based ban list would indeed be a separate concept, and I see some usefulness in that. These sorts of concepts are a lot trickier in implementation than they sound though, so always we end up with a long discussion on which way is best. By the time said discussions are over, we have ended up going in circles and questioning even existing mechanisms without getting any closer to an idea. This kind of feature inevitably turns into a time sink on the design end.

I'm not sure I see the utility in [grouping skin elements]. It's an interesting idea, but it'd be an organizational nightmare internally and would radically alter the skin editor interface. The cost/benefit ratio seems high.

There is a big benefit to be gained by doing this: it would be possible to group windows/panes together so that the final list becomes less cluttered.

That's not really a "big" benefit. I'll grant that it would be of some benefit, but by no means a big one. It would affect only a limited number of projects anyway. I still think the cost/benefit ratio is too high.

I can see the problems with this, but the benefits would be far greater than the cost to implement it in my book.

Trust me, you have this completely backwards. It may well be of more benefit to you than it would be to a lot of people, but the cost would be quite high. I know I wouldn't use this, and generally speaking if a feature that supports complex projects isn't something I'd use, probably only 3 people will ever use it. It just doesn't seem like the payoff is there, and this would definitely be a lot more work than it sounds.

Alternatively, it could be possible to just leg it by allowing multiple .dmf files; then the same thing can be done with less work, because all you'd need to do is combine the .dmf files at compile-time and complain if there are duplicate names.

Multiple .dmf files would indeed be a decent idea, although that could also take some significant tweaking. Bear in mind a compile-time warning isn't sufficient to catch changes made at the user end of course, but this is a decent idea in general. However if you're really having organizational issues, I'd take advantage of the alphabetical sorting the list does and just name your elements as [group]_[element], which should do the trick.

Lummox JR

Foomer wrote:

You know, something that's really starting to irk me is people on this forum who nitpick every little thing people say so as to make a counter-argument over nothing. Use your brain before your keyboard. It is possible to view BYOND from an outsider's perspective. From the perspective of people who are new to BYOND and aren't suffering from "OMG change!!!" syndrome, 95% of the changes are good.

QUOTE FOR TRUTH IF I EVER SAW IT. (Every single time you say something on this website someone just has to jump in and say something about it, usually starting an argument)

Anyway. Not particularly an "outsiders perspective", but I've been using Byond for 7 or so years now, on and off. Sometimes I'd use it for a few months to a year, then stop for a few months to a few years, rinse and repeat for 7 years.
So, everytime I came back to BYOND I would notice all the changes. I'd say that the changes to BYOND are good (though I'm not sure about the websites colours!), but compared to other, alternative programs a lot of BYONDs updates are just underwhelming. BYONDs updats are simply just to few and to far apart (version 3.5 to 4 was like... a 127 year wait, and apart from interfaces there wasn't a whole lot new either).
Argue all you want about this (because someone will, they always do) but it is the truth, and that is that.

Android Data wrote:

I do agree about the uselessness of having an argument about that, although I was confused at how he got to 95%.

Its an arbitrary figure.

Lummox JR wrote:

The BYOND 3.0 to 3.5 to 4.0 transition took a long time largely because during that time, Dan left. All development from the middle of '03 through all of '06 was strictly on a volunteer basis, as people found time.

Mostly it took a long time because the project wasn't making money which led to us trying to pursue that avenue which led to burnout. But I disagree with your implication that the years before '07 were unproductive. In '05 and '06 I and others spent a lot of time pushing 3.5 out and getting 4.0 ready. It took some time, but the bulk of both of those pieces of software was written in those years, not subsequently. Given our manpower then (and now), I stand behind the achievements and think they compare well with many "real" companies who often go years between releases.

The reason that we aren't pushing out things as quickly as earlier is twofold: the product is more mature (major features that are readily do-able have been done) and our audience is much bigger (which means we don't have the freedom to make widespread changes). Like many of you, I fondly recall the early days when we were making big changes in this new technology all the time-- but I have to remind myself (as should you) that just about everything about the project then-- the software, community, and business-- was far different.