Why not make it a coded option whether or not the players can take screenshots? This would probably reduce the risk of graphics being ripped all the time. -_-
-Kijokiha
ID:136370
 Dec 7 2002, 11:46 am
|
|
|
Dec 7 2002, 11:48 am
|
|
Mertek
 |
I don't think that is even possible. There are other screen-capturing programs, the print screen key... There are just too many ways, it's not feasible. I doubt there will be any way to completely stop icon-ripping.
|
No its pretty much impossible, even if you set a macro for the PrintScreen button, then you could just rip it from a software package. Sucks hey?
| |
Kijokiha wrote:
Why not make it a coded option whether or not the players can take screenshots? This would probably reduce the risk of graphics being ripped all the time. -_- Well as noted in the previous posts you can't realy avoid people ripping graphics. Basically if you can see it on the screen it can be ripped. So the safest way to avoid people ripping your graphics is to not display them which kinda defeats the purpose :). The best thing you can do is look down upon people who do it and tell them its wrong in hopes that they see the error is their ways. | |
The only people who do that are people who think they can use someones elses icons for there game and get away with it! Dam you stealers!
| |
Make a macro for F2 and that will return ".quit"
| |
Mertek wrote:
I don't think that is even possible. There are other screen-capturing programs, the print screen key... There are just too many ways, it's not feasible. I doubt there will be any way to completely stop icon-ripping. If only there were a way to make the byond window non-captureable using some internal windows function. But then someone would hack that as well. The solution is open source and a society without money. :) /Gazoot | |
I think even if you made an un-hackable version, there would always be a determined ripper or two who goes out of there way to copy your icons pixel by pixel.
-DogMan | |
Spuzzum wrote:
My technique is to make my graphics complicated enough that any rips done will come out poorly. =) But don't most modern video cards store the displayed image in DIB format? If they do I don't see how you can complicate your graphics without making them look corrupt on the screen. | |
I think he means making the graphics themselves complicated, not the format (phenotype versus genotype). Even though they're in a standard format, they could be composed of different parts animating seperately. This is pretty hard to capture, unless you can seperate the parts (not always entirely possible if they overlay). Even just having more animation frames makes it more difficult to rip. There's a lot of stuff you can do to discourage ripping, but nothing to prevent it.
-AbyssDragon | |
Or they could just open a seperate window, making the BYOND window inactive, this would make you able to take a screnshot with the printscreen button anyway, because it would be the new window recieving the printscreen command, and not the BYOND application.
And if you DID manage to set a macro for F2, the player could just hit the tab that says "screen capture" under the window's toolbar. Stopping ripping is not impossible, but is harder than it's worth. Just try to discourage it. Or just ignore it. | |
Actually...Terra Server (Microsoft's site that contains satellite images of Earth) use to have a feature that whenever you pushed PrintScreen, it would copy the screen to the clipboard; however, the actual image (which they wanted you to buy) was removed. I have no idea as to how they did this, but it is a very interesting concept.
| |
I was making a mech-warrior type game where each mob was 2 pieces, body and legs. They would rotate independantly. I'd like to see someone rip THAT. It turned out to be too much of a strain to upload all those files every time someone moved (360*360 = too big). I might try it again once I get my program that bypasses the default BYOND client-to-server communication, and will allow me to do more things client-side.
| |
Garthor wrote:
I was making a mech-warrior type game where each mob was 2 pieces, body and legs. They would rotate independantly. I'd like to see someone rip THAT. It didn't keep people from ripping Tanks. Of course, my tanks only have 8 directions and limited animation. It turned out to be too much of a strain to upload all those files every time someone moved (360*360 = too big). The easiest way is to just premake them so players get the entire package when they download the game, then place the resource file on another server (look at the preload_rsc client var for more details). You could have BYOND draw the turned icons and save each one for use by the game program. Thats how I produced the colored blob icons in Blob! when I only created a single grey blob by hand. I'm sure you remember what a nightmare it was to download them in the game when they weren't premade. I might try it again once I get my program that bypasses the default BYOND client-to-server communication, and will allow me to do more things client-side. BYOND is capable of making each client operate independantly. There are two problems with it though. One, the designer has to determine exactly which data to transmit between clients and write code specifically for the data transmission. Two, users who can not host games (due to firewalls or what have you) will not be able to recieve data from other clients. To my knowledge, no one has created a game using this method, but Deadron made a demo. (http://www.byond.com/hub/ hub.cgi?qd=hubIndex;hub=190;channel=1183) | |
The firewall issue is one thing that I'm not sure how to work around. Prompting the person for an open port in their firewall would make sense though.
Aside from the icon upload thing, there are other issues with the current default BYOND client-server communication. One of them is an excess of communication, which results in more used bandwidth, which can spell hell for someoen hosting a game, because every time someone presses a key, information is sent to the server. With a system that controls the information flowing between client and server, it can reduce the lag produced by macros/movement. By first checking it client-side, then sending it to the server if it passes the check and double-checking the information there, a system that reduces lag and yet is just as secure can be established. Like I said before, the client-side processing of color changes, icon manipulation, and such would allow for more of an escape from the tile-based system, as the single problem that I've come up with most was the lag from the processes. It could even be used to make 3d games that would work multiplayer. A single-player 3d game is possible in BYOND, but due to the object limit, and the fact that everything is processed server-side, it is impractical. | |