In response to Foomer
Yes, the overall meaning was nothing about how linux is better than windows(even if that is true), the point was that windows doesn't let the user know when things are happening when it should. This is the root of these problems. They have been working this control back in, like blockign activeX controls by defualt, but they still have a lot of making up to do. The less the developer knows about what is happening in his game, the less he has control over it.
Encrypting Lib's isnt a good idea, somone could use this to there advantage and add in exploits or little secrets to gain control over a game.
In response to Wizkidd0123
Wizkidd0123 wrote:
Then it isn't eligible to be published. Still, that's one reason I don't want password-protected .dm files: MKany libraries DO need touching hup. For example, up until just recently, Deadron's Character Handling library had a bug that made its default behavior go all screwy when a player tried to delete his/her character. Thankfully, this has been fixed, but you get the point. This, in my opinion, would be a horrible, horrible step for BYOND to take.

That would have been fixable without the source. Subclassing would have been sufficient.

Nope. Lummox JR's libraries generally work in any situation. Actually, that's the whole purpose of a library: to work in any situation.

Libraries are best when they can be used in unanticipated situations, but they are not necessarily designed to be used in any situation. They may only apply to a game the fits certain criteria, by nature. A turn-based library probably will not apply to a non-turn-based game.
In response to Deadron
Deadron wrote:
That would have been fixable without the source. Subclassing would have been sufficient.

True, but there are libraries out there that need the source to be fixed.

Libraries are best when they can be used in unanticipated situations, but they are not necessarily designed to be used in any situation. They may only apply to a game the fits certain criteria, by nature. A turn-based library probably will not apply to a non-turn-based game.

Apply? Maybe not. But it should still work.
In response to Wizkidd0123
Wizkidd0123 wrote:
Apply? Maybe not. But it should still work.

Not necessarily. A library may rely on conditions that not all games can support.

A library that supports pathfinding based on BYOND's coordinate system is not going to work if your game uses your own coordinate system. (I bring this up because I can't use my own pathfinding library for the board game I'm currently working on, for this reason.)
In response to Deadron
Deadron wrote:
Not necessarily. A library may rely on conditions that not all games can support.

Good point, but I still absolutely hate the idea of encryptedlibraries. I can remember many times when I've needed tomodify a library, and some when the documentation wasn't adequate, so I had to look at the code to figure the lib out.
In response to Wizkidd0123
Well, I want some kind of possibility to encrypt a .DM file.
This way, I can save the core coding inside another .DM file and the implementation coding in an unencrypted one.

I just don't want people messing with my code! Yes, I want to give them my coding, but I don't want them to alter some parts of it so that they can make it look like they made it.
In response to Phoenix Man
Phoenix Man wrote:
I just don't want people messing with my code! Yes, I want to give them my coding, but I don't want them to alter some parts of it so that they can make it look like they made it.

I think I'll just have to go back to the statement I made to some other guy who posted a similar remark about not wanting people to steal his icons.

If you're that paranoid about having your code stolen, I would suggest just not releasing it.
In response to Phoenix Man
Dude, seriously, CHILL. I used to dislike releasing my code as well, but then I realised I was being silly about it.

If you don't want people looking at your code, don't release it. Face it; pre-compiled DM libraries are NOT GOING TO HAPPEN. End of story.
In response to Crispy
Reminds me of those sites that try to block people from viewing their source code. I always laugh at them and find a way to view it anyway, just to spite them. I should start e-mailing them their code back. :)
In response to Foomer
Foomer wrote:
Reminds me of those sites that try to block people from viewing their source code. I always laugh at them and find a way to view it anyway, just to spite them.

View->Source. Or turn Javascript off. =D

I should start e-mailing them their code back. :)

"Dear Webmaster,

Your attempts at stopping people from viewing your source code are futile and pointless. It's pointless because NOBODY CARES ABOUT YOUR HTML; and to prove the futility of such an exercise, the HTML for your entire site follows. Enjoy.

*huge HTML dump follows*

Sincerely,
Very Amused."

That would be so mean, but yet... so funny. =P
In response to Phoenix Man
Phoenix Man wrote:
Well, I want some kind of possibility to encrypt a .DM file.
This way, I can save the core coding inside another .DM file and the implementation coding in an unencrypted one.

I just don't want people messing with my code! Yes, I want to give them my coding, but I don't want them to alter some parts of it so that they can make it look like they made it.

actually, i think someone around here made an encryption library in DM, and i believe there is an md5() function in BYOND now anyway. you could parse your files through either of those, but you have to do all the encrypting and decrypting (maybe retrieving a special key from your server or website?) which would slow your game down considerably since the encrypted library would probably not be compiled into the game as a whole. (and this makes it worse if someone is using several libaries from you).

heck even if this feature was 'built-in' into BYOND, you would get noticeable delays in game play because the library would need to be encrypted and decrypted 'on-the-fly' whenever it called a function, unless you could store the entire un-encrypted library in memory (reduces processing lag, but not much better), which could lead to a *whole* other set of issues in memory management, not to mention someone could be industrious enough to do memory dumps to see your code in the end. (gah! talk about run-on setences! :D )

taking another way, your encrypted library could be 'de-crypted' before being compiled into the game. but that might require you giving DanTom a 'passkey' for decrpyting *your* library. this may also require adding functionality to store these passkeys for anyone who wants to encrypt their libraries. think of the headache involved in trying to decide where best to store these passkeys? in the DM editor? in another (encrypted) file? on the BYOND server? (which would require an active net connection- sucks for those who make offline or local network games). not to mention the endless discussion over the best method for encryption ("smaller!", "faster!", "more secure!", "gah!").

and what if your encrypted file does not have feature 'x' which may something that a game developer thinks you ought to have in your library (for robustness, let's say), or it has an error or behaviour you did not expect? that person has to stop his game-development in order to contact you, converse with you (over hours or days). this would be time better spent if the developer can just look at what you coded and directly make the changes necessary for his situation. ideally, that person would send the changes back to you so that either a) you can incorporate them into the next version of the library, or b) return with an improvement over that person's hacks ('oh! i know what you mean now! here is an even better way!' - kind of thing).

if you have ample documentation about your library, and make it available for public use, there will be little worry about people 'stealing' anything since you could recognize it right away. besides, making it available for public use means you freely offer it for people to use how they see fit, modifying and improving it if possible. you just need to maintain *the original* and be opened-minded enough to incorporate improvements or fixes that others suggest. this is how Open Source Software works, basically.

so if someone screws up your library and uses it elsewhere (or even tries to sell it), then that is their problem, not yours. you can be happy knowing that *your* library is the original, and works. let others use it how they like- they will all come crawling back to you when they break it (if it is really important to them). then you can sell them support to fix it! (another OpenSource concept)

:D
I have suggested a similar feature, though encrypted DM files is not the way to go. As some others have said, you could put in junk that you don't document which gives you control over the library user's game. As I stated elsewhere in a past thread, the way to go is to have DLL style files that creators can use to include specific functions and/or variables into their code. Even then, safeguards would have to be added in which makes the idea less appealing than it otherwise would be. The base idea, however, is a good one.

Concerning all the annoying statements against it, get over yourselves. "If you don't want people using your code, don't release it." What the heck kind of statement is that? He never said he did not want people to use it. Besides, I could just as easily say "If it's not good enough for you uneditted by yourself, don't use it."

Open source may be better, but that doesn't mean people who want to keep the source hidden shouldn't. If you need a different sort of output than one a certain function gives, just make a function that takes that output and input it into a function of your own that makes it how you want. I quite often have functions that do little more than call another function and alter its output.

That said, you should still weigh carefully the balance of all sides. If the function just takes the input and spits some data out without actually altering anything (such as a decimal2hexidecimal function) then there is probably no need any programmer would ever have to edit it. On the other hand, if the function alters external data (such as Byond's Move function) then the programmer will probably have to alter it if he wants to change movement in any way. If it is the former, nobody should have any objections to someone keeping the process hidden; it's not meant to learn from (it would be nice if the programmer made it open if it is something many people would want to learn, but that is an argument about manners for another day). If it is the latter, then the programmer has no reason to keep the code hidden unless he wants to force all games that use it to be identicle where it is concerned, which may be a good idea in some cases but is not in general.

Lastly, I want to bring up another use such a system (in this case encrypted DM files would be better than my suggestion) would have. If I am making a game and I want to give the job of making the map to someone else, I could just use the encrypted DM system to easily hand the project over without having to worry so much about abuse. That seems to be one of the biggest sources of code leaks that plague us - the people who offered to do the maps give the project out. Similarly, if someone came to me and asked for my permission to make an expansion (not too uncommon, I can think of some instances where one professional company goes to another and obtains permission to make an expansion for their games and does so) I could do the encryption thing and hand it right out without a second thought.
In response to Loduwijk
Loduwijk wrote:
If I am making a game and I want to give the job of making the map to someone else, I could just use the encrypted DM system to easily hand the project over without having to worry so much about abuse.

Or you can just pass over a bare-bones turf list that reduces the map maker to little more than a tile-based MSpaint, and have the map maker pass the plain map back. I was doing this just last night. :)
In response to Loduwijk
Lastly, I want to bring up another use such a system (in this case encrypted DM files would be better than my suggestion) would have. If I am making a game and I want to give the job of making the map to someone else, I could just use the encrypted DM system to easily hand the project over without having to worry so much about abuse. That seems to be one of the biggest sources of code leaks that plague us - the people who offered to do the maps give the project out. Similarly, if someone came to me and asked for my permission to make an expansion (not too uncommon, I can think of some instances where one professional company goes to another and obtains permission to make an expansion for their games and does so) I could do the encryption thing and hand it right out without a second thought.

The map editor in DM is great for doing maps for ismple games or making up maps for testing game functionality. But if your project is so big that you need someone else to do the map data for you it would probably best if you just built your own map format and editor.
In response to Theodis
Theodis wrote:
The map editor in DM is great for doing maps for ismple games or making up maps for testing game functionality. But if your project is so big that you need someone else to do the map data for you it would probably best if you just built your own map format and editor.

But, that still wouldn't give 100% functionality as the built-in editor. And, the built-in one rocks! Especially the object tree, the new instances, and the locating. Sure, you could program all that - but, it'd be sort of a waste of time. That, and actually saving the map (s) could lead to some problems. File size, corruption, etc...
In response to Teh Governator
But, that still wouldn't give 100% functionality as the built-in editor.

If you do it right you get that and more since you're loading the data dynamically so you can build the map based off data that doesn't have to be statically compiled into the project meaning you can seperate even more data that shouldn't be hard coded into a large scale game.

And, the built-in one rocks! Especially the object tree, the new instances, and the locating.

But it all has to be built at compile time which means all item data must also be included in the source rather than being able to have it in seperate data files. Which means you need to also distribute source for new items to be added and the game must be recompiled. If you do it like my Racing Game and keep the data seperate from the code you can add maps and new cars without touching the source code or recompiling which not only is cool but if you have a lot of source code you'll be saving yourself a lot of time spent compiling to add things that shouldn't need recompiling.

Sure, you could program all that - but, it'd be sort of a waste of time.

Well by wasting you time doing this you seperate your data from your code allowing other people to work with it without needing to touch your code or needing to recompile to add new stuff. Not to mention there are several limits in BYOND as far as object nodes and variables go which you won't need to worry about as you should only have a few base nodes with data from files defining their attributes rather than seperate object nodes.

That, and actually saving the map (s) could lead to some problems. File size, corruption, etc...

These are all problems with the built in type. For instance I can't physically store my Space Game map data as dmp files because there isn't a harddrive with enough space avaible now or probably in awhile to do that. It is much cheaper and easier for me to work with when I just store the planets and stars as locations with their associated data as there is far too much empty space to bother storing like the dmp format would do. File corruption can happen as easily to dmp files from the BYOND editor as a well written external tool.
In response to Theodis
Dagnabbit Theo, now you're going to make me build my own map format. And here I had this nice editor that converted things into DMPs...
In response to Foomer
Foomer wrote:
Dagnabbit Theo, now you're going to make me build my own map format. And here I had this nice editor that converted things into DMPs...

/me wonders if he can get that editor. >_>
In response to Teh Governator
Teh Governator wrote:
/me wonders if he can get that editor. >_>

Perhaps. But as I'm too lazy to clean up the code, comment it, and provide some usage instructions, you wouldn't get much benefit from having it.
Page: 1 2 3