[Mod] SkillsFramework [0.4] [skillsframework]

[domtron vox]

SkillsFramework gives modders an API for registering and using skills in Minetest.

SkillsFramework provides an API for creating and managing skills. Modders define skills by providing some basic information like experience cost per level or the max/min level that is attainable. Then collections of unique skill data, called a skillset, can be created at anytime by a modder using an id and a list of skill names. Modders can then manipulate the skillset's skill using a handful of functions rewarding actions with experience.

SkillsFramework is flexible enough that skillsets can be used for individuals, like the player, or groups, like all level 1 skeletons. Modders can also easily use multiple skills for an action or make skills dependent on the successes of other skills.

Players can chat "/skills" to get a list of skill names. And "/skills <skillname> will list that skills level, experience, and goal for next level. Players can also chat "/skills @gui" to open a Formspec.





Credit:
I mooched some general ideas off of BrandonReese's AdventureTest.


Code License: Public Domain
Mod Version: 0.4
Minetest Version(s): Minetest 0.4.12
Git repository: https://github.com/DomtronVox/minetest-SkillsFramework
Download: https://github.com/DomtronVox/minetest- ... ve/0.4.zip

Dependencies: None.

Known Issues

• Formspec shows the same skills on each page.
• Sometimes formspec does not open when the chat command is called.
• Only rudimentary testing has been done. Other bugs may exist. Heavy usage and server testing has not been done.

Feedback welcome and requested. Post bugs here or on GitHub issues.

ToDo

See the bottom of the readme for an up to date TODO list.

Example skills
Attached to this post are zip archives of example skill mods for each version of Skillsframework. You will probebly want the most recent version. Install it along side SkillFramework to see working examples. Code is thoroughly commented. Again make sure you download the correct one for the version of SkillFramework your using.

[TG-MyinaWD]

Sounds interesting.
I might use this somehow in HPT (HarryPotterTest).

Better name hm.
How about Statistics And Levels?
Or just Statistics. And I didn't find really any statistics kinda mods.

Since Minetest needs an statistics system. So can know How many times placed down craft or mined.

Request would be two things.

1. An see others statistics privilege. (/statistics <playername>)*
2. How long been playing.

*Privilege called statistics_oversee
Must have admin privileges to give out.
That if want to. Players can set as an default privilege or staff. like interact.

[rubenwardy]

You're playing the minimal development test game. Why?

[TeTpaAka]

+1

How about a skill tree, where the player can decide, which skill he wants to improve?
This would require dependencies between the different skills, so you can enable a certain skill only, if you leveled enough on another skill.
Just my thoughts.

[Minetestforfun]

wow, great work !

Maybe the subgame adventuretest can help you with this framework ? Because this subgame include it own skills system (with chance of sucess per craft, digging node per level, etc...)

for the viewing skills, i dislike the formspec or the text lines, i think a "hud bar" will be a better "permanent and graphical" idea for see our skills level / experience

this framework, with the quest framework, is the latest feature we need to create a full modded RPG server !

I hope you will improve an finish this framework because im impatiente to use it in my server :)

[domtron vox]

I might use this somehow in HPT (HarryPotterTest).

Yay first guinea pig! uh I mean customer hehe.

How about Statistics And Levels?
Or just Statistics. And I didn't find really any statistics kinda mods.

Since Minetest needs an statistics system. So can know How many times placed down craft or mined.

I agree a statistics mod would be nice so you can see how many nodes you have dug or entities killed. You could use SkillsFramework that way but it would be overkill. I may try making that idea soon though. A statistics mod would be pretty simple just two functions: register player counter and increment player counter.

As a side note you could handle core stats (intelligence, strength, ect) with SkillsFramework. Just register them as skills and make other skills depend on them (see the using skills section in the readme for interlinking skills).

Request would be two things.

1. An see others statistics privilege. (/statistics <playername>)*
2. How long been playing.

1) is a good idea I will add it to the todo list. Being able to check another player's skills could be important.
2) is beyond the scope of this mod but would be great in a statistics mod.

You're playing the minimal development test game. Why?

Not playing per se just using it to test mods. I haven't had time to play MT for a while. :( I use "minimal development test game" because I think it makes a good bare bones platform for testing mods without worrying about conflicting with other stuff. I think that is its purpose besides testing basic engine features.

How about a skill tree, where the player can decide, which skill he wants to improve?
This would require dependencies between the different skills, so you can enable a certain skill only, if you leveled enough on another skill.

That's a good idea and I have thought about it, but that might fall under a different skill system. I am thinking about making skills unlock-able with unlockSkill(entity, skill). For example you have to read a scroll of carpentry before you can start using the skill and doing so calls that function. After that a skill tree would probably be easy for modders to implement.

Maybe the subgame adventuretest can help you with this framework ? Because this subgame include it own skills system (with chance of sucess per craft, digging node per level, etc...)

As I said in OP I got some ideas from AdventureTest but AT uses items(exp orbs) to represent experience and I don't see that being compatible with this SkillsFramework. BrandonReese is of course welcome to use this mod if he wants(Public Domain and all).

for the viewing skills, i dislike the formspec or the text lines, i think a "hud bar" will be a better "permanent and graphical" idea for see our skills level / experience

Showing skills on the HUD would be good if you only have say 6 or 8 skills but would just be clutter for more then 8. I am considering using Wuzzy's HUD bars to show the experience and level of the last used skill (or if your doing a multi-skill action then multiple skills). This would let you grind a single skill like woodcutting without needing to check your skill sheet to see if you leveled up.

this framework, with the quest framework, is the latest feature we need to create a full modded RPG server !

I hope you will improve an finish this framework because im impatiente to use it in my server :)

Yep that's the idea. :) I have plans to release a RPGCore modpack. I had listed the features that still need adding to it and started working on skills. Then quests came out and I said "Yay, one less thing I have to make!"

It is usable now(I hope) but not very pretty.

I'm really busy right now so won't be doing updates for a while. :(

[Krock]

Interesting mod. It would be even better if there's support between the different skill/stats mods.

[domtron vox]

Interesting mod. It would be even better if there's support between the different skill/stats mods.

Could I have links? I don't remember seeing any before.

[Don]

+1

[Sokomine]

For example you have to read a scroll of carpentry before you can start using the skill and doing so calls that function

Basic skills - like digging or very easy crafting - ought to be learning-by-doing-skills. But some advanced things - like i.e. building furniture - might indeed be learned from a mob (or even travelling around, talking to several mobs), written down on a piece of paper, put into a book and collected in a bookshelf. The book would then act as a visual reference as to what the player has learned to make and how often he's done so. The bookshelf could be close to a machine/tool used for crafting those items.

[twoelk]

hmm, learning recepies along your way and collecting them in a book until you have some sort of personal crafting and survival guide. That actually sounds interesting.

This could be used for a gameplay where a player has to travel to gain knowledge just as some craftsmen in the middle ages did before stationary schools for certain professions where established. Of course for those more into the magical or fantasy aspects of gaming maybe something designed like a personall book of spells might work better.

Now I wonder if this could be combined with a crafting school system. The gaining of knowledge or skills in different places somewhat appart might result in a simple quest-like gameplay.

Maybe the trader npc could become a sage-npc that offers knowledge. Of course his hut should then be generated in places not too easy to access ;-P

oooh the airsword myth could grow and prosper with this..........

I'm off to search the secret underground dungeons and remote mountain tops to gain the knowledge to find just the right air needed and the correct ritualls performed and finaly the correct crafting proccess unveiled to get that ultimate weapon to rule the server. ... to rule all servers .... <insert> mad laugh <here>

[Sokomine]

Maybe the trader npc could become a sage-npc that offers knowledge. Of course his hut should then be generated in places not too easy to access ;-P

Just some distance ought to be enough. Without advanced travelling methods, inhabitants of diffrent villages won't meet each other often, and the blacksmith in the next but one village [im übernächsten Dorf] might already have a slightly diffrent technique. The player might learn from watching the mob (giving it the task of creating what the player wants to learn to do himshelf?) or just from asking the mob to be taught something in return for a service provided or money paid. The AdventureTest game already has an experience system and focusses on gaining skill. In that context, such a learning method would be far more intresting than just getting skill points from killing mobs.

oooh the airsword myth could grow and prosper with this..........

The ultimate weapon is but for the wisest to wield!

I'm off to search the secret underground dungeons and remote mountain tops to gain the knowledge to find just the right air needed and the correct ritualls performed and finaly the correct crafting proccess unveiled to get that ultimate weapon to rule the server. ... to rule all servers .... <insert> mad laugh <here>

Keep on trying! There has to be that mountain and that dungeon - somewhere. If you're lucky, it is part of the world. If you're unlucky, it is more than 32000 m away from the origin.

[TeTpaAka]

Hello domtron vox,

I find the usage of trySkill too complicated. The typical usage of a skillset would be:

1. test, whether a skill has all requirements
2. do the action
3. improve the skill (optional)

With your current trySkill function, this is at least for a single skill possible. But as soon as you've got multiple skills, it gets problematic. For two skills, you can, like in the README, chain the calls, but it would be much easier if trySkill would do, what it is named: Simply try, if the skill works.
My proposal would be that trySkill would simply return true or false, depending on the success of the trySkill function. Maybe, you could even eliminate the trySkill function and instead add the required level and experience to the calls.
This way, you could simply do:

Code: Select all

if (SkillsFramework.trySkill(entity, "skill_a", required_level, required_experience) and SkillsFramework.trySkill(entity, "skill_b", required_level, required_experience)) then
        -- do your work
        SkillsFramework.addExperience(entity, "skill_a", some_experience)
--      SkillsFramework.addExperience(entity, "skill_b", some_experience) -- maybe only one skill improves?
end

The current implementation has the drawback, that it requires you to improve every time you try your skill since adding 0 experience would mean failure. My suggestion would allow an easy way to check for requirements without modifying the skill. So you could check, if a fighter is experienced enough to enter an arena, for example. The entering of the arena alone wouldn't alter his skill, would it?

Furthermore, I request the possibility to define different base skillsets. Currently, every call to attachSkillset sets the same skillset for every entity. But maybe it would be easier if you could simply define different skillsets for different classes, so that for example, a dwarf needs less experience to level up in digging. This could be done by adding different amount of experience depending on the class, but it would be less work for the modder if he/she doesn't have to think about the class and simply add always the same amount of experience.

Also it is a bit confusing that the function names are all camel case. In the engine, all functions are lowercase with underscores and the table is all lowercase. I would stick with this for consistency, but it's no big deal if it wasn't like this.

But all in all, this is still good work. I could code my suggestions myself, but I don't want to do work which is never accepted. And making a fork is no option since the two skillsframeworks would be incompatible to each other and this is what a framework shouldn't be.

I hope my post is not to long.

[Minetestforfun]

Up !

Any news about this framework ?

[TeTpaAka]

I made a fork, where I fixed a minor bug and added a basic formspec (probably needs improvements, but at least, there is one, now).
https://github.com/TeTpaAka/minetest-SkillsFramework
I hope this gets pulled.

[domtron vox]

Glad people are interested in this. ^.^ I haven't done any development because collage. But I just had my last day of classes today and will be doing finales next week. After that I'll try to get back onto developing this.

Up !

Any news about this framework ?

I'm still alive if that's what you mean. Sadly no progress on my part as I said above.

@TeTpaAka I'll need more time to think about your post fully, but I'll try to address it.

The current implementation has the drawback, that it requires you to improve every time you try your skill since adding 0 experience would mean failure. My suggestion would allow an easy way to check for requirements without modifying the skill. So you could check, if a fighter is experienced enough to enter an arena, for example. The entering of the arena alone wouldn't alter his skill, would it?

There are already functions (getLevel, setLevel, addLevel, and the experience variants) as I mention below. (unless I am misunderstanding you.)

I find the usage of trySkill too complicated. The typical usage of a skillset would be:

1. test, whether a skill has all requirements
2. do the action
3. improve the skill (optional)

With your current trySkill function, this is at least for a single skill possible. But as soon as you've got multiple skills, it gets problematic. For two skills, you can, like in the README, chain the calls, but it would be much easier if trySkill would do, what it is named: Simply try, if the skill works.

The trySkill function may not be the best name for it. My intention was for modders to use the getLevel and getExperiance functions for tests and only run trySkill when they are ready to do 2 and 3. However, now that you bring it up it is not really even needed since modders could just use the get and add functions to accomplish the same thing but with a bit more control. (P.S. The more I think about it the more I believe trySkill should just be dropped to make things simpler. I'll review it.) For example the modder's code could flow like so:

1. run getLevel(skill) for all relevant skills and make some tests (RNG, threshold, ect)
2. use the data from 1 in their own code to do the action
3. run addExperiance(skill) to add the exp amount deserved by doing the action

Note: Apparently I left the add functions out of the README. o.O I'll fix that later. The add functions are just aliases anyway for a setLevel(skill, getLevel(skill)+int) call so it could still be done with the information in the readme.

I would like some feedback on this. Which is preferable. This:

Code: Select all

if (SF.getLevel(entity, "skill_a") == required_level and SF.getLevel(entity, "skill_b") == required_level) then
    --do work 
   SF.addExperience(entity, "skill_a", exp)
   SF.addExperience(entity, "skill_b", exp)  -- maybe only one skill improves?
end

Or is this better:

Code: Select all

if (SF.trySkill(entity, "skill_a", required_level, required_experience) and SF.trySkill(entity, "skill_b", required_level, required_experience)) then
        -- do your work
        SF.addExperience(entity, "skill_a", some_experience)
--      SF.addExperience(entity, "skill_b", some_experience) -- maybe only one skill improves?
end

Furthermore, I request the possibility to define different base skillsets. Currently, every call to attachSkillset sets the same skillset for every entity. But maybe it would be easier if you could simply define different skillsets for different classes, so that for example, a dwarf needs less experience to level up in digging. This could be done by adding different amount of experience depending on the class, but it would be less work for the modder if he/she doesn't have to think about the class and simply add always the same amount of experience.

I thought I had this on the TODO list. If it isn't I can certainly add it. I had considered it before, but was waffling on it since I wasn't sure if I should be trying to handle character classes in this, currently, simplistic mod. If I can do it cleanly then I will implement it.

Also it is a bit confusing that the function names are all camel case. In the engine, all functions are lowercase with underscores and the table is all lowercase. I would stick with this for consistency, but it's no big deal if it wasn't like this.

I can change this. I just prefer camel case for functions and hadn't noticed that it conflicted with the core API's style.

But all in all, this is still good work. I could code my suggestions myself, but I don't want to do work which is never accepted. And making a fork is no option since the two skillsframeworks would be incompatible to each other and this is what a framework shouldn't be.

Thank you. :) I will tentatively say that I won't turn away pull requests as long as they are cleanly implemented and well documented. I haven't needed to manage pull request before so bare with me. :P

I hope that answers stuff fairly well and I really appreciate the feedback. If it didn't awnser your q's or you have more thoughts do not hesitate to make another long post. ;)

Edit: Meant to say I'm glad you added the formspec. I was planning on depending on smartFS but also wanted to have a fallback formspec. I may tweak it depending haven't had a chance to look at it.

[TeTpaAka]

Glad people are interested in this. ^.^ I haven't done any development because collage. But I just had my last day of classes today and will be doing finales next week. After that I'll try to get back onto developing this.

I thought it was something like this.

There are already functions (getLevel, setLevel, addLevel, and the experience variants) as I mention below. (unless I am misunderstanding you.)

This was just to explain, why trySkill was not necessary. I'm sorry, if it was confusing. And you are right. This can be achieved with the current API.

I would like some feedback on this. Which is preferable. This:

Code: Select all

if (SF.getLevel(entity, "skill_a") == required_level and SF.getLevel(entity, "skill_b") == required_level) then
    --do work 
   SF.addExperience(entity, "skill_a", exp)
   SF.addExperience(entity, "skill_b", exp)  -- maybe only one skill improves?
end

Or is this better:

Code: Select all

if (SF.trySkill(entity, "skill_a", required_level, required_experience) and SF.trySkill(entity, "skill_b", required_level, required_experience)) then
        -- do your work
        SF.addExperience(entity, "skill_a", some_experience)
--      SF.addExperience(entity, "skill_b", some_experience) -- maybe only one skill improves?
end

Now, when I think about it, case 1 seems more practical. But I think it should be >= instead of ==, or else you lose possibilities by levelling up.

I thought I had this on the TODO list. If it isn't I can certainly add it. I had considered it before, but was waffling on it since I wasn't sure if I should be trying to handle character classes in this, currently, simplistic mod. If I can do it cleanly then I will implement it.

Sorry, missed it.
But I think, this can be easily implemented in this framework. For now, there is only a base skillset. This can be used as default, when no other skillset is named. So, current behaviour would remain with the addition of further skillsets.

Note: Apparently I left the add functions out of the README. o.O I'll fix that later. The add functions are just aliases anyway for a setLevel(skill, getLevel(skill)+int) call so it could still be done with the information in the readme.

Yes, I've seen this. And looking on the code, your warning seems to be wrong.

warning: setting the level also resets experience to 0. Save the experience before and set it afterwards if you want to keep the experience (this may cause the skill to level up again so be careful).

This function (setLevel) is even used internally without saving the experience. And the function doesn't reset the experience.

[domtron vox]

This was just to explain, why trySkill was not necessary. I'm sorry, if it was confusing. And you are right. This can be achieved with the current API.

Ah, ok well you were successful. I'll remove try skill after merging in you pull request.

Now, when I think about it, case 1 seems more practical. But I think it should be >= instead of ==, or else you lose possibilities by levelling up.

Right, I wrote that post rather quickly and didn't notice that error.

I thought I had this on the TODO list. If it isn't I can certainly add it. I had considered it before, but was waffling on it since I wasn't sure if I should be trying to handle character classes in this, currently, simplistic mod. If I can do it cleanly then I will implement it.

Sorry, missed it.
But I think, this can be easily implemented in this framework. For now, there is only a base skillset. This can be used as default, when no other skillset is named. So, current behaviour would remain with the addition of further skillsets.

I kinda have it on the TODO. I was thinking of the "multiple skill systems" one, though now how the skills work is upto the modder to decide. I'll ask for feedback on this later when I get to it.

Note: Apparently I left the add functions out of the README. o.O I'll fix that later. The add functions are just aliases anyway for a setLevel(skill, getLevel(skill)+int) call so it could still be done with the information in the readme.

Yes, I've seen this. And looking on the code, your warning seems to be wrong.

warning: setting the level also resets experience to 0. Save the experience before and set it afterwards if you want to keep the experience (this may cause the skill to level up again so be careful).

This function (setLevel) is even used internally without saving the experience. And the function doesn't reset the experience.

Ya that was left over from my previous implementation. Kinda like the try skill function. I have removed it in the new readme that will go up after I remove trySkill.


@TeTpaAka, I want to thank you for the pull request. It looks great. However, I need to point out a few concerns with the pull request. I'll go ahead and merge it and will see about fixing it myself, but it would be great if you knew what the issues might be.

• The fix undeclared global didn't actually change any files.
• After closing the formspec several lines of stuff is printed into the players chat bar. This needs to be removed but I'm not sure what's causing it.
• I noticed when testing, the formspec opens intermittently. I tryed opening it when '/skills @gui' is called and when '/skills' is called. The latter worked better, but still occasionally didn't open on the first try, usually after moving.(??) This is probably an engine bug or the fault of my chat command code.

Finally, I would like feedback on weather to remove the chat display stuff(textural display). I think some people might prefer it. However, the other people might not like calling '/skills @gui' which is how the formspec is currently shown but I figure most of those people will just add a button to open it from their inventory window.

[TeTpaAka]

@TeTpaAka, I want to thank you for the pull request. It looks great. However, I need to point out a few concerns with the pull request. I'll go ahead and merge it and will see about fixing it myself, but it would be great if you knew what the issues might be.

• The fix undeclared global didn't actually change any files.

That's because I am a noob with git. I made the commit and pushed it to github. later I found the missing global and fixed it with --amend, so it wasn't a new commit. But to push it to github, I had to merge the two versions. Maybe I should have force-pushed? I'm sorry for the messy git log.

[*]After closing the formspec several lines of stuff is printed into the players chat bar. This needs to be removed but I'm not sure what's causing it.

I think, this is due to me simply adding the gui to the existing display function. Or is this something different? I didn't add any chat messages to the mod.

[*]I noticed when testing, the formspec opens intermittently. I tryed opening it when '/skills @gui' is called and when '/skills' is called. The latter worked better, but still occasionally didn't open on the first try, usually after moving.(??) This is probably an engine bug or the fault of my chat command code. [/list]

Me neither. It happens occasionally for me, too. It's the same with my other mods, but I can't do anything about it. The function gets called, but the formspec simply doesn't open.

The gui will need further improvements. For example, the skills are simply arranged by their creation time. It would be much better, if the tabs would correspond to the different groups, so you would have all p.e. Landscaping skills together.

[asanetargoss]

Regarding your reply to my feedback on your outdated design thread: thank you for the clarification. I found this thread first but somehow found my way over to the old thread thinking it was still regularly updated. Not sure how that happened. :/ I looked at the readme and I think I understand better how the mod's design has changed, and overall it seems you have implemented, or are planning to implement, things which address most of my concerns.

I'll have to think a little bit harder about my conception of progression points (which I had referred to as "skill points") as different currencies that could be spent inside of the gui to advance skills (which I had referred to as "levels"). My intuition said, "Yes, this is a good idea," but when I considered what it would be like for a player to have experience-based skills and progression-points-based skills shown together in the formspec with the same visual appearance, it seemed like it might be confusing. In addition, it seemed redundant for a progression-points-based skill to require multiple experience points to get to the next level, given that progression points would logically come from a player gaining levels, which already requires multiple experience points to begin with.

That is why, in my code, I proposed (but perhaps poorly explained) the paradigm shift where "skills" would be separated into two different things, "levels" and "skills," to account for them being incompatible use cases. In your namespace, I would guess these would be called "experience-based skills" and "progression-based skills." Such a shift is based on the assumption that this framework will implement a system for progression points to be spent. Also, after some thought, I feel that my suggested implementation for progression points as a separate thing to be registered may be more complex than necessary, both for modders and players. It would make more sense for there to be at most one progression point currency per EBS (experience-based skill), and only the EBS associated with that currency should be allowed to increment it (perhaps through an optional return value passed by the level_func of the EBS). That way, there could simply be a little button next to the EBS progress bar indicating that there are progression points waiting to be spent, and the player could simply click on the button to open a formspec with all eligible PBS's (progression-based skills) that they could spend their progression points on.

I hope that better explains things. While I can see the potential flexibility of a "one size fits all" skill definition, asserting some restrictions on how mods implement skills would allow for a more streamlined and hopefully more fun experience for the player. I do feel your original conception of the two skill systems had merit, just functioning side-by-side rather than permanently separated by a config variable.

[TeTpaAka]

Hi domtron vox,

In the README it says:

Better handling of old skill sets when:
Players never log in again or haven't logged in for a very long time.

is needed.
This could be achieved by saving the skill data not in a general table but player specific. This can be done by hacking and misusing the inventory. This way, the data is saved together with all other player specific data in the same file.
The idea comes from the hunger mod. There a new inventory slot is created just for the purpose of saving the amount of hunger.
In your case, you would create an inventory called "skills" and add in an item ":" with the serialized playerdata as metadata. Then, when a player joins, the data can be read and inserted in the existing table and when a player leaves, the data can be saved and removed from the table again, so there won't be the usual overhead when using a general table.
On the other hand, this would make it extremly hard to get rid of skills that aren't used anymore.

Hope this helps in a way or another.

[domtron vox]

Regarding your reply to my feedback on your outdated design thread: thank you for the clarification. I found this thread first but somehow found my way over to the old thread thinking it was still regularly updated. Not sure how that happened. :/

Sorry, that was entirely my fault. I should have made a note on the OP that the post was not in use anymore. I did so after seeing your post.

I looked at the readme and I think I understand better how the mod's design has changed, and overall it seems you have implemented, or are planning to implement, things which address most of my concerns.

Glad to hear it. I had just updated the README today so I assume that is the one you saw? If it still had the trySkill function you should look again. :) As you can see the mod is very unstable at the moment. >.>

My intuition said, "Yes, this is a good idea," but when I considered what it would be like for a player to have experience-based skills and progression-points-based skills shown together in the formspec with the same visual appearance, it seemed like it might be confusing.

Oh dear I really had not thought of that. >.< This mod will only have experience-based skills (for the forseeable future) and the formspec will not have a way to assign progression points.

As you know I originally wanted to implement two skill systems the progression-based and the experience based. The framework had forced the game maker to choose one or the other so that there would be no mixing of the two systems. Then when I released the mod I decided to simplify it and just do experience-based skills maybe adding the other later (still listed on the TODO). However with the removal of trySkill and pointing modders to use the getters and setters, I don't think multiple skill systems will be possible. But I encourage anyone (I may even do it later) to fork my code and use it as a base for a progression-based system with a different mod name of course. BTW, I'm still looking for feedback on a better name for this mod. :P

In addition, it seemed redundant for a progression-points-based skill to require multiple experience points to get to the next level, given that progression points would logically come from a player gaining levels, which already requires multiple experience points to begin with.

...

While I can see the potential flexibility of a "one size fits all" skill definition, asserting some restrictions on how mods implement skills would allow for a more streamlined and hopefully more fun experience for the player. I do feel your original conception of the two skill systems had merit, just functioning side-by-side rather than permanently separated by a config variable.

Ya, that was why I dropped the progression-based system. It was really hacky trying to make both use the same code base and made things overly complicated. Trying to be a one stop shop is sometimes a bad idea.

BTW, your code did help me a lot. My next commit will use a register_skill(register follows the api better then define) function that receives a table to set it up. It will also have the level max and min values(optional). I will probebly release version 0.3 after that. Also, I added an on levelup function to the todo list for later.

@TeTpaAka: Ok, sounds promising. I don't like the idea of not being able to remove old skills especially in a server environment (servers being the main reason for that todo item). I'll look into it and see if I can get an acceptable balance. I think this is low priority at the moment though unless some server admin speaks up about it.

Thanks for the feedback asanetargoss and TeTpaAka. :)

[TeTpaAka]

@TeTpaAka: Ok, sounds promising. I don't like the idea of not being able to remove old skills especially in a server environment (servers being the main reason for that todo item). I'll look into it and see if I can get an acceptable balance. I think this is low priority at the moment though unless some server admin speaks up about it.

It is not entirely impossible. The point is, you don't have a table with all registered skills anymore. You would need to save somewhere which skills are available and which are outdated. This list can be edited when a mod gets removed, so this skill doesn't exist anymore.
Second you would check each player when he logs in, whether he has all skills. (That's what you do now.) In the same process, you can remove outdated skills.
That means, a player keeps his outdated skills until he logs back in. Even the removed skills that are still on the list wont be visible though, because the display function relies on the skills that get registered on startup.

[asanetargoss]

This mod will only have experience-based skills (for the forseeable future) and the formspec will not have a way to assign progression points.

Sounds like a good way to go about it.

BTW, I'm still looking for feedback on a better name for this mod. :P

Maybe you could just shorten the name to "skills"? It doesn't seem to be taken, as far as I'm aware.

...also, before you consider changing the namespace, you might want to read up on Lua's colon syntax (in the bottom four lines of the Lua Manual's function definition section). While it's technically not quite in-line with how minetest api functions are usually called, it could potentially allow you to define all of your mod's functions and variables while almost never referring to the name of your mod:

Code: Select all

my_mod = {}

function my_mod:init()
    self.example_variable = "example_value"
    local example_local_variable = "asdfjkl;"
    
    function self:example_function()
        if example_local_variable then
            return "The cake is a lie!"
        else
            return self.example_variable
        end
    end
    
    minetest.register_something(function(some, params)
        -- [[
                 A little gotcha: This does not work: minetest.register_something(self:example_function)
                 The reason is that colon syntax always acts like a function call outside of the function declaration
        -- ]]
        self:example_function()
    end)
end

my_mod:init()

Of course, this is isn't exactly trivial to implement in an existing codebase. It could be a headache or a godsend, depending on your needs. In particular, keeping your code split into different files would require some sort of mixin scheme.

BTW, your code did help me a lot. My next commit will use a register_skill(register follows the api better then define) function that receives a table to set it up. It will also have the level max and min values(optional). I will probably release version 0.3 after that. Also, I added an on levelup function to the todo list for later.

Happy to help! However, after some thought, I don't think that skills need an additional "on level up" function, because in principle level_func would only be called when a player levels up. It may suffice to simply update the documentation to clarify how level_func is called.

The only exceptions would be if a modder wanted to register a method that was called every time any skill increased in level, or if the modder wanted to account for a case when a player is leveling up many times in quick succession. Aside from playing a little level-up jingle, these seem like pretty niche cases, although probably trivial to implement.

[domtron vox]

BTW, I'm still looking for feedback on a better name for this mod. :P

Maybe you could just shorten the name to "skills"? It doesn't seem to be taken, as far as I'm aware.

I don't want to sound picky, but I would like something unique since (hopefully) other skill modes will follow mine. Anyway I will keep the current one for now.

...also, before you consider changing the namespace, you might want to read up on Lua's colon syntax (in the bottom four lines of the Lua Manual's function definition section). While it's technically not quite in-line with how minetest api functions are usually called, it could potentially allow you to define all of your mod's functions and variables while almost never referring to the name of your mod:

...

Of course, this is isn't exactly trivial to implement in an existing codebase. It could be a headache or a godsend, depending on your needs. In particular, keeping your code split into different files would require some sort of mixin scheme.

Yep that would be good. I see it as trivial. just a simple refactoring of the code. I just finished reworking some stuff and ended up touching almost the entire codebase.

BTW, your code did help me a lot. My next commit will use a register_skill(register follows the api better then define) function that receives a table to set it up. It will also have the level max and min values(optional). I will probably release version 0.3 after that. Also, I added an on levelup function to the todo list for later.

Happy to help! However, after some thought, I don't think that skills need an additional "on level up" function, because in principle level_func would only be called when a player levels up. It may suffice to simply update the documentation to clarify how level_func is called.

The only exceptions would be if a modder wanted to register a method that was called every time any skill increased in level, or if the modder wanted to account for a case when a player is leveling up many times in quick succession. Aside from playing a little level-up jingle, these seem like pretty niche cases, although probably trivial to implement.

I think on level up is still good. You want the function to run when a natural level up occurs(after and add exp call causes a level up). level_func is called whenever set_level is called. There is a fine line between them though.


I have everything I'm going to do for version .3 done and committed in my local repo, but I don't have time to push it and do the other necessary things(edit posts) so I'll try to do that tomorrow. Then I'll take a break and work on other stuff. Note: this update will break everything because I made changes to what info is stored for each skillset.