• 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!

[10.41] TFS 1.0 Custom Version Github Project

I have done a new pull request to anyone which is not looking on github. I have implemented the feature player:setRate which will make possible to scripters control players rates( skills, exp, magic ) from lua. Its means that every player can have custom rates.
 
Wouldn't it be better to optimize the implementation of those system and try adding them in TFS 1.0?
I guess it would also be better to have a patch for each feature which is compatible with latest TFS 1.0 rather than a different distribution which will get outdated real quick and just cause splitups.
 
Wouldn't it be better to optimize the implementation of those system and try adding them in TFS 1.0?
I guess it would also be better to have a patch for each feature which is compatible with latest TFS 1.0 rather than a different distribution which will get outdated real quick and just cause splitups.
we can always merge from tfs 1.0 to this project and then handle the conflicts, so it will only be outdated if we want it to be outdated.
Mark is very restrictive. If you want custom source you need to have a private fork. Having this open fork is a way to get freedom and let people use it and contribute.
For me its better contribute to a open fork than work only on my private fork( its forces you to get better and clean implementations ).
I would have to wait forever to have a custom quest mission description, because it would only implemented on tfs 1.1.
 
I agree with Summ why don't try merging that codes in TFS 1.0? I think it's time for all distribution become only one again and work together in TFS 1.0
 
Wouldn't it be better to optimize the implementation of those system and try adding them in TFS 1.0?
I guess it would also be better to have a patch for each feature which is compatible with latest TFS 1.0 rather than a different distribution which will get outdated real quick and just cause splitups.
Well the problem is if the most stuff gets denied (which I fully understand) as Mark wants to make it stable and as clean as possible.
I do this mostly educational wise (to get better myself) but why should I let my work get to waste, if it's not added to the official.
That's pretty much what opensource is about, either contribute to something existing or make it your own and do it the way you want it :p
I don't intend to make compatibility issues (lua functions which exist, wont get changed / re named) however I still add new stuff which cannot be used on official 1.0
we can always merge from tfs 1.0 to this project and then handle the conflicts, so it will only be outdated if we want it to be outdated.
Mark is very restrictive. If you want custom source you need to have a private fork. Having this open fork is a way to get freedom and let people use it and contribute.
For me its better contribute to a open fork than work only on my private fork( its forces you to get better and clean implementations ).
I would have to wait forever to have a custom quest mission description, because it would only implemented on tfs 1.1.
don't need to say more then this :p
I agree with Summ why don't try merging that codes in TFS 1.0? I think it's time for all distribution become only one again and work together in TFS 1.0
as mentioned at #1 quote
 
Changelog:

Events:
Code:
Player:onGainExperience(target, exp, rawExp)
Player:onLoseExperience(exp)
Creature:onTarget(target, isAttacked)
Creature:onChangeOutfit(newOutfit, oldOutfit)
Creature:onAttack(target)
Creature:onHear(sayCreature, words, type, pos)

Creatureevents:
Code:
onAppear(cid) -- for monsters and npcs
onDisappear(cid) -- for monsters and npcs

Spells.xml
Code:
New requirements for spells.
ex: fist="30"
tags which can be used are: fist/club/sword/axe/distance/shield/fish

Ingame Manager ingame administration tool for gms/gods

Talkactions:
Code:
added new tags for talkactions.xml
access / accType
so we don't have to make in each lua file a check for access of the player.
cleaned up talkactions, removed all the not neccessary checks.
/manager
to use the ingame manager.

Item Attributes:
Code:
added new attributes, so items can be manipulated through lua.
ex: :setAttribute("attack", 100), :setAttribute("name", "Evil Hero")
accepted attribute types:
name/article/attack/defense/extradefense/armor/hitchance/shootrange

Lua Functions:
Code:
getMaxSummons() -- shows how much summons the player can have.
setMaxSummons(maxSummons) -- changes the max ammount of summons a player can have.
getRate(skill) -- shows how much the current rate of the player is for the certain skill.
ex: getRate(SKILL_LEVEL) -- would print the exp rate of experience.
setRate(skill, rate) -- sets the player a certain rate for the skill, note: if you set the skill rate to 0 then the default rate is used from either config.lua or stages.xml
ex: setRate(SKILL_MAGLEVEL, 50) -- would set the rate of magic level to 50x
getOnlineNpcs() -- returns a table with all npcs which currently exist (name and uid)
getOnlineMonsters() -- returns a table of all monsters which currently exist (name and uid)

Database:
Code:
altered the "player" table, max_summons are now stored in there (database_version 19)
added "player_rates" table, to store the rates of the players in database (database_version 20)

Config.lua:
Code:
warnUnsafeScripts = "no" -- referred to Dalkon's fix of the addEvent function.
convertUnsafeScripts = "no" -- referred to Dalkon's fix of the addEvent function.
rateStaminaAboveNormal = 1.5
rateStaminaUnderNormal = 1.0
staminaThresholdOnlyPremium = "yes"

config.lua is now supporting floating values.

Monster Loot:
Code:
added new tags to manipulate items from the monster xml files already.
ex: <item id="2379" name="Test" article="a" attack="1337" defense="13" extradefense="37" chance="80000"/><!-- dagger -->
supported tags are:
name/article/attack/defense/extradefense/armor/shootrange/hitchance
you however cannot set items which do not have that attribute before, the new attribute
ex:
backpack has no armor, so you cannot set it armor now.

That was it so far, all detailed changes can be found at Github
 
a good reason for conver onChangeHealth/onChangeMana to onStatsChange (or better onChangeStats) is for unify in only single global function, and you can add missing features for soul points. stamina, and offline training
 
Now we will try to build a better Player Storage system, which will enable us to use string keys string values and table values. Currently support for storages on 1.0 is horrible, if i want to storage complex values how i can do it without strings?
 
Now we will try to build a better Player Storage system, which will enable us to use string keys string values and table values. Currently support for storages on 1.0 is horrible, if i want to storage complex values how i can do it without strings?
In which system would you need that?
 
In which system would you need that?
When i want to truly store complex data on players without relying on database, when i do not want use multiple storages ids to the same system, etc.
 
In which system would you need that?
as a quick example I could name "Killing in the name of"
if you'd be able to store names as keys and tables as values, then you could make that quest in pretty much 20 lines if not fewer, it's not that I say that the current system is bad but supporting string as key and value should atleast be added as it gives a lot more possibilites of storing tbh.
 
Does this support mods? i have a mod the cykotitan random attributes mod, how would i go about added that mod to this tfs?
 
Does this support mods? i have a mod the cykotitan random attributes mod, how would i go about added that mod to this tfs?
it does not support mods, you would have to break the mod down in it's pieces for the different event areas :) (onUse/onEquip/whatever)
 
also i believe you would need to check for compatibility with 1.0
 
Back
Top