• There is NO official Otland's Discord server and NO official Otland's server list. The Otland's Staff does not manage any Discord server or server list. Moderators or administrator of any Discord server or server lists have NO connection to the Otland's Staff. Do not get scammed!

[APCL] Awsome player class lib v.1.0 - Like revscripts!

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'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.

@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).
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.

Now you guys need to quit Hijacking his thread and instead should post some useful feedback. -.-
True that, thread went offtopic.

@Topic:
I can agree with Cykotitan, your idents are terrible. I know I should rather focus on code itself than tabs but it's hard to read code that's not neat. The library itself looks fine, I'd change funtion names a little tho.
 
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.
 
Now that you've read slawkens post, stick to Mock's topic or suffer the consequences. :$
 
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?
 
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
 
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


That way you cannot create own keys to the script

like:

p.health = 8878
p.mana = 9098
etc...

That what revscript was planning to do, a easier way to script the codes.
 
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)
 
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)


I told about the IDEA of revscript not the scripting system.


(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.

You just didin't understood me, when i told that:
That way you cannot create own keys to the script
 
Wrong

Code:
function doCreatureSetHealth(cid, amount)
	doCreatureAddHealth(cid, getCreatureHealth(cid)-amount)
end

You can define custom functions, as long as you follow the OTs lua function convention ([do|add|set][Player|Creature]Whatever), it will work, try it yourself.
 
is it updated?
its better to use the original programming style or use this new lib ?

Mock, do u use it or its only for beginners?
thanks
 
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

It is smaller but cannot use like:
Code:
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
 
Back
Top