Good vs. Evil

  • The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
96 so... abilities now can be linked to actions and when creating an ability you have the ability to write a new action.

I've also decided to limit direct access to modifiers, characters and stuff like that and instead create functions that do that for you. That way, I can calculate the changes more easily and automatically create feedback messages based on the changes, instead of forcing people to put print statements everywhere if they want to know what happened.

So... time to create that, I guess....
 
97 Right now, I managed to make functions to add and delete modifiers :) Now, I need one to find modifiers and one to update them.
After that, I need to do the same for characters and add a way to represent characters. Currently at 83 lines of code already though.
My plan is also to move as much code to setup the environment over to the lua side. That way, php only has to stitch the script that gets run together, which should make it easier to get the lua scripts working in the browser and possibly other environments as well :)

I'm not sure if I will just create a way for clients to get the whole script or also add ways to just get smaller parts which a client need to stitch together themselves.....
 
duckfan77 said:
98 char characters or player characters? I'd imagine it should know how to represent chars already.
Click to expand...
99 player characters. And it more has to do with the various actions a character can do.
Do I just create a giant pool of all the actions, do I put the actions directly in the character table or do I group them all together....
Code: 
actions:char1nameDoAction(char1,char2) --bigPool
char1:doAction(char2) --every action directly inside the character table
char1.actions:doAction(char1,char2) --every action grouped together in their own table.
I like the second the most when writing stuff, but then ability names can screw stuff up. The third one would be nice except that I can't pass the table of the character that does the action automatically. Unless I put that table inside the actions table, in which case ability names can still screw stuff up....

And then there is the question if I should add special methods to add modifiers to a character inside the character table and do something similar for modifiers or not. That way you can just do
Code: 
char1:getModifierByName("Damage"):delete()
instead of
Code: 
local mod = battle:getModifierByName(char1,"Damage")
battle:deleteModifier(char1,mod)
but... that is also a good bit more work.....
I guess, I'm just doing the easy and quick thing now, then I can always bring out updates later on to extend on them.
 
99.
download.png
 
  • Like
Reactions: GamerwithnoGame
99
lenscas said:
player characters. And it more has to do with the various actions a character can do.
Do I just create a giant pool of all the actions, do I put the actions directly in the character table or do I group them all together....
Code: 
actions:char1nameDoAction(char1,char2) --bigPool
char1:doAction(char2) --every action directly inside the character table
char1.actions:doAction(char1,char2) --every action grouped together in their own table.
I like the second the most when writing stuff, but then ability names can screw stuff up. The third one would be nice except that I can't pass the table of the character that does the action automatically. Unless I put that table inside the actions table, in which case ability names can still screw stuff up....

And then there is the question if I should add special methods to add modifiers to a character inside the character table and do something similar for modifiers or not. That way you can just do
Code: 
char1:getModifierByName("Damage"):delete()
instead of
Code: 
local mod = battle:getModifierByName(char1,"Damage")
battle:deleteModifier(char1,mod)
but... that is also a good bit more work.....
I guess, I'm just doing the easy and quick thing now, then I can always bring out updates later on to extend on them.
Click to expand...

Even if you're just doing the quick and easy thing, if you plan to expand it later, you should make sure you write it in a maintainable and extensible way, even if itsn't quite as quick and easy. Otherwise you could find yourself needing to rewrite it to get the functionality you wish.
 
You must log in or register to reply here.
Top Bottom