Cykotitan
Experienced G'
- Joined
- Nov 4, 2008
- Messages
- 16,892
- Solutions
- 5
- Reaction score
- 849
It's ugly to see, not hard to correcttabs are hard -.- lol sargasm
It's ugly to see, not hard to correcttabs are hard -.- lol sargasm
It's ugly to see, not hard to correct
I'm working with TFS for years already and I know pretty LOT of bugs and basing on my current knowledge 1-2 hours is way enough.You don't even know, how much bugs 0.4 has. I don't think so, you'll spend 1-2 hours on fix them until you really know where is the bug, so all you can do is reading core dumps and fixing - but thats not just 1-2 hours.
I never wrote about COMPLETE removal of all flaws and you don't have to treat me like a newfag 'cause I know that's not easy to keep such a big application bugfree. But again, basing on what I already learned on working with TFS - most common problems of TFS could be patched within max. 2 hours and going this way you could get stable revision that could stay from global save to global save w/o any problems.@Derek Boom Boom, there is no way of know EVERY hang, crash, or error to an application of this size without the proper testing methods, and even with that there's no guarantee of a bug free system (no application is 100% bug free, its just the way it is).
True that, thread went offtopic.Now you guys need to quit Hijacking his thread and instead should post some useful feedback. -.-
So many talented minds over there, knowing every single line of code in TFS, but never saw a single patch from many of you. Do we live in a different worlds or is it just a dream?
Moderator posting critics opinions without even understanding the fact in what stage TFS currently is, if you still don't got it, I will try to enlight your mind: its in development stage.
I also did a little offtopic now, but if you're going to give me your useless "warning" without getting the facts it will just prove me that OtLand is going down, because of so many peoples that are not capable to understand what openness behind "Open Tibia" really means.
Keep your codes and tricks for yourself, that's for sure is going to change the way TFS and Open Tibia is going to look in the future.
so if i stop to post things, how it will change the TFS to good?
He has been not talking about you, rather about whiners (like me).
Actually 0.4 has way more possibilities than 0.3.6.
Player = {}
local fnPrefixes = {
["get"] = {"getPlayer", "getCreature"},
["set"] = {"doPlayerSet", "doCreatureSet", "doSetCreature", "setCreature"},
["add"] = {"doPlayerAdd", "doCreatureAdd"},
["do"] = {"doPlayer", "doCreature", "do"}
}
local PlayerInternal = {}
PlayerInternal.__index = function(player, key)
local prefix = key:sub(1, 3) -- set, get or add
local index = 4
if prefix:sub(1,2) == "do" then
prefix = "do"
index = 3
end
local what = key:sub(index, index):upper() .. key:sub(index+1, -1)
-- method access
if fnPrefixes[prefix] then
for _,fnPrefix in ipairs(fnPrefixes[prefix]) do
print("index: ".. fnPrefix .. what)
if _G[fnPrefix .. what] then
return function(...)
return _G[fnPrefix .. what](player.cid, select(2, ...))
end
end
end
return nil
end
-- field access
return PlayerInternal.__index(player, "get" .. key)()
end
PlayerInternal.__newindex = function(player, key, value)
PlayerInternal.__index(player, "set" .. key)(player.cid, value)
end
function Player:new(cid)
local player = {cid = cid}
setmetatable(player, PlayerInternal)
return player
end
Uhm, heres a much more compact version:
Code:Player = {} local fnPrefixes = { ["get"] = {"getPlayer", "getCreature"}, ["set"] = {"doPlayerSet", "doCreatureSet", "doSetCreature", "setCreature"}, ["add"] = {"doPlayerAdd", "doCreatureAdd"}, ["do"] = {"doPlayer", "doCreature", "do"} } local PlayerInternal = {} PlayerInternal.__index = function(player, key) local prefix = key:sub(1, 3) -- set, get or add local index = 4 if prefix:sub(1,2) == "do" then prefix = "do" index = 3 end local what = key:sub(index, index):upper() .. key:sub(index+1, -1) -- method access if fnPrefixes[prefix] then for _,fnPrefix in ipairs(fnPrefixes[prefix]) do print("index: ".. fnPrefix .. what) if _G[fnPrefix .. what] then return function(...) return _G[fnPrefix .. what](player.cid, select(2, ...)) end end end return nil end -- field access return PlayerInternal.__index(player, "get" .. key)() end PlayerInternal.__newindex = function(player, key, value) PlayerInternal.__index(player, "set" .. key)(player.cid, value) end function Player:new(cid) local player = {cid = cid} setmetatable(player, PlayerInternal) return player end
Should be working properly as long as you use camel-case syntax (i.e p:setMaxHealth valid, p:setmaxhealth not valid), isnt tested though
Revscriptsys has nothing to do with the OP's class or mine, Player class/table in revscriptsys is implemented right inside the sources. Here were just emulating class method/properties access with values available in the global namespace (not that useful IMHO).
Im not sure what you mean, p.maxHealth = 100 works as expected, sets the p player max health to 100, print(p.maxHealth) works aswell. If you mean setting an arbitrary property, say p.MyPropertie = 1, it wont work but your not suppused to add arbitrary fields to a class (yes, even a lua table), you can add predefined methods/properties to Player just declaring a function Player:doSomething(). I just dont see a need to index all the player functions if we can figure their names by ourselves (hence 300 lines less).
(P.S p.health wont work since theres no function "doCreatureSetHealth", but you can create that one)
That's what i'm trying to say to you, thats why mocks libs is better because you can create own "keys" to figure functions, making easier for noobs to script and that was the IDEA of revscript.(P.S p.health wont work since theres no function "doCreatureSetHealth", but you can create that one)
That way you cannot create own keys to the script
function doCreatureSetHealth(cid, amount)
doCreatureAddHealth(cid, getCreatureHealth(cid)-amount)
end
Uhm, heres a much more compact version:
Code:Player = {} local fnPrefixes = { ["get"] = {"getPlayer", "getCreature"}, ["set"] = {"doPlayerSet", "doCreatureSet", "doSetCreature", "setCreature"}, ["add"] = {"doPlayerAdd", "doCreatureAdd"}, ["do"] = {"doPlayer", "doCreature", "do"} } local PlayerInternal = {} PlayerInternal.__index = function(player, key) local prefix = key:sub(1, 3) -- set, get or add local index = 4 if prefix:sub(1,2) == "do" then prefix = "do" index = 3 end local what = key:sub(index, index):upper() .. key:sub(index+1, -1) -- method access if fnPrefixes[prefix] then for _,fnPrefix in ipairs(fnPrefixes[prefix]) do print("index: ".. fnPrefix .. what) if _G[fnPrefix .. what] then return function(...) return _G[fnPrefix .. what](player.cid, select(2, ...)) end end end return nil end -- field access return PlayerInternal.__index(player, "get" .. key)() end PlayerInternal.__newindex = function(player, key, value) PlayerInternal.__index(player, "set" .. key)(player.cid, value) end function Player:new(cid) local player = {cid = cid} setmetatable(player, PlayerInternal) return player end
Should be working properly as long as you use camel-case syntax (i.e p:setMaxHealth valid, p:setmaxhealth not valid), isnt tested though
function onUse(cid)
player= Player:new(cid)
player.position = {x=10,y=10,z=7}
player.say = "Yo"
player.say = "My health is "..player.health.."."
player.health = player.health+100
player.mana = 0
player:doRemoveCreature(cid)
end
bump for this, this system is simply awesome, and very useful