hidden/password protected folder

Page: 1 2
ID:158018
 
Nov 16 2009, 6:37 am
 
proc
    pl_savecharacter(mob/M as mob)
        var/savefile/F = new("characters/"+lowertext(M.name)+".sav") //create a savefile in the directory of "characters', witht he name of the characters name.
        F["old_x"] << M.old_x // Save their last coordinates.
        F["old_y"] << M.old_y
        F["old_z"] << M.old_z
        F["password"] << M.password // Save the password.
        M.Write(F) // Write all values of each variable stored within M.
        del(M) // Deletes the physical mob.
    //pl_loadcharacter(S as text,mob/M as mob)

that a file i use to save my characters for yet another project my teams working on is there any way to make it so that the folder created for this game becomes a hidden folder or a folder that needs a password to access.
and i mean so it automaticly becomes hidden or password protected and not done manualy
Nov 16 2009, 7:47 am
I can imagine if it's possible at all that it's going to require use of shell() which requires the host to approve it anyways. I can imagine your only purpose for this request is to prevent savefile edits or deletions by a third party host, and all I can say is good luck. If you don't trust them enough to not delete the files outright and your game can't survive a few simple edits, then you'd save a lot of trouble by hosting yourself, or procuring a server under your control that you can host with.
Nov 16 2009, 8:48 am
Not really related to your problem, but I find this line in your snippet rather odd:
var/savefile/F = new("characters/"+lowertext(M.name)+".sav")


This is better:
var/savefile/F = new("characters/[lowertext(M.name)].sav")
Nov 16 2009, 11:41 am
In response to Nielz
It's not odd at all, why would you think that?
Your "better solution" is, in fact, slightly slower, and it's only any better to someone that has trouble reading the first way, but a lot of people don't, partly due to it being the way to go in other languages.
P.S. FYI, there's also another valid way to do this, using the text() proc (not that there's much incentive to bother with that in DM).
Nov 16 2009, 11:50 am
In response to Kaioken
I see...
Well I don't have any experience with other programming languages, and this is the first time that I've ever seen it written this way in DM, so...
Nov 16 2009, 11:56 am
In response to Kaioken
Your "better solution" is, in fact, slightly slower

Do you have the numbers on that? I'm curious now. They're doing pretty much the same operations, as far as I can tell.

I would recommend use of [] for inserting stuff into text in DM, by the way, mostly because it's idiomatic usage. Sure, you can write DM like this:

mob
{
    bob
    {
        New()
        {
            world << "A new bob!";
        }
    }
}


But most people don't.
Nov 16 2009, 12:26 pm
In response to Jp
Jp wrote:
Do you have the numbers on that? I'm curious now.

Not at the moment, but I tested it once for the heck of it.

They're doing pretty much the same operations, as far as I can tell.

They're not. For one, embedding expressions most likely needs to do more operations (such as type checks, computations and the like), since it generally has different behaviors for each value type, more than +'s handfuls (which also mostly produce different results).
Nov 16 2009, 12:44 pm
In response to Kaioken
Kaioken wrote:
They're not. For one, embedding expressions most likely needs to do more operations (such as type checks, computations and the like), since it generally has different behaviors for each value type, more than +'s handfuls (which also mostly produce different results).

Yeah, and if I'm not mistaken the '+' operator is assigned to each class so it's more specific to the types. It doesn't need to go through the process of determining what type of data it is processing. Whereas the embedding version 'does' need to determine all of that because it's not type-specific so it has to establish the data-types it is playing with.

So the the simple '+' method has less to do, therefore it should be faster, but yeah, there are still no figures to support this.

I could be totally wrong, but that's how I imagine it works. I remember overloading operators in C++, many times I overloaded the '+' for the classes/data-types I created.

I personally use the embedding version myself, don't know why, it's just how I've been doing it from the start.
Nov 16 2009, 12:51 pm
In response to Kaioken
They're not. For one, embedding expressions most likely needs to do more operations (such as type checks, computations and the like), since it generally has different behaviors for each value type, more than +'s handfuls (which also mostly produce different results).

"some string" + a
"some string [a]"

Both need to convert 'a' to a string.
Both need to append 'a' to an extant string.

I don't see any further operations that have to be done in either case.

Although it's bizarre that they produce different results. What specific cases are you referring to?
Nov 16 2009, 1:32 pm
In response to Jp
I would go so far as to say that, at least intuitively, string1+string2 concatenation should be slower, if anything. It would seem reasonable that string1+string2 would be the one to have to go through extra type checks, if either does, and that "[string1][string2]" would not.

If you are adding two things together, it has to be checked as to whether those things are both integers, if not is the first one a string, is it something else? If they're both integers, add them as numbers, if the first is a string convert anything else to a string and concatenate, if the first is not a string and neither is a number then error.

For "hi[var]" I would think it would not need to do any of that and would just automatically go to converting var to a string without checking anything else, and it wouldn't need to check to see if the rest is a string at all. It just goes straight to concatenation.

The fact that they could end up different at all is something I would not have ever thought to bother checking, and the fact that it's the other way around from this logical assessment is just odd.
Nov 16 2009, 1:46 pm
In response to Jp
Jp wrote:
I don't see any further operations that have to be done in either case.

They both need to first check, at runtime, the types of the values used, in order to know what operation to take.

Although it's bizarre that they produce different results.

Bizarre? Wow, to someone like you this should be common sense.

What specific cases are you referring to?

Examples:
"aaaa" + 3 //type mismatch error
"aaaa[3]" //works; also, it checks if the number has more \
than 6 digits and if so, converts it to scientific form.

"aaaa" + new /list //type mismatch error
"aaaa[new /list]" //produces "aaaa/list"

... etc etc.
Nov 16 2009, 1:48 pm
In response to Loduwijk
Loduwijk wrote:
For "hi[var]" I would think it would not need to do any of that and would just automatically go to converting var to a string without checking anything else,

It does convert the value to a string, but to know how to do so it has to first validate its nature and type (which obviously has to be done at runtime, since in DM any var could hold any value type).

and it wouldn't need to check to see if the rest is a string at all. It just goes straight to concatenation.

How would it possibly go straight into concatenation, when the value types that can be used in an embedded expression are much more than just strings?
Obviously enough, + also works on the same principle, since it can also take non-string args.
Nov 16 2009, 2:03 pm
In response to Kaioken
Kaioken wrote:
It does convert the value to a string, but to know how to do so it has to first validate its nature and type (which obviously has to be done at runtime, since in DM any var could hold any value type).
How would it possibly go straight into concatenation, when the value types that can be used in an embedded expression are much more than just strings?

I have used the wrong words again. Sometimes I am one of my own worst enemies.

"automatically go to converting var to a string without initially checking anything else." That is, without checking up front to make sure it is even possible, as it must with string+string concatenation, since, with the latter, you don't even know ahead of time if the expression is valid in the first place.

If name=Bob, "hi[name]" is "what type is name? do that type's conversion to string and concatenate."

Alternatively, "hi"+name is "We have a plus, what type is on the left? String. Do string's + operation (concatenation) with right-hand side. What type is name? do that type's conversion to string and concatenate."

One little extra step, because it has to actually determine that it wants to concatenate in the first place. Not that this is significant in the least and worth caring about, but I just didn't see how it could actually be faster.

And heck, depending on how it is set up, it doesn't even necessarily have to check to see what type of data it is to convert to a string first. Byond is written in C++, so for all we know the class that handles a var could just have a pointer to something that handles whatever type of variable it contains. For that matter though, the same could be said of checking the + operator first too.

It all depends on how it was implemented, but I would still have thought that "text[var]" would have the edge over text+var, if any edge were to be had at all.

Whatever. Now I've spent more time thinking about this than it's worth.
Nov 16 2009, 2:13 pm
In response to Loduwijk
Oh my, I've brought up an argue war

*tip-toes away*

:D
Nov 16 2009, 4:43 pm
In response to Kaioken
They both need to first check, at runtime, the types of the values used, in order to know what operation to take.

That's in the string conversion. I'm guessing at virtual functions and inheritance, rather than a big if-then statement.

Bizarre? Wow, to someone like you this should be common sense.

Believe it or not, I've never actually tried to add a number and a string in DM, and I assumed it would work like it does in Java - call string conversion on the non-string types, append. Just tested that then. Interesting.

Probably another reason to consider embedded expressions the idiomatic DM construct over the + operator for string concatenation - it's more robust.
Nov 16 2009, 4:52 pm
In response to Kaioken
The bytecode generated probably does something like this, to give you an idea of what I'm thinking of:

"a[b]"->
evaluate b
read tostring pointer from b's function table
call tostring
push pointer to a
call append

"a"+b->
evaluate b
check b's type == string
if false error
push pointer to a
push pointer to b's result
call append

In the case of appending strings, the latter will probably be faster by just a bit, depending on how expensive calling an empty virtual function is compared to doing a type check. But I imagine it's only slower by a pointer dereference or two, which should barely show up.

Disclaimer: I have no idea what DM bytecode looks like.
Nov 17 2009, 2:53 am
In response to Jp
Jp wrote:
Believe it or not, I've never actually tried to add a number and a string in DM, and I assumed it would work like it does in Java - call string conversion on the non-string types, append. Just tested that then. Interesting.

num2text() ?
Nov 17 2009, 3:11 pm
What I have been working on in situations where I need to protect a file that users will readily be able to access is to to use md5() to create a hash of all the values used in the file, and save that md5 hash as another variable in the file. Then, when you attempt to load the file, make sure that all the saved values (except for the md5 hash) match the md5 hash value. If the values attempting to be loaded don't match the hash, then the values have been altered and the file has been modified. So you can safely refuse to load a modified file.
Nov 17 2009, 3:40 pm
In response to Foomer
Note that that is not actually particularly safe, and you should be storing the hash in a separate file and running the whole file through md5() instead.

But I think I've brought this up before and explaining it would just encourage people, I'm sure.
Nov 17 2009, 7:22 pm
The only way I can think of, is to make .dll, which would make your folder hidden
Page: 1 2