[DBTech] DragonByte Credits [Paid] 5.9.0

[Zulenka]

So new thing I need to figure out if I can do it! Sorry to be a bother! We're using this addon for a Forum RPG and we have a currency that pays out every 2 weeks. I know I can cap the currency, but is there a way to exclude users from that cap individually? Either through a shop purchase? Or some function I'm not seeing?

 

[kbryant414]

So new thing I need to figure out if I can do it! Sorry to be a bother! We're using this addon for a Forum RPG and we have a currency that pays out every 2 weeks. I know I can cap the currency, but is there a way to exclude users from that cap individually? Either through a shop purchase? Or some function I'm not seeing?

Perhaps not in the exact way you mean... but I have a related idea. It sounds like you want certain players to be free to earn more than others. Rather than having capped versus uncapped, you could stagger the rate of income.

I actually run a Forum RP myself, and I set up 6 levels of paychecks (7 if you count "none"). What I did was create a Usergroup in XF to correspond with each. Each user in the RP, if they get a paycheck, has just one of these as a secondary usergroup. Then, in the Paycheck event, under Event Settings, I set each paycheck event to only apply to one usergroup.

Spoiler: Examples

So my setup was this:

Registered = No paycheck​

Registered - Pay Grade 1 = 100 currency​

Registered - Pay Grade 2 = 200 currency​

Registered - Pay Grade 3 = 400 currency​

Registered - Pay Grade 4 = 600 currency​

Registered - Pay Grade 5 = 800 currency​

Registered - Pay Grade 6 = 1000 currency​

My screenshot shows a bit more. I give a small starter bonus of 500 currency when a new member joins, and users can also pick up small bits of currency by writing in the designated RP nodes (not just the general chat and such). It's also set up so that players can give currency to another player ("Donate") or transfer one currency to another ("Transfer").

If you don't want to stagger income, but just want capped vs uncapped, the only thing I can think of would be to use Taxation or Interest set with the Minimum currency at the 'cap' and only applying to a usergroup for the members you want capped. This isn't perfect, and @DragonByte Tech would have to confirm if it would even work this way, but if it does what I think, it would only subtract from users who are over that 'Minimum' and stop subtracting when they go below it again.

Idea #3, however: make two currencies. The regular one, Credits, caps at say 5,000. Then make a big-boy currency, Gold, that specified members can earn. You can sell the same items for different currencies in the shop (for instance, a user upgrade that costs 1000 Credits might cost only 10 Gold), or just have some items available with Credits and more desirable items available with Gold.

 

[Zulenka]

Perhaps not in the exact way you mean... but I have a related idea. It sounds like you want certain players to be free to earn more than others. Rather than having capped versus uncapped, you could stagger the rate of income.

I actually run a Forum RP myself, and I set up 6 levels of paychecks (7 if you count "none"). What I did was create a Usergroup in XF to correspond with each. Each user in the RP, if they get a paycheck, has just one of these as a secondary usergroup. Then, in the Paycheck event, under Event Settings, I set each paycheck event to only apply to one usergroup.

Spoiler: Examples

So my setup was this:

Registered = No paycheck​

Registered - Pay Grade 1 = 100 currency​

Registered - Pay Grade 2 = 200 currency​

Registered - Pay Grade 3 = 400 currency​

Registered - Pay Grade 4 = 600 currency​

Registered - Pay Grade 5 = 800 currency​

Registered - Pay Grade 6 = 1000 currency​

My screenshot shows a bit more. I give a small starter bonus of 500 currency when a new member joins, and users can also pick up small bits of currency by writing in the designated RP nodes (not just the general chat and such). It's also set up so that players can give currency to another player ("Donate") or transfer one currency to another ("Transfer").

If you don't want to stagger income, but just want capped vs uncapped, the only thing I can think of would be to use Taxation or Interest set with the Minimum currency at the 'cap' and only applying to a usergroup for the members you want capped. This isn't perfect, and @DragonByte Tech would have to confirm if it would even work this way, but if it does what I think, it would only subtract from users who are over that 'Minimum' and stop subtracting when they go below it again.

Idea #3, however: make two currencies. The regular one, Credits, caps at say 5,000. Then make a big-boy currency, Gold, that specified members can earn. You can sell the same items for different currencies in the shop (for instance, a user upgrade that costs 1000 Credits might cost only 10 Gold), or just have some items available with Credits and more desirable items available with Gold.

Thanks! I'll see what we can do. How do you handle leveling on your site? I'm looking for a way to do that that's simple.

 

[kbryant414]

Thanks! I'll see what we can do. How do you handle leveling on your site? I'm looking for a way to do that that's simple.

Mine's not at all normal or simple, haha. I have a currency set up as essentially EXP. Users can 'purchase' different skills and tiers with it, some of them tied to UserGroup Upgrades.

If you want something simpler, I would still use a currency as EXP but instead of buying upgrades, use AdminCP -> Groups and Permissions -> Usergroup Promotions and Apply this promotion while... their EXP currency is above a certain threshold. Then however you set events for them to gain EXP will determine what they do to level up.

 

[Zulenka]

Sent you a PM, because I ran into problems with that.

 

[DragonByte Tech]

Be careful not to delete anything in Event Triggers, though. That could cause you to have to reinstall the add-ons and start over.

Just as an update to this, I've finally decided what I'm going to do with Event Triggers going forward. That entire page in the AdminCP will be killed, and the settings will be ported to the standard XenForo Options page.

The initial reasoning behind making the "Manage Event Triggers" page accessible to admins (outside of Debug Mode) was so that there could be a centralised location to manage various settings that doesn't make sense to have customisable per-event.

In reality, what this means is that people installing the mod for the first time will need to open no less than 75 pages in order to find out whether there are any settings available and if so, figure out what they do. The only way that could be less intuitive was if the mod deleted parts of the configuration if you happened to click the wrong save button... oh wait that's exactly what is actually happening.

Another reason why the page (and corresponding database table entries) existed in the first place was to provide a way to tell XF where the Event Trigger-specific code was located. For instance, the "Adjust" event would use the class DBTech\Credits\Model\Event\Adjust, etc. In XF2, I can add these class references to a built in system called "Content types", which means it is much easier to maintain.
Not only that, but it becomes easier for myself as well as 3rd party developers to develop new event triggers, as we won't have to worry about inserting into the database.

Lastly, by moving developer-only settings (such as "Cancel", or "will the user see an error message if they don't have enough credits to perform this action") into the files, it becomes easier for me to release new updates that enables new functionality or changes existing functionality. I won't have to update the database and trust that every form of cache has been purged before the new functionality will actually, uh, function.

All of these changes will delay the actual finished product, but if I'm going to port the code in the first place, I might as well go full trade and correct some deficiencies in the architecture and design of the mod while I'm at it


Fillip

 

[Zulenka]

I also figure it's worth mentioning, that unless you know why, the default permissions state for Credits and Shop is No for every Usergroup. I have to manually turn them on to see them even as a Super Admin. If that's intended, then ignore me. If it's not! Then consider this a friendly "heads up."

 

[DragonByte Tech]

I also figure it's worth mentioning, that unless you know why, the default permissions state for Credits and Shop is No for every Usergroup. I have to manually turn them on to see them even as a Super Admin. If that's intended, then ignore me. If it's not! Then consider this a friendly "heads up."

I am aware of that, it applies to all our older XF2 mods. DB eCommerce and newer has sensible permissions set as default, and it's something I plan to revise for DB Credits & all older XF2 mods in the re-engineering effort


Fillip

 

[Zulenka]

I am aware of that, it applies to all our older XF2 mods. DB eCommerce and newer has sensible permissions set as default, and it's something I plan to revise for DB Credits & all older XF2 mods in the re-engineering effort


Fillip

Understood! New question! <3

Is there a way to hide specific currencies in the Credits Add-on? I know where to turn off the post-bit function, but I just want to disable a specific one. Is that possible and I'm just not seeing it? Or can I do that in the template?

 

[kbryant414]

Understood! New question! <3

Is there a way to hide specific currencies in the Credits Add-on? I know where to turn off the post-bit function, but I just want to disable a specific one. Is that possible and I'm just not seeing it? Or can I do that in the template?

Go to AdminCP -> DragonByte Credits -> Manage Currencies. Select your currency, and under Currency Settings, there's options for Privacy Filters.

One downside is you can't show one hidden currency to group A and another hidden currency to group B. It's kind of a binary, either a group can see all currencies, both public and private, or a group can see public currencies only.

 

[Zulenka]

Go to AdminCP -> DragonByte Credits -> Manage Currencies. Select your currency, and under Currency Settings, there's options for Privacy Filters.

One downside is you can't show one hidden currency to group A and another hidden currency to group B. It's kind of a binary, either a group can see all currencies, both public and private, or a group can see public currencies only.

I just need to hide one currency from all groups, but themselves. So I can see my own XP but no one else can see it. I have the options setup correctly (so I think) and it's not working.

 

[kbryant414]

I just need to hide one currency from all groups, but themselves. So I can see my own XP but no one else can see it. I have the options setup correctly (so I think) and it's not working.

I don't have time to do a test on my forum at the moment, but to my knowledge you should only need:

AdminCP -> DragonByte Credits -> Manage Currencies -> XP -> Currency Settings -> Privacy Filter: Show to self and designated usergroups
AdminCP -> Groups and Permissions -> User group permissions -> Registered -> DragonByte Tech: Credits Permissions -> Can See Private Currencies: No

You'd only want to toggle See Private Currencies to Yes on moderator/admin permissions. If you've set that and it's not working, I'll defer the question to @DragonByte Tech

 

[Zulenka]

@DragonByte Tech

Yeah I have the right permissions, but registered users can still see private currency even with it set to "No" or "Never."

 

[DragonByte Tech]

@DragonByte Tech

Yeah I have the right permissions, but registered users can still see private currency even with it set to "No" or "Never."

Specifically where do they see them? Are you sure the people you’re testing with are not a member of another group?


Fillip

 

[hemant_bhardwaj]

brother don't you think steal function might be good in credit like you added in the shop - >

 

[sub_ubi]

For the events:
XenResource Rate and XenResource Rated soft-deleting a resource rating/review causes an amount increase, rather than amount negation. Permanent delete works correctly and triggers negation.

 

[DragonByte Tech]

For the events:
XenResource Rate and XenResource Rated soft-deleting a resource rating/review causes an amount increase, rather than amount negation. Permanent delete works correctly and triggers negation.

I'll resolve that in the 5.1.x branch, thanks.


Fillip

 

[Freud]

Hi Filip,

Do you have a demo/sample of this add-on for XF2?

 

[DragonByte Tech]

Hi Filip,

Do you have a demo/sample of this add-on for XF2?

Not beyond the screenshots, sorry. We don't operate a demo site at this time.


Fillip

 

[Freud]

Not beyond the screenshots, sorry. We don't operate a demo site at this time.


Fillip

I don't see any screenshots of your sales resource page. Neither from your shop add-on. Would you be able to send me the link with the screenshots? Thanks.