|
Pfhreak posted:Anyone have any suggestions? Ideas? Also, how secure is my idea? I know that I won't be able to stop dedicated crackers using this technique, but how long would it hold of a curious nerd? A few minutes. Maybe an hour, tops. That said, it's probably a very good way to go about this. You simply can't prevent someone dedicated from accessing the data you have to send them, so it's not worth trying. The benchmark you should be aiming for is to prevent "casual" or "accidental" piracy, without impeding "normal" use or causing yourself a massive hassle. Your proposed solution sounds like it meets this benchmark well. You'll probably want to use an HMAC to create the secret key for the username, just so you can't be defeated by a trivial google search or something like that. I wouldn't bother putting any more thought or effort into it than that. You just need to get to the point where if someone pirates the data, it is obvious that they did so intentionally and with forethought -- at that point, you are legally in a much better position, and it's unrealistic to assume you can do any better.
|
#
¿
Dec 28, 2007 07:15
|
|
|
|
| # ¿ May 7, 2024 13:27 |
|
|
Vinlaen posted:The only problem with this is that you can't use textures in system memory as render targets (which would make drawing explosion circles or whatever a LOT easier...) So don't have off-screen explosions; just pan the screen to follow the active projectile?
|
|
#
¿
Mar 5, 2008 21:33
|
|
|
Vinlaen posted:So you're saying to destruct the active terrain tile texture (which is on the video card) and then copy it back to system memory? If you're absolutely committed to using the graphics cards for your processing, sure. I don't know why you would bother, though, when various scorched earth clones seem to do just fine on sub-hundred-megahertz machines without accelerated graphics.
|
|
#
¿
Mar 6, 2008 05:34
|
|
|
Cedra posted:1.67 rounded up Integer arithmetic does not round, it truncates. 5 / 3 = 1.
|
|
#
¿
Mar 25, 2008 22:11
|
|
|
Intel Penguin posted:Now my question is, what's the best way to store the key to the archive? The simple answer is to use the same key for all the archives and store it as a constant in the game, but I can't imagine that'd be very secure. No method will, in practice, be any better than this. The DRM problem is incredibly hard to solve. What are you trying to prevent through your use of encryption? It sounds like you may be using the wrong tool for the job.
|
|
#
¿
Jun 16, 2008 01:22
|
|
|
vanjalolz posted:Sounds like you're trying to stop people from editing the files to get an unfair advantage in game. I think you'd need to use some kind of CRC method for this, but ultimately you just need to put in more effort protecting your game than the hackers are willing to put in to break it. They could just edit the CRC to match the modified data. If he's trying to prevent editing by cheaters, then he wants to use a signature and a public key. If he's trying to protect his art assets from copying, then embedded watermarks might be the best plan. If he's trying to protect his game from wholesale piracy, then I have some bad news...
|
|
#
¿
Jun 16, 2008 07:42
|
|
|
Null Pointer posted:If it were for multiplayer cheat-prevention, I'd base the it on a hash of a host-dictated concatenation of random segments of loaded assets. Someone who could bypass that would probably write a trainer before bothering with content editing. Yeah, for multiplayer this means that the cheater needs to at least alter the program code or directly manipulate the network stream (and keep a copy of the unaltered files, but that's obviously easy). For single player, you probably want to just sign the data files, and store the public key in the program executeable. You could also hash the data files and store the hashes, but that means that every time you change the data, you have to recalculate the hash, alter the code, and rerelease the program. Either way, the cheater has to change the program executeable itself (which is far from difficult, but at least isn't trivial). If you have more time to put into this, then augment your data model: Wherever you would normally just have a constant in the data, add the possibility to use the CRC of a segment of a data file, XORed with a constant (with the other data file, the start and end of the segment, and the XOR constant specified inline). Then just pepper your data files with spaghetti references to eachother. A cheater could still attack the data files, but they'd have to write a helper program to undo the cross-references first, or risk random in-game corruption. To make it even more devious, incorporate the same references into your program code, at critical points of the program.
|
|
#
¿
Jun 16, 2008 08:21
|
|
|
https://opengameart.org is probably a good place to put things like that.
|
|
#
¿
Apr 5, 2010 18:48
|
|
|
Luigi Thirty posted:Helpfully, the cos/sin functions say they return radians but don't say whether they take radians or degrees. No cos or sin function in the world returns radians. They return unitless numbers which are projections of a unit vector on to either the X or Y axis, respectively.
|
|
#
¿
Jun 15, 2010 23:40
|
|
|
OneEightHundred posted:Okay, asset management: git-annex is very nice for managing collections of files without checking the files themselves into git, which sounds like the kind of thing you want. You could use a normalish git workflow to do your work, but easily drop dead content from your store, and you don't have to worry about anything like partially-uploaded files breaking things.
|
|
#
¿
Feb 3, 2012 04:02
|
|
|
KingsRansom posted:In my experience thus far git is hilariously bad at dealing with large binaries. but to be fair its been about 2 years since I attempted to use it for that purpose. Yeah, plain git is really not designed for large files. I think at this point everyone who needs git and large files is using something lik git-annex to avoid having to check the files themselves into git, and just store references to them instead.
|
|
#
¿
Feb 6, 2012 00:06
|
|
|
poemdexter posted:Git is actually great for large files of text. The whole way it was designed is pretty clever when it comes to storing references to different chunks of text that's used a lot. And worst comes to worst, you can always run "git gc" to let it clean up references and such. In my experience, the packfile delta algorithm isn't any worse on binary files than on text files. It certainly has no obvious algorithmic reason to be worse; it's not like it cares about line endings or anything silly like that. Text files tend to be somewhat more compressible than binary artifacts, so large already-compressed binary files like textures are something of a worst case. The slow hash function calls associated with large files are much more of a problem in my experience; it sucks to run "git commit -a" and have it do a hash check on gigabytes of data just to determine that only a few small files have changed. Especially if you're used to a workflow involving frequent commits of small changes, as is fairly common with distributed RCSes.
|
|
#
¿
Feb 6, 2012 00:47
|
|
|
HaB posted:Yeah I know. What I mean is, Minecraft is using that seed in some equation that sets the spawn point. I'm trying to see if anyone knows what that equation is. It is as you described. Minecraft picks a random point within a few hundred blocks of (0,0) until it finds one that's an acceptable spawn location.
|
|
#
¿
Feb 18, 2012 01:41
|
|
|
HaB posted:If it's random, then it wouldn't be the same every time the same seed is used. Sure it would be. That's what random seeds are. If you use the same seed, you'll always get the same sequence of pseudorandom numbers. The seed you give to minecraft doesn't go into some fancy "world gen seed algorithm". It's just used to seed the standard random number generator, which is then used to build the world. Immediately after building the world, that same random number generator is used to pick the spawn point. There's nothing clever or unexpected going on. If you give a fixed seed to a random number generator, it will always produce the same sequence of numbers. Minecraft uses some of those numbers to generate the world, then it uses some of them to pick a spawn point. Because you provided a seed, you get repeatable results.
|
|
#
¿
Feb 18, 2012 01:56
|
|
|
HaB posted:I spent a few hours last night wading through the Minecraft sources, but following the chain backwards from where the player is actually spawned only leads me to one spot where it's grabbing 3 int values from an NbtTree (which seems to work like a hashtable but can return multiple types instead of just one). I assume the tree is populated using the map seed but hell if I can figure out where that's happening. Specifically: That looks like code for loading the spawn location from a save file. World.java has getInitialSpawnLocation() which boils down to this: code:Edit: For me, at least, a big part of the confusion with this whole thing is that this is an algorithm I would not be shocked to find described as "picks a location within a few hundred blocks of (0, 0) and tries to spawn, if it fails, it increments until it finds a valid location" so it's been weird that HaB seemed to want something more. ShoulderDaemon fucked around with this message at 18:01 on Feb 18, 2012 |
|
#
¿
Feb 18, 2012 17:49
|
|
|
|
| # ¿ May 7, 2024 13:27 |
|
|
The Gripper posted:The license is unnecessarily vague in parts and it leads to the current situation where there's no consensus on what it all means, exactly. Even worse is that there shouldn't *be* a consensus at all - it should be laid out in the license. What constitutes a derivative work is contested, for example, and that absolutely shouldn't be something defined by the author of a license. It is worth noting that in many countries, including the USA, it is beyond the scope of any license to determine what constitutes a derivative work. Or, to put it another way, works can only be affirmatively determined to be derivative or not based on the decision of a court, which will examine the entire context and origin of the work in conjunction with the stated intention of the authors, as conveyed by any licenses that are determined to be applicable to the situation. The GPL simply makes it clear that the intent is to extend the copyright claim as broadly as possible, and does so very explicitly. But that's all it's doing. The BSD license, for example, can be easily interpreted to be exactly as broad as the GPL-3 in terms of what works are to be considered derivative; it makes no special mentions of derivative works, so it's likely to be assumed that it implicitly covers all such works. As another example, the Artistic license is extremely broad in what it claims as derivative works, making only a single exception for works which are "separable" or "merely link [...] to the interfaces of [the work]". It would be up to a judge to determine what constitutes "separable", or an "interface" as opposed to the internals of a work. The LGPL similarly provides a exception such that certain classes of derived works may be distributed more loosely, but is constructed such that it still requires interpretation in a social context to determine if an application is faithfully interpreting the terms. It's important to not get hung up on technical computer science distinctions when considering licenses. The law is not a program, and cannot be treated as a machine; it is inherently social and flexible, with the context and intent of the parties involved always taken into consideration. Any license which exactly and precisely laid out what constituted a derivative work would be a bad license; such a precise enumeration would inevitably have both loopholes which prevent what most people would consider "morally derivative" works from being considered as such, or loopholes which cause the licenses interpretation to be overly-broad and thus likely to be less enforceable in court, or most likely both. In practice, it is often best to simply amend your license of choice with an additional statement of your intent as an author. For example, a friend of mine has written a library which she released under the GPL-2, but with an additional statement saying that any use of it which is restricted to a particular documented interface does not, in her opinion, constitute a derivative work; that library is in use in proprietary software, and everyone involved is fine with that situation and happy that nobody needs to be sued. Compilers often are released with an additional statement saying that the output of the compiler is not considered a derivative work; without such a statement, that situation is far from clear. And because licenses are inherently social, you should never forget that they are subject to negotiation. I've written code and had people email me asking if they can incorporate it in some other work with an outwardly-incompatible license. The purpose of strong licenses like the GPL, as far as I'm concerned, is to get changes to the code I wrote sent back to me; usually I will simply ask if they are making any changes to my code, and if they are not, I will readily agree that they are allowed to use my code. In the one case where someone was modifying my code and wanted to incorporate it in something with a separate license, I was able to work with them to get the interesting changes they needed to make sent to me as a patch, and then happily agreed that they could proceed with incorporating my (now with no significant differences from upstream, as far as I'm concerned) code. The Gripper posted:I'm sure it's a fine license for someone who has created an original work and wants to give back/receive from the community, but it's an absolutely awful choice for a developer looking to make use of a GPLed original work in their new non-derivative original work. This is sort of a critical point; if you think your new work is non-derivative of some GPL work, and you believe you can defend that outlook, then you're done. The GPL cannot extend the legal status of a derivative work past what copyright law allows. But you should consider that the tests for derivative works are usually along the lines of "Could X have been created if Y did not exist? If not, then X is a derivative work of Y" which is, needless to say, incredibly broad. In the free software world, authors have a vastly reduced sense of personal ownership, but that's merely by convention and isn't in any way true of the general state of software law. To put it another way: If Microsoft claimed that every piece of software that has been written to use the Win32 API was derivative of their code and should be subject to their licensing oversight, and they had not previously made statements to the contrary in their licenses, then I believe that a judge in the USA would find in their favor. In the proprietary software world, corporations frequently negotiate with eachother over use of code; there's no particularly good reason to believe that the broad and unspecific licenses we use for free software should be universally applicable to the situations our code is used in. Fair use is a far less broad protection in the software industry than most free software authors expect, and companies hate to depend upon it. I've found that if you're willing to send quick "hey, can I use this?" emails to people, the situation is just easier for everyone.
|
|
#
¿
Feb 5, 2013 23:53
|
|