You are not logged in.

Applications: [GameMaster: OPEN] | [Volunteer Testers: OPEN]


This forum will be permanently shut down on Friday 13.07.2018
Please copy or save all important information from old forum before they will be deactivated
We have moved to new board. https://forum.runesofmagic.gameforge.com/Come join us.

Peryl

Intermediate

  • "Peryl" started this thread

Posts: 313

Location: Elsewhere

  • Send private message

61

Monday, April 15th 2013, 5:24am

I've taken a peek at the interfaces for both Uberflex and Kitty Combo. The interface I'm designing will be quite different from those.
2013... The year from hell....

Peryl

Intermediate

  • "Peryl" started this thread

Posts: 313

Location: Elsewhere

  • Send private message

62

Tuesday, June 4th 2013, 1:23am

Some Design Notes for the "Compiler"

As I haven't posted anything recently about what I'm actually working on (rather slowly I admit, but progress is being made), I thought I'd give a little note on what the internals of the code compiler/converter will be like.

As stated, FuzzyDIYCE will have a GUI with what I hope will be a relatively easy yet flexible system. Further, it needs to be expandable. That is, other folk should be able to use the system to add their own commands etc to the system. To add yet another rinkle to the works, FuzzyDIYCE also needs to be able to use a text based variant of the code for in-game mailing, posting on forums, or just transmitting the code to other players in-game.

A tall order, but it can certainly be done.

First is the decision to split the "compiler" into two parts. The first will convert the GUI created code to/from a text based form. This will mostly be a straight one-to-one conversion process with a bit of error checking to ensure that it isn't just getting garbage.

The second part is the conversion from the text based form to actual executable FuzzyScript. This will require more error checking and validation, but shouldn't be too difficult to pull off.

In both cases, the conversion and validation will be done via data tables that contain the description of all possible commands to the appropriate form. The desired flexibility and expandability of the system will reside in these tables. Obviously, a relatively good design for these tables will be required.

The best solution I can come up with is to effectively design the tables to represent the commands/pseudo-language by taking a page out of compiler design and creating a Lua friendly version of a Backus-Naur Form (BNF) for describing the commands in question. It doesn't need to be a full BNF representation in fact, but we can use BNF (and its variants) as a basis for creating our conversion tables.

By doing this, we gain flexibility since the tables would also do a good portion of the error checking for us, and we gain expandability of the pseudo-language by adding more entries to the data tables.

The main drawback to all this is that we do need to maintain all these tables in memory for compiling the code, but as the language will be using the plug-in system, we could take advantage of On-Demand loading so that it is only ever loaded when needed.

Here's a Wiki on BNF for the curious.
2013... The year from hell....

63

Monday, December 2nd 2013, 5:19pm

Looking interesting and I wanna use it, just [REMOVED] I don't understand a [REMOVED] you talking about. :(

EDITED: Profanity removed. -Kali

Mrpushpop

Master of the Storyteller

Posts: 800

Location: Indigo - The small and feisty server

Mood: Mellow

  • Send private message

64

Wednesday, December 4th 2013, 7:52pm

I believe Peryl and hope of this project has vanished. He has not logged on forums since August.

ghostwolf82

Professional

Posts: 859

Location: Kalvans Trunk

Occupation: It's dark in here

  • Send private message

65

Thursday, December 5th 2013, 12:08am

He had real life issues come up, and hasn't had the time (or the gumption) to work on it, or log in here. Knowing what he told me several months ago, I can't blame him. I miss him hanging around, but I totally understand what he is going through. Peryl, if you do end up reading this my friend, stay strong and my prayers are with you and your family. (To everyone else, please do not ask me what happened, I will not be telling you out of respect for a coding colleague, and someone I consider a friend.)

66

Friday, December 13th 2013, 8:34pm

Thanks Peryl

Thanks for letting us know Ghost. Hope everything goes ok to Peryl. He has helped RoM comunity so much, wish we could return the favor, Good luck Peryl on your journey.
Roxzincrazy r/wd/s/m 87/85/85/85 | Crazybr wd/d 85/63
Roxzin m/wl 85/70 | Roxzn ch/m/r/w 87/70/70/70

Peryl

Intermediate

  • "Peryl" started this thread

Posts: 313

Location: Elsewhere

  • Send private message

67

Monday, March 31st 2014, 7:17pm

The story...

Hey guys... Sorry for the massive delay.

Thought I'd drop in to say boo and mention the whole sordid tale. I'm not looking for sympathy, just thought I'd get around to mentioning what went on. It'll end up reading like a bad dark comedy (and no, this isn't some twisted, sick, april fools joke).

So it starts about a year ago when my mother passed away. This was not completely unexpected (her health had been deteriorating for some time) and in some ways came as a bit of relief, but it still my mother we are talking about.

To add insult to injury, just prior to this event my niece-in-law was diagnosed with lung cancer. Treatments were possible but her condition was quite serious.

During the summer months, my room-mate's father suffered a stroke and was in hospital for some time. As I also know him personally, this was like adding salt to an already growing wound.

Around the end of August a friend of my room-mate passed away. Though I hadn't known him personally, it did add to the mind-numbing events.

Then in October my niece-in-law lost her battle with the big C and passed away.

Somewhere in there I also had a hard-drive crash and lost some work, but that is rather minor considering the other events.

All-in-all, 2013 was a rather nightmarish year for me and needless to say, FuzzyDIYCE wasn't exactly top priority for me.

As I haven't even looked at the code in something like a year, and have sort of lost the desire to try to pick up where I left off, I guess we can consider this project dead unless someone wants to try to pick up the pieces, brush off the cobwebs and have a go at finishing it after all. I'd be willing to help in that respect, but I've been away from RoM for so long now that I don't really see myself getting back even to the level I was at before. I'll try to pop-in more often.

Thanks for the support guys! Here's to 2014 being better that last year... Cheers!
2013... The year from hell....

ghostwolf82

Professional

Posts: 859

Location: Kalvans Trunk

Occupation: It's dark in here

  • Send private message

68

Monday, March 31st 2014, 8:16pm

Good to hear from you again. Sad to hear your niece-in-law lost the battle, the last I knew she was still fighting :( My grandfather is in remission once again, and his body seems to be accepting the medications they are giving him. As we discussed, someday hopefully they will be able to have a cure for it the same way they do polio or smallpox. We all miss you around here, and totally understand why the long time of not logging in and being able to upkeep the project. Losses on that scale really tend to put a damper on ones spirit. Hopefully 2014 will be a great year for you! :beer:

Mrpushpop

Master of the Storyteller

Posts: 800

Location: Indigo - The small and feisty server

Mood: Mellow

  • Send private message

69

Tuesday, April 1st 2014, 4:32am

Peryl, you were a master and you will be missed. I hope everything goes well for you here on out.

70

Wednesday, April 2nd 2014, 12:38pm

Moving on

Peryl will be missed, I wish for him the best moving on.

I have been using FuzzyDiyce as my main combat script for more than six moths, its without any GUI but working combat script like diyce. All thats needed is to write the class specific parts like we do for normal diyce.

If there is any interest I could publish this as a base for moving forward?

best regards & wishes to Peryl,

Peryl

Intermediate

  • "Peryl" started this thread

Posts: 313

Location: Elsewhere

  • Send private message

71

Wednesday, April 2nd 2014, 2:46pm

Peryl will be missed, I wish for him the best moving on.

I have been using FuzzyDiyce as my main combat script for more than six moths, its without any GUI but working combat script like diyce. All thats needed is to write the class specific parts like we do for normal diyce.

If there is any interest I could publish this as a base for moving forward?

best regards & wishes to Peryl,
Well I'm not quite going away... Just not getting back to development stuff or the game. But I do intend to pop into the forums from time to time and post a comment or two.

Anyway, for the record I've given explicit permission to frafall to post his modifed FDiyce Core. He was good enough to wait for permission though IIRC, I did put it in the public domain anyway so no-one should give him any issues about ripping my work 'cause I say it is fine by me.
2013... The year from hell....

72

Thursday, April 10th 2014, 7:31am

FuzzyDIYCE at Curse

I have published my version of FuzzyDIYCE at Curseforge .

It is the base version from Peryl with some additions:

  • Modified command line to: "/fdiyce options script args", currently only supported flag is "debug"
  • Added some variables for use in combat script, check out plugins/BaseCommands/Vars.lua
  • Added a plugin for pluggable configuration panel hooked into to the game interface config UI
  • Added a hud plugin which displays the attacks fdiyce tries to execute with timestamps (debugging scripts)
  • Added an attack plugin which loads the skills and enables an "Attack" script which calls the respective user supplied scripts by primary/secondary classes. Ex "/fdiyce Attack" will execute the script "WarriorWarden". This is to keep number of macros nessesary down as some have 8 classes and MANY class combinations available. Note, you can ofc still use "/fdiyce WarriorWarden" directly.
  • Added the scripts directory used for user written scripts, currently there are three included, prolly can be improved a lot but they serve as examples.

I have been using this on my main toons for quite some months where it works stable, any input would be appreciated.

I suggest we keep discussion on the core developement in this thread and make a separate thread for combat scripts.

Best regards
Frafall

This post has been edited 2 times, last edit by "frafall" (Apr 10th 2014, 7:57am)


Peryl

Intermediate

  • "Peryl" started this thread

Posts: 313

Location: Elsewhere

  • Send private message

73

Friday, April 11th 2014, 4:51pm

Took a peek at your changes. Nice stuff.

Anyway, I noticed that your todo list mentions adding in the FD extensions. Well I can help out there. The last viable version that I have kicking around (some of the later stuff got trashed in the HD crash unfortunately) has the extensions and the begginings of the UI and such). There is a couple of other changes you will need to be aware of if you want to rebase your code off this.

The plug-in system also went though some modifications due to the extension system.
  • FuzzyDIYCE extensions are implemented.
  • Plug-in system is moved into the core code namespace instead of being outside of it. Should be a minor change but may affect you.
  • Plug-in system defaults to load priority of 100 instead of 10.
  • Plug-ins can now be flagged as Load-on-demand (more on this below)
  • Plug-ins can require dependencies on extensions.
  • Game event manager is added.
  • The skill list loading stuff got moved, but probably not its final correct location.
  • The beginnings of the FuzzyDIYCE UI code (supposed to be as an extension) is in place.
The intent of the Load-on-demand stuff was that a plug-in would manually load itself as needed. When registering, it would provide a stub function to the plug-in system that could then load the actual plug-in when it first gets called. I'm not sure how far I got on that though, but there is code in there for it. Consider this feature as untested.

The relationship between Plug-ins and extensions are as follows. Extensions are plug-in-like things that extend the functionality of the core itself. They should be (more-or-less) self-contained. In effect, they add capabilities to the core, but likely shouldn't be doing any user interaction stuff. Plug-ins on the other hand are what the user interacts with and so may require the use of certain FD extensions., hence the dependency list. The UI stuff I was working on is an example of this. The UI extension implements creating windows, buttons, etc. This was to be used by a plug-in that would then be the main user interface for the GUI editor I had planned.

BTW, the UI code, after a brief look, is not really complete, nor is it loaded as an extension.. It doesn't appear to do frame recycling, and there may be other things missing, wrong, or buggy. It is just whatever I was working on that managed to survive the HD crash. Use it, dump it, do whatever you want with it).

Anyway, hope you can use some of this (I'm just glad the code is finding use somewhere)
Here a link to the last version I've got (bugs and all) : https://copy.com/txsNRWOuJAcd
2013... The year from hell....

This post has been edited 1 times, last edit by "Peryl" (Apr 11th 2014, 4:59pm)


74

Saturday, April 12th 2014, 7:07am

Great, Ill look through it and rebase.

My main priority is to have the base system without GUI up and stable (mainly as I havent done much ui stuff).

If any1 want to contribute... :)

best regards
frafall

75

Sunday, April 20th 2014, 12:34pm

Just uploaded v0.21, this is re-based on Peryl's latest version.

Major changes:
  • The Skills table is moved into FDVars, this has implications for combat scripts, they need to be modified as:

    Source code

    1
    2
    3
    4
    5
    
    local fd     = FuzzyDIYCE
    local api    = fd.API
    local fdvars = fd.FDVars
    -- local Skills = fd.Skills		-- Version =  0.1x
    local Skills = fdvars.Skills	-- Version >= 0.2x, rebased with Peryl's latest code


  • I've started using the extensions for everything thats not a plugin, i.e. registered with the 'RegisterPlugin' call.
  • Reorganized to use Peryl's directory structure for ui/media/lib folders.


Regards,
Frafall

Peryl

Intermediate

  • "Peryl" started this thread

Posts: 313

Location: Elsewhere

  • Send private message

76

Sunday, April 20th 2014, 7:40pm

Saw the crash bug that pietroasp posted in the other thread. The only thing I can think of that would do something like this is if the apartment for the code scripts and/or the main FD code apartment has somehow changed. This could mess things up enough to crash the game. So you may want to check if this is happening.

On another note, I guess I never really explained how the templated vars work (may be beneficial for some of your in-script functions). So here goes:

The basic idea for templated vars is that, like a function, you need to tell the variable some piece of information so that it returns the correct information, but don't want to have to create a special variable for each possible condition, yet still want to benefit from the data caching. To pull it off, I used a couple features of Lua. The first is that if trying to use a variable as if it was a function will trigger a lookup for a __call method in its metatable. The second is that if you use a single table as a parameter, you can omit the use of the parenthesis for the function call. This then allows us to do some fairly tricky stuff.

For an example of this, see how I defined and use the IsTargetType variable. (BTW, the args entry in the templated var definition was really added for the editor so that it would know what special parameters were allowed to this variable, it has no other use and can remain empty and/or non-existent).
2013... The year from hell....

77

Sunday, May 4th 2014, 6:30pm

Client crashes

I've had issues with client crashes, particularly when the skill named does not exist.

I.E. when We do a

Source code

1
try("skill", Skills["Bugged"].entry, true)

which would always crash client.

Due to a bug (mine) in the skill reading code the skill table was not correctly populated and perfectly valid scripts crashed the client, why it didn't happen when I tested I haven't looked into yet.

To rectify this I:
  1. Corrected the skill reading so it will always reflect the correct skill set
  2. Added a metatable with __index function to the Skills table to catch any invalid given skills named and print out a nice error report instead of crashing client. But for now I'm returning Attack on all unknown skills to make sure the try statement completes, I'll have to look into catching errors in the script compartment to make a streamline solution.


-frafall

78

Tuesday, May 13th 2014, 1:30pm

Thinking about usage of the 'try' statement, is there any good reason (like performance) for the statement to be as it is?

Source code

1
try("skill", Skills["Wound Attack"].entry, Bleeding and TargetHasBuff("Grievous Wound"))

For manual script writing it would be more natural (I think) to have it like ex.

Source code

1
try("skill", "Wound Attack", Bleeding and TargetHasBuff("Grievous Wound"))

and keep the lookup in the skill table internal in the 'try' statement.
  1. This would enable smoother error handling and debuggin
  2. Simplify interface for script writers


One could also argue for implementing new commands such as 'skill', 'action', 'petaction', this would avoid changing the 'try' command if its important to keep it as-is?

Any views Peryl?

-frafall

Peryl

Intermediate

  • "Peryl" started this thread

Posts: 313

Location: Elsewhere

  • Send private message

79

Tuesday, May 13th 2014, 1:59pm

From what I remember, the way I set it up was to have the ability to pass more than one thing as a single parameter. This allowed me to put pretty much anything as the second parameter which is data for try's sub-command (skill in this case). As these were to be generated by the GUI editor, I wasn't too concerened with how easy it was to edit manually.

Since each of try's sub-commands are essentially independent functions (called via the main try function), you could modify the code so that if it is given a string it would do a lookup for the skill in question in the Skills array itself and retrieve the required entry that way. Doing this would have minimal impact since the current method would still work.
2013... The year from hell....

Marvengus

Beginner

Posts: 14

Location: Netherlands

Occupation: Mathematician, Scientist

Mood: Smile

  • Send private message

80

Tuesday, May 13th 2014, 2:12pm

Hi, great to see a new evolution of DIYCE come to live. I've been DIYCE addict sine the first day I learned about it. Today I learned about this reincarnation, and am ready to become addict to this as well :) . I have only yet downloaded the addon and looked at code and combat scripts. Have not yet tried it yet.

The combat scripts look much cleaner than in previous DIYCE versions. I run quite some combo's, so my current CustomFunctions is a 680 line monster. I love being able to split the logic into a file per class-combi.
Next, I like the reload possibility, since restarting the client each time after I changed CustomFunctions was not funny. (Now I realize that I should have asked earlier for a work-around for that.)

Apart from these obvious and great advantages, are there other advantages of FuzzyDIYCE? What about speed?
Do we know inherent disadvantages, except for the fact that is is new and still has bugs, which should be just a matter of time to get resolved? :)

When looking at some combat scripts (mainly at RogueScout), the following questions came up:

I don't understand why hero and uni are such important parameters to the combat method. In my own DIYCE scripts, I do not even manage hero pots and unicorn through DIYCE. Personally, I would treat these just as any other Player Buff, if I wanted. For example, in my own DIYCE scripts I have logic like this to auto-eat housemaid food, and I would in FuzzyDIYCE want to do the same for hero pots (IF I wanted DIYCE to auto-drink hero-pots.)

Source code

1
2
3
4
	{ name = "Action: "..foodslot, use = ( (not pbuffs["Unimaginable Salad"])
								and (not pbuffs["Roast Leg of Lamb"]) 
								and (not pbuffs["Fried Salted Fish"]) 
								and (not pbuffs["Fried Rib"])) },


Same as previous post. I would even create multiple try methods, to prevent typo's in the first argument, and to allow specific argument lists per option, so e.g.

Source code

1
2
3
4
5
6
7
	-- Silence target skills
	trySkill( "Throat Attack", SilenceThis)
	-- Survival	
	trySkill( "Evasion", PlayerInCombat and PlayerHealthPct < .5)
	-- Maintain Hero, Speed pots, HP pots and stuff
	tryAction( hero, PlayerHasBuff("Hero Magic Medicine") and PlayerHasBuff("Hero Magic Medicine").time <= 5)
	tryAction( uni, PlayerHasBuff("Touch of the Unicorn") and PlayerHasBuff("Touch of the Unicorn").time <= 5)


This line from RogueScout

Source code

1
   try("skill", Skills["Sneak Attack"].entry, (not PlayerInCombat) and (IsTargetType("boss") or IsTargetType("elite")) and PlayerMana >= 20 and IsBehind)

I could miss-spell boss or elite in the strings, so you could alternatively create variables IsTargetBoss and IsTargetElite. Combined with previous remarks, we would get:

Source code

1
   trySkill( "Sneak Attack", (not PlayerInCombat) and (IsTargetBoss or IsTargetElite) and PlayerMana >= 20 and IsBehind)

In my opinion, more compact and better readable.

Any reason why 'try' starts with small t and IsTargetBoss starts with capital?

It would be great if I could talk about PlayerEnergy, PlayerRage, PlayerFocus, etc, instead of PlayerMana for the respective classes. Would that be possible?

In the following code, I think Bleeding relates to the target, but that isn't obvious from the name. Should perhaps be IsTargetBleeding? On the other hand, bleed is just a debuff, so perhaps should be like the grievous wound TargetHasBuff("Bleed"). In fact, these are de-buffs. Perhaps better to distinguish buffs and debuffs on target?

Source code

1
2
		try("skill", Skills["Wound Attack"].entry, Bleeding and TargetHasBuff("Grievous Wound"))
		try("skill", Skills["Low Blow"].entry, Bleeding)


Ok, a lot of feedback, hopefully not too stupid after having only read code and not ye played with it :) I intended to be constructive, and hope I managed to let it sound like that (English not being my mother language). :) Looking forward to the next iterations of FuzzyDIYCE and my own experiments.
Marvengo R/S/K (90/90/65)
Marvengus M/D/Wd (85/80/68 )
Playing on Isilitir (EU)
Guild Traumfaenger