301
Add-Ons / Re: [Event] Apartment - Landlord like a boss
« on: September 12, 2016, 04:22:53 PM »
Oh, yeah, someone need to poke this so it wont go below the perimeter of binned topics.
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
I haven't touched this much since then, I've been focusing on Glass Hosting as there's a greater need for that and it'll actually end up paying to keep the Glass servers themselves up.No rush! I just wanted to let you know so you could put it way down on your todo-list. Unless you want someone else to poke into it. As I mentioned to one of you, my offer to help is still open.
Thanks. I'll look to see what specifically is causing that.I checked now after a couple of weeks and it looked better, but now it got other errors:
<span class="mu_global">$InputTarget_[<span class="mu_text">"</span>;Self"</span>] = <span class="mu_local">%brick</span>;</span>What I see is the semicolon before the name. I see a nestling of tags where they should probably not be.I can't believe I've edited this mod for a long time and didn't realize that was there. (Is Dediloader not good enough credits?)It is a mess. By rewriting it you ensure high quality, a possibility to remove people from credits and make it easier to add new functionality.
Code is a complete mess, I'm determining if I should rewrite this or not.
(Is Dediloader not good enough credits?)No, it definitely is not. It could give false assumptions for an another add-on, as there is a few out there with the same functionality.
Ah, you were the one who wrote this, I'll include the original credits. I'll apply more updates when I get back home. Thanks for posting.
// Writes information from a file to an another file - Stole from DediLoaderserver.cs:47so from what i understandWell, if you read it, it's more that it first hashes the password, then it hashes that with other variables together to make an another hash. To guess the password is almost impossible. Also, this system is only to make sure that you each time you send a request it makes sure that the content haven't been tampered with and that you are what you claim you are. As it says in the wiki:
menu connects to blockland over a TCP connection
menu asks for a username
blockland creates an expected hash from the username (if it exists), and the password sha1 hash (which i don't trust. at all. i'd rather use an external script to do all of this over sha256)
and if it works they get in etc etc blah blah, hash is sent with each command
These enhancements are designed to protect against, for example, chosen-plaintext attack cryptbrown townysis.Yes, sha-1 is not a secure hash anymore, but when did you care about security in Blockland? It is also worth noting that even if it's insecure as it is broken, you still cannot decrypt it and need to guess what the hash contains by looking in a rainbow table.
{
"nonce" : "346gw3e6hw3h6se5h6",
"opaque" : "90834g6908w3609g"
}Then the client responds:{
"username" : "YourName",
"algorithm" : "sha1",
"nonce" : "346gw3e6hw3h6se5h6",
"nc" : "00000001",
"cnonce" : "8s3498",
"opaque" : "90834g6908w3609g",
"response" : "59e7b54eeef1a5d84aa99d19f3ef5bc6f11f4a8a",
"action" : {"cmd":"dostuff"}
}So, the client is sending back what the server requested and a bunch of other data that will identify it.nonce = Random. It is like a token that is used for this connection
cnonce = Random. Issued by the client as an extra hash
response = algorithm(algorithm(username:password):nonce:nc:cnonce:algorithm(action))The action is hashed directly like so:algorithm({"cmd":"dostuff"})On the server, the password is saved hashed with username. It's not perfect, but it will add some sort of security to avoid people to tamper with your server without your credentials. And as mentioned earlier, it's almost impossible to guess it unless someone have put it into a rainbow table. The only way to actually try to get into the system is to decrypt one of the response hashes and find the hash for the username and password pair.working on itDigest access authentication
the idea i have is to create a TCP server on blockland that the menu would connect to for interfacing. i plan on letting the menu generate a key/random string each time the server is started, and that key would be sent with each command to prevent someone just coming in and wreaking havoc
I've been working on a new script inspector, primarily for reviewers. It's certainly not mobile compatible and probably won't work well with smaller displays, and given my experiences with JavaScript and Firefox, it probably won't work on that either. I'll be making small improvements on that to try to replace the current review system.I think you already know it, but it could be worth mentioning:
<span class="mu_global">$InputTarget_[<span< span=""> class="mu_text">"Self"</span<></span>]So all I have to do is event a baseplate and they can build on it?That's the gist of it.
There's actually a vector parameter type, those are already handled.Oh, I saw that you did rotation for fireRelay[direction], but might have missed the vector part. Good that was already done.
Ok, I've added something here if you want to test it: https://github.com/Zeblote/Tool_NewDuplicator/commit/7562957d839c19a2c3abbc4063f6c9a28ad2f4a5?ts=4I've tested it and it works perfectly. Great job there. Thank you.
Seems to work fine with the default events.
Missed this post somehow.Pewh... You almost got me worried there.
Having add-ons implement their own rotation is a bad idea, as everyone would have to make a seperate loop over all events and it simply stops working when someone does it wrong.Yes, it is bad and that's why I asked if you could somehow implement it. You could just read the current list of names ($OutputEvent_parameterList) and use that as the rotation.
I guess I can add a generic solution that will detect directions in drop downs (up, down, north, east, south, west?) and attempt to rotate them. Maybe use a lookup table aswell to not lose performance with many rotated events.
I'm not sure about the named brick that's not in the selection. I can disable rotation for those, but won't it get confusing if you have one named brick in the selection and another with the same name out of it?No matter how you do it, it would break anyway. Just set a standard and people are obliged to follow it. In this case, don't do a thing. The problem is way too big to handle and you would require som sort of list to be displayed to the user to take certain actions for these kind of issues, and that would just make it way too complicated.
// Handle New Duplicator
function ND_Selection::plantBrick(%this, %i, %position, %angleID, %brickGroup, %client, %bl_id)
{
%brick = Parent::plantBrick(%this, %i, %position, %angleID, %brickGroup, %client, %bl_id);
// Handle error
if (%brick <= 0)
return %brick;
// Locate our event
for (%n = 0; %n < %brick.numEvents; %n++)
{
if (%brick.eventOutput[%n] !$= "fireRelayNum")
continue;
// Get direction and normalize it
%dir = %brick.eventOutputParameter[%n, 2] - 1;
if (%dir >= 0)
{
if (%dir >= 2)
{
if (%this.ghostMirrorX && %dir % 2 == 1 || %this.ghostMirrorY && %dir % 2 == 0)
%dir += 2;
%dir = (%dir + %angleID - 2) % 4 + 2;
}
else if (%this.ghostMirrorZ)
%dir = !%dir;
// Put direction back as it was
%brick.eventOutputParameter[%n, 2] = %dir + 1;
}
}
return %brick;
}Thank you, regardless I'm still going to use this because it's badass, I'll just have to redo the house is all, but then they can make their own floor and suchThank you for being so polite. Too bad I couldn't be of much help. It is always recommended to use as few baseplates as possible for each owner to avoid this kind of thing to happen. I'll update first post about this issue.