I just had an odd thought of a possible abuse of the new ban system while thinking of ideas. Sorry for posting again on the old topic but will this new ban system also allow the coder to make it so someone couldnt be banned from the game thats being hosted.
Im sure your confussed about what im asking so heres an example. Im going to use prpr as an example. Its only right that a host couldnt ban the owner an in some cases they cant because byond allows you to override the banned keys list from the host. That way its limited to the verb an of it has a return for the owners key.
Will coders still be able to override this ban system if needed so that a host couldnt just ban the owner for some reason... I mean I can understand how the host should have control over who can connected an what not but same should apply for the owner in most cases hosts can use 3rd party programs to ban the owners ip. Anyway that was the question. o.O Hope I didnt make to many people yell wtf to many times...
Ac19189 wrote:
I just had an odd thought of a possible abuse of the new ban system while thinking of ideas. Sorry for posting again on the old topic but will this new ban system also allow the coder to make it so someone couldnt be banned from the game thats being hosted. Actually it would be VERY handy for BYOND to code in a basic panel that game owners can access from the BYOND site that allows them to do basic things to their online games like make a banned player list, shut down the game etc. Since BYOND communicates with hosted games anyway it'd save SO MUCH trouble if the host those commands that they could access externally through BYOND. In fact I'd donate like $50 extra just to see that happen XD | |
Feeding off of Perpetr8r the Perpetu8r comment for a moment it also be a nice option if the game owners could force byond to delete the rsc or hosting files to the game if the owner wishs to do so from that owner panel or anything that was created by the game. That way owners could force there own protection on people that steal the hosting files etc. Just an idea. Might turn a few heads because of the fact its deleting files but I honestly say it be worth the extra control.
Maybe making it simple like for example make it so when an owner force deletes the rsc from the hosts computer using the owner panel. An exe compile client number comes into play an the only way to host a working copy of that game again is to get a new compiled copy that is allowed from the owner. Even if they had a backup rsc if the hubs rsc/client compile number didnt match then byond auto delete the rsc again. This would bring a whole new level of control to byond an its coders. I think it be worth it an im sure MANY people be willing to pay for byond membership to have that option. o.O | |
You can delete the .dmb and .rsc files. fdel("/") will delete the folder. You could also delete the dmb and rsc by setting the path. In my game if there is an abusive host I can delete the .dmb or .rsc file to prevent the hosting.
| |
Xx Dark Wizard xX wrote:
You can delete the .dmb and .rsc files. fdel("/") will delete the folder. You could also delete the dmb and rsc by setting the path. In my game if there is an abusive host I can delete the .dmb or .rsc file to prevent the hosting. So long as they don't outsmart you and backup the files beforehand, in which case you're screwed. | |
"Round 1" of the Dream Daemon upgrade is now complete, meaning the application is finished and checked into our CVS repository, but may see some changes down the road depending on what else changes with the pager and such. Some of the features in Dream Daemon are really more backend features, like the new ban and friend systems, and we're looking into ways to tie some of these into the hub--the friend lists especially. If a game is only hosted for your friends, logic says it should only be visible to them as well.
Here's the full list of new features in Dream Daemon: - Multiple tabs allow easy access to all aspects of world hosting. - Server settings like security, visibility, etc. can be changed on the fly just like in Dream Seeker. The server port may also be closed to prevent new logins, and opened again. - New World menu allows quick changes to world status and ability to reboot a game in progress. - A list of players is available, showing who is logged in and who has logged out. - Messages or announcements can be sent to players. - Players can be kicked out of the game for the duration of the session, or banned entirely. - New host-based ban controls allow banning by key and/or IP address, and "sticky" bans make it more difficult for unwelcome users to login. - Hosts can set up lists of friends, and choose to host for only certain friends lists instead of for the general public. - Commands can be sent to world/Topic() by the host. The proc will be called with master=1. - Output to world.log (seen in Dream Daemon's World tab) can be loggged for later reference. - World files can be selected from the File | My Games menu. - Dream Daemon has a proper Windows help file. And a related new feature for DM is that now a world.host var is available. | |
The only thing that I'm somewhat a-feared of with regards to splitting Dream Daemon and Dream Seeker entirely is the idea that it won't be as easy to run a one-off test of a BYOND game in Dream Maker. Instead of just having a single self-contained Dream Seeker window pop up, also popping up BYOND if need be, it will naturally have to pop up BYOND, Dream Daemon, and Dream Seeker, and you'll have to remember to close down both Dream Daemon and Dream Seeker once you're done testing and ready for another half-hour-long coding swarm before you run another local test.
| |
This may be a pretty difficult to implement, but could we be able to run multiple worlds with one DD window?
| |
no way that would be a huge time waster
| |
Can we also have the option of banning a user for x amount of minutes?
| |
Android Data: The ban and friends lists are not, as I mentioned previously, per-game settings. There's really no reason for them to be, except for bans which expire at the end of the session which are a separate concept. Whether a game is restricted to certain friends or not is a per-game setting, but the lists themselves are universal.
It is not possible at present to color world.log output and runtime errors separately, since all runtime errors are output to--you guessed it--world.log.
world.key actually has another use, which is outmoded as I recall, but world.host is a new var I added just Friday. It will be available to both Dream Daemon and Dream Seeker. We've needed this info to be available for a long time.
And just FYI, the new ban system does cover IP addresses. Either they'll work as an IP address recorded to belong to a certain banned key (from a sticky ban), or you can ban an IP address subnet. I'm still adding interface code for the latter.