[2.0] WCS - A combat system framework

You would just check if the enemy has blood before applying the status effect? This question seems pretty self explanatory

ok, and another example for my game i have let’s say a person that has complete resistance to a burn status and if i want to have a fireball that is high in level/skill i would like that to actually burn, should i apply grades to the status or skill?

The simplest way would be to have grades for both the fire resistance and the status effect. So like if the resistance is at grade 1 then it wouldnt work against a grade 2 burn effect.

where should i store the grade in the metadata? like in the skill when i create it?

Personally i like to use dictionaries when setting the metadata, as its easy to make changes to. So it would look something like this:

Self:SetMetadata({Grade = 3})

And you can place that wherever you want.

Also it would make more since to give the status effect a grade than the skill, since you could just pass a grade parameter through the constructor

:crossed_swords: WCS 2.0 :crossed_swords:

:checkered_flag: BREAKING CHANGES

  • You can now send unlimited amount of starter params.
  • Messages fully revamped! Check out the doc page for more info.
  • GetMoveset() now returns the actual moveset object instead of the name.
  • WCS will now cancel the execution thread of OnStartServer and OnStartClient if skill has ended.

:white_check_mark: NON-BREAKING CHANGES

  • New events: Character.SkillStarted, Character.SkillEnded, Character.StatusEffectStarted, Character.StatusEffectEnded
  • Janitor object, Player field and :End() method (Stop alias) for status effects.
  • Your status effects and skills can now extend from other classes.
  • Character.DisableSkills field.
  • You can now validate skill starter params using ParamValidators field.
  • WCS will serialize some of the data going through remote events to buffers.
  • New method of StatusEffect - GetDebounceEndTimestamp().

:books: Documentation

:ledger: Github Repository

5 Likes

Awesome update, a question, does WCS includes already a Janitor object i can use to clean the things i want?

Yeah, you can check that in the API

Thanks for the update! Looking forward to working with the revamped messages.

Quick question: are arguments no longer passed to the client in OnStartClient? I used to edit the argument table in OnStartServer to then pass to the client, but it seems that no longer works.

1 Like

Thank you waD for this blessed update. The changes to messages are heavenly, as I found the original sendMessageToClient and HandleServerMessage functions to be rather hard to work with.

Also, could you elaborate on what exactly the buffers on remote events are doing? That’s the only part I didn’t really get.

3 Likes

for my npc system do i still have to do the cleaning on it’s death? im creating a new wcscharacter with the npc

Partially serializing data that goes through remote events somewhat reduces network load

2 Likes

I don’t think so, I need to look into this

1 Like

Nice!
My main issue after looking over v1 is was the lack of client to server and sever to client communication.

Will be starting use on Wcs now!

1 Like

:crossed_swords: WCS 2.0.2 :crossed_swords:

:gear: CHANGES :gear:

  • Migrated from @rbxts/reflex → @rbxts/charm with a custom syncer. This solves a lot of replication problems due to immediate behavior of charm in comparsion to reflex.
  • Added GetAllActiveSkills(), GetDebounceEndTimestamp() to Luau types.
  • Fixed GetMoveset() Luau types.

:books: Documentation

:ledger: Github Repository

1 Like

Very nice wAD,
It’s starting to shape up to be able to basically handle everything combat wise.

Right now I think it would be beneficial for you and users to label what type of scripts the server and client handlers need to be!
Documentation is solid just needs polishing.

Suggestion, can you add certain fields to the skill disabled boolean?, like you can select what skills can be enabled and what not, or a “except” parameter too, maybe

i installed this version using wally and synced with rojo and i’m getting this error

  12:40:39.880  Infinite yield possible on 'ReplicatedStorage.Packages._Index.cheetiedotpy_wcs@2.0.2.wcs.include.node_modules.@rbxts:WaitForChild("charm")'  -  Studio
  12:40:39.880  Stack Begin  -  Studio
  12:40:39.880  Script 'ReplicatedStorage.Packages._Index.cheetiedotpy_wcs@2.0.2.wcs.include.RuntimeLib', Line 53 - function import  -  Studio - RuntimeLib:53
  12:40:39.880  Script 'ReplicatedStorage.Packages._Index.cheetiedotpy_wcs@2.0.2.wcs.source.actions', Line 4  -  Studio - actions:4
  12:40:39.880  Stack End  -  Studio

going to be fixed next release, wally seems to be overriding default.project.json

:sparkles: WCS 2.1.0 :sparkles:

  • Fixed a lot of replication problems due to the migration from reflex.
  • Fixed holdable skills acting like normal in the previous version.

:books: Documentation

:ledger: Github Repository

1 Like