- ComputerCraft | Programmable Computers for Minecraft
- → Advert's Content
Advert's Content
There have been 441 items by Advert (Search limited from 30-March 23)
#11780 Local Variables
Posted by Advert on 06 May 2012 - 09:39 PM in Suggestions
I don't think this will happen. You can create files that contain these computer specific variables.
It'd also be wise to check if the name you've chosen is already in use, to prevent confusion.
It'd also be wise to check if the name you've chosen is already in use, to prevent confusion.
#11051 <Request> Inventory help.
Posted by Advert on 29 April 2012 - 10:42 AM in Ask a Pro
You can use a table:
You'll probably want to make it a bit more sophisticated, though. For example, this example uses strings to store which items you have -- I'd probably want to use a table for those.
You might also want to use a separate table for the reverse lookup, since it'd be easier to clear it.
local items = { "Bear meat", "Piano", "Delicious Creeper Supreme" }Then reverse it:
for k, v in pairs(items) do items[k] = v end print(items["Piano"])
You'll probably want to make it a bit more sophisticated, though. For example, this example uses strings to store which items you have -- I'd probably want to use a table for those.
You might also want to use a separate table for the reverse lookup, since it'd be easier to clear it.
#10829 Code revision
Posted by Advert on 27 April 2012 - 03:14 PM in Ask a Pro
Glad I could help.
Keep in mind that if you want to do pathfinding, you'll want to optimize your code quite a bit.
For your updated code, I have a few recommendations:
In the worker prototype, you're adding a vector. I'd recommend moving this to the __construct function, so you get a different vector per worker, automatically.
For your getFacing, function, I'd recommend using a table to store all the facing values:
Alot is very welcome.
Have fun with your pathfinding, it can be quite tricky />
Keep in mind that if you want to do pathfinding, you'll want to optimize your code quite a bit.
For your updated code, I have a few recommendations:
In the worker prototype, you're adding a vector. I'd recommend moving this to the __construct function, so you get a different vector per worker, automatically.
For your getFacing, function, I'd recommend using a table to store all the facing values:
local facings = {{1, 0}, {0, 1}, {-1, 0}, {0, -1}} local facenames = {"North", "East", "South", "West"}
Alot is very welcome.
Have fun with your pathfinding, it can be quite tricky />
#10821 Code revision
Posted by Advert on 27 April 2012 - 12:11 PM in Ask a Pro
You're welcome />
Yes, although it means checking yourself:
Kind of, with the above example you can check metatables:
All in all, there are many ways of doing OO in Lua, though I'd recommend just doing it the prototype way.
Yes, although it means checking yourself:
function someFunction(sAString) if type(aString) ~= "string" then return nil, "someerrormessage" or error("some error") end endI generally would try to return nil, "error" if you return an object, since you can then do x = assert(someFunction(...)), or try to fix it without stopping the program.
Kind of, with the above example you can check metatables:
if getmetatable(obj) == Vector then --it's a Vector endIf you're using the above example and you've extended a 'class' a few times, you'll have to loop through the metatables, if you want to know if it inherited stuff from another 'class'.
All in all, there are many ways of doing OO in Lua, though I'd recommend just doing it the prototype way.
#10817 [1.32] Yet another Persistent Variables API (uses metatable)
Posted by Advert on 27 April 2012 - 11:53 AM in APIs and Utilities
dotsonface, on 27 April 2012 - 05:35 AM, said:
I've looked at the forum and in about a 15 day span 3 different Apis that claim to do the exact same thing except differently in some way shape or form just appear on the front page of the API list. Other than that.
Your script is much cleaner than the other two, good job.
Your script is much cleaner than the other two, good job.
But horribly inefficient compared to them.
If you have a lot of data, calls to serialize will be expensive, in addition to filesystem calls.
#10809 Code revision
Posted by Advert on 27 April 2012 - 10:00 AM in Ask a Pro
I haven't looked over it thoroughly, but here are my .03$:
First and foremost, Lua isn't an acronym (i.e it's written 'Lua').
TL;DR: I would say that you're heading in the wrong direction! I'll explain why below.
You're doing stuff very inefficiently, and your 'class'es aren't re-usable (i.e you can't use them for something else without a butload of code).
1) You are creating new functions for each object: This will cost you more as the are created, but less as you call their functions (but you can do this with metatables, too).
From looking at your code, you don't seem to need to be doing this; You could use a metatable with a crafty index function instead.
An example of what this would look like is at 3).
2) Instead of doing:
I'll also put this in here, since these two are somewhat minor points:
A (micro) optimization: Instead of using obj.x/y/z, you could use obj[1/2/3]: This is faster and more memory efficient, since you would be accessing an array, instead of hashing and finding the value.
3) Now that I've explained some things, I'll show you what I'd say is a better way to create one of your classes, and you can derive your other classes from it:
I'll update this in a few minutes once I'm done cooking it, but I'll leave this post here for now so you can read it />
Edit: Here: http://ideone.com/4lmsa
Feel free to ask any questions, since I may have derped somewhere.
First and foremost, Lua isn't an acronym (i.e it's written 'Lua').
TL;DR: I would say that you're heading in the wrong direction! I'll explain why below.
You're doing stuff very inefficiently, and your 'class'es aren't re-usable (i.e you can't use them for something else without a butload of code).
1) You are creating new functions for each object: This will cost you more as the are created, but less as you call their functions (but you can do this with metatables, too).
From looking at your code, you don't seem to need to be doing this; You could use a metatable with a crafty index function instead.
An example of what this would look like is at 3).
2) Instead of doing:
local getX = function() -- You could do: local function getX()Which I'd argue is more readable (although they are technically equivalent).
I'll also put this in here, since these two are somewhat minor points:
A (micro) optimization: Instead of using obj.x/y/z, you could use obj[1/2/3]: This is faster and more memory efficient, since you would be accessing an array, instead of hashing and finding the value.
3) Now that I've explained some things, I'll show you what I'd say is a better way to create one of your classes, and you can derive your other classes from it:
I'll update this in a few minutes once I'm done cooking it, but I'll leave this post here for now so you can read it />
Edit: Here: http://ideone.com/4lmsa
Feel free to ask any questions, since I may have derped somewhere.
#10405 POOPing in ComputerCraft
Posted by Advert on 24 April 2012 - 04:51 AM in Tutorials
bonobot, on 24 April 2012 - 12:19 AM, said:
I do note that I did mistake to put (self) in the method I don't suggest using, (slapping a function as a value for a table key, inside the table block {} ). However...
Referencing the way I suggested, works wonderfully and is very legible:
Referencing the way I suggested, works wonderfully and is very legible:
yourMom = { weight = 9001 } function yourMom:isFat() if self.weight > 9000 then return true end end if yourMom:isFat() then print( "SUPER FAT!" ) end hisMom = yourMom hisMom.weight = 8000 if hisMom:isFat() then print( "SUPER FAT!" ) endPrints "SUPER FAT!" once.
That doesn't work properly.
You are creating a reference to the table in yourMom when you do that, and modifying that. If you were to call yourMom:isFat(), it would fail.
Your tutorial doesn't work either, as you are doing the same thing there.
Also note that, It'd be much simpler to have a function take two arguments, rather than do all this work for underlining:
function underline(char, text) ... end underline("^", "Some random text")
#10127 [Critique Request] Please tear apart my code!
Posted by Advert on 22 April 2012 - 02:13 AM in Ask a Pro
Alright, I've had a chance to look over it again now.
I see that you're duplicating a lot of code, to get input. Making a function to do this would make your code clearer.
In your home function, you have a lot of other functions, that don't really serve a purpose, I'd move them out of home(), and send arguments to them instead of using upvalues.
When you're taking a password, I'd recommend using read("*"), which will asterisk out the password, then having the user confirm by typing in the password again.
When logging in, take a username and password regardless. Error at the end with 'Unknown username or password' instead of telling them that the user doesn't exist right away.
At some places, (12-13, 24-25, 48-49, ...), you're using 'if <condition> <newline>then<newline>', but on other places you're not including the newline for the 'then'.
To recap: Turn smaller tasks into functions, especially the ones you do often (receiving username or password; you can make a function that takes one input, but you tell it what text to display, e.g local user, pass = getInput("Username: "), getInput("Password: ", "*").
And try using function arguments. You can pass a table around to simplify the arguments, and store related stuff in that table, like username, what the user can do, etc.
I see that you're duplicating a lot of code, to get input. Making a function to do this would make your code clearer.
In your home function, you have a lot of other functions, that don't really serve a purpose, I'd move them out of home(), and send arguments to them instead of using upvalues.
When you're taking a password, I'd recommend using read("*"), which will asterisk out the password, then having the user confirm by typing in the password again.
When logging in, take a username and password regardless. Error at the end with 'Unknown username or password' instead of telling them that the user doesn't exist right away.
At some places, (12-13, 24-25, 48-49, ...), you're using 'if <condition> <newline>then<newline>', but on other places you're not including the newline for the 'then'.
To recap: Turn smaller tasks into functions, especially the ones you do often (receiving username or password; you can make a function that takes one input, but you tell it what text to display, e.g local user, pass = getInput("Username: "), getInput("Password: ", "*").
And try using function arguments. You can pass a table around to simplify the arguments, and store related stuff in that table, like username, what the user can do, etc.
- ComputerCraft | Programmable Computers for Minecraft
- → Advert's Content