Jump to content

  •  
- - - - -

New .def changes and scripting enhancments


  • Please log in to reply
13 replies to this topic

#1 Learner

Learner

    God

  • Administrators
  • 2451 posts

Posted 31 July 2018 - 01:11 PM

Recent changes have allowed map makers to add conditional testing of variables to areas to see if it is active or not, hide map objects based on conditions, and set or clear multiple variables when you enter certain areas or use map objects.

With a recent break through, I am now working on triggers which will be able to issue #commands commands and to support that I also created an NPC called God which has full IM permissions that will be able to process commands in the server as if an IM had typed them.

... All that means is that more automation and more feature will be available to IM's to add into .def files as well as them gaining #trigger and #delay commands to trigger canned actions with conditional testing (with or without a delay).

This also puts us much closer to having Quests & Invances now! Also means SAWolf will be able to start canning complete DTF & MBC Events which can be triggered by a single command without having to constantly issue new commands to keep them going.

This will be a major step forward in OL's abilities! All driven by .def files that the IM's and others helping to work with them will be able to create!

#2 Learner

Learner

    God

  • Administrators
  • 2451 posts

Posted 31 July 2018 - 01:19 PM

New IM commands going in:

#trigger trigger_name ....

Causes one or more canned triggers to be processed

#delay time_in_minutes trigger_name ....

Causes one or more triggers to be processed after N minutes of delay

#delay time_in_minutes #command

Issues the #command after waiting for the proper delay in minutes

#3 Learner

Learner

    God

  • Administrators
  • 2451 posts

Posted 31 July 2018 - 01:29 PM

New trigger definitions will be available

[TRIGGERS]

[TRIGGER]
name: trigger_name
chance: %chance
... more TBD
[CONDITIONS]
cond: variable_name condition variable_name|number|#roll
.... repeat as much as needed
[/CONDITIONS]
[VARIABLES]
var: variable_name = variable_name|number|#roll
... repeat as needed with other additional variations
[/VARIABLES]
[ACTIONS]
command: any valid IM or player command, such as #invade TML4_nasty or #delay 15 trigger_name
... repeat as needed
[/ACTIONS]
[/TRIGGER]

... repeat more trigger definitions
[/TRIGGER]

When a Trigger is processed, first the chance is checked, if that passes, then all the CONDITIONS are checked. If that passes, then the VARIABLES are processed, followed by ACTIONS.

The different sections will be gaining more features after the initial coding of this is in place ... and the features will be added to this as we move forward. These simple definitions are being used just to allow quick development now. There will also be other more automated ways that triggers could happen as well, such as walking or stepping in a place on a map.

#4 Learner

Learner

    God

  • Administrators
  • 2451 posts

Posted 02 August 2018 - 07:20 PM

After initial testing, the name: tag is being moved up to the [TRIGGERS] section and a desc: is being added to help IM's. This means when an IM or an action triggers via #trigger ... a list of possible triggers will be processed. Having a list instead of a single trigger is better in the long run.

Current status is the initial testing of triggers is working, and #triggers with multiple trigger names is working.

Next steps is getting #delay to work.

Then after more detailed testing we can look at more types of automated triggers. One that's been tested already is when an IM #reset_map on a map, it can trigger after it's done automatically

#5 Learner

Learner

    God

  • Administrators
  • 2451 posts

Posted 03 August 2018 - 02:11 PM

The current syntax being tested on Test is based on:

[TRIGGERS]
name: <trigger name>
desc: <description to show in WebAccess>

[TRIGGER]
flags: <special control flags for this trigger>
chance: <chance this trigger will even be processed>
[CONDITIONS]
cond: <variable name> <comparison> <variable name or #roll syntax or number>
.... repeat
[/CONDITIONS]
[VARIABLES]
var: <variable name> <simple math like = or +=> <variable name or #roll syntax or number>
... repeat
[/VARIABLES]
[ACTIONS]
command: <any valid #command or @syntax>
... repeat
[/ACTIONS]
[/TRIGGER]

... additional [TRIGGER] blocks

[/TRIGGERS]

#6 Learner

Learner

    God

  • Administrators
  • 2451 posts

Posted 04 August 2018 - 03:48 PM

We have tested running these in the following situations already:
* under IM control using #trigger to start processing
* under IM control after a delay using #delay to start it several minutes later
* under control of other triggers using either #trigger or #delay methos
* when the server starts up
* when a map is reset at start up or an IM resets a map

Just because Trigger gets run, doesn't mean it's do things. The Conditions test still decide for each step if it does anything or name, and those look at the named variables to decide.

Additional features not yet tested:
* when an NPC is started
* when a player enters a map
* when a players walks in an area or uses a map object
* New Day
* New Hour
* ... more will be added as they are needed when we also see it doesn't add much to the overhead

(not going to mention all the currently planned extensions)

SAWolf is already working to automate MBC to take the load of of IM's that one needs for timing each wave.

IM's already have a WebAccess page on Test to see defined triggers and a short description to help reduce errors.

#7 Learner

Learner

    God

  • Administrators
  • 2451 posts

Posted 05 August 2018 - 04:33 PM

A complete MBC in a single room has now been run from start to finish. SAW is going to be working on the other rooms and begin a DTF.

We both feel that there are now enough working & tested features that it would be possible to redo GIWS invasions totally using only .def files, including changing things based on the GIWS support level and not starting the next wave if all the GIWS mobs get wiped out. At this time though it's not high on the priority to convert GIWS or expand into DL.

With some more enhancements (like having info on invasion & player CL's) in theory some very complex smart invasions could be written ... and triggers/scripting attached to them. The [TRIGGERS] being able to issue any IM #command mean that if we could cause trigger processing under more conditions, spawn groups could get more interesting (example, the Boss entered the destination area ... run a trigger to find a ne place to wander to, think guards on patrol).

P,S, Some of these details might not all make sense .. but they add up to this feature giving a lot of power to trusted .def editors like SAW & Z instead of having ti code things explicitly into the server.

#8 Learner

Learner

    God

  • Administrators
  • 2451 posts

Posted 07 August 2018 - 02:20 PM

The Trigger Subsystem and some of the initial .def's for it are now on Main. Al we've tested the ability load in new trigger files without having to do a restart the server. That means once DTF is automated and tested, it can be loaded into Main.

#9 AlddrA

AlddrA

    Advanced Member

  • Full Member
  • PipPipPip
  • 590 posts
  • LocationCanada

Posted 07 August 2018 - 03:22 PM

nicePosted Image

#10 Learner

Learner

    God

  • Administrators
  • 2451 posts

Posted 09 August 2018 - 12:55 PM

A bunch of additional enhancements are currently in testing or being worked on. At this point, it looks like we can probably do every important thing in EL Instance/Invances except bonuses at the end?

Stuff includes running a trigger when mobs in a spawn are killed, the active boss in the spawn, or when the last mob in a spawn is killed, Others include if the mobs or the boss reach specific areas as alternatives.

#11 Learner

Learner

    God

  • Administrators
  • 2451 posts

Posted 09 August 2018 - 02:35 PM

View PostLearner, on 09 August 2018 - 12:55 PM, said:

A bunch of additional enhancements are currently in testing or being worked on. At this point, it looks like we can probably do every important thing in EL Instance/Invances except bonuses at the end?

Stuff includes running a trigger when mobs in a spawn are killed, the active boss in the spawn, or when the last mob in a spawn is killed, Others include if the mobs or the boss reach specific areas as alternatives.
A test I finished today also means that spawn groups can now gain waypoints, allowing them to move on to another destination when they succeed in reaching where they were headed. At this time I only tested the boss getting there, but more complex logic is possible given then flexibility that has been added.

#12 Learner

Learner

    God

  • Administrators
  • 2451 posts

Posted 09 August 2018 - 03:24 PM

For some of you wondering about the amount of information in this thread ... I'm working closely with SAWolf & Warlock to trained on the features to take advantage of them, with a side o keeping Z in the loop since some of these features directly affect him as well. A side effect is players are seeing some of the internal changes going on for the new features they don't normally see, Since this level of information I see no need to hide from players, it's good to let them peek. What IM's do with this on the other had is very different :ebul: !!!!

I'm sure we'll be seeing many more features being added to the game because of this and some future enhancements as we see additional requirements.  Those trying to compare this to EL ... all Instance/Invances are coded into the server by Radu, this allows a lot more to be done without having to touch server code!

#13 Learner

Learner

    God

  • Administrators
  • 2451 posts

Posted 25 August 2018 - 07:30 AM

Since the [CONDITIONS] and [VARIABLES] logic has been working well, after cleaning up the code, I can now use some unused space to enhance them to allow:

[CONDITIONS]
cond: <variable> <comparison> <variable or number>
cond: <variable> <comparison> <variable or number> <simple math> <variable or number>
cond: <variable> <comparison> <#ROLL syntax>
[/CONDITIONS]

[VARIABLES]
var: <variable> <simple assignment math> <variable or number>
var: <variable> <simple assignment math> <variable or number> <simple math> <variable or number>
var: <variable> <simple assignment math> <#ROLL syntax>
[/VARIABLES]

The big change is that when using a variable or a simple number, there is now an optional math operation using another variable or number permitted. This will allow doing a little bit more in one operation instead of needing two steps. Two steps will still be needed if the #ROLL syntax is being used.

<simple math> and <comparison> have also been enhanced with the logical operators of && (and) as well as || (or) as well.

All this is being done without requiring more storage and no noticeable performance hits when not used. Using the new features will have the effect of running more efficiently and using less storage then using multiple entries as needed in the past.

#14 Learner

Learner

    God

  • Administrators
  • 2451 posts

Posted 30 August 2018 - 12:13 PM

More new features are currently being tested, including a way to give extra bonus rewards to people in Events when certain milestones are reached, including winning the Event.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users