User:Ccw: Difference between revisions
Jump to navigation
Jump to search
Cazomino05 (talk | contribs) No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
{{MTA Developer}} | {{MTA Developer}} | ||
== == | |||
=2012 October 7= | |||
==Propose to add two new functions== | |||
===addPreEventHandler and addPostEventHandler=== | |||
Adding these will help solve the following problems: | |||
:'''1. Only the function that triggered the event knows if the event was cancelled''' | |||
::As ''wasEventCancelled'' is only valid after all ''addEventHandler''s have been completed | |||
::(This also means its not possible to react to cancelling of inbuilt events) | |||
:'''2. Solve issue of cancelling events and really stopping them from doing anything''' | |||
::i.e. Cancel event in ''addPreEventHandler'' will stop ''addEventHandler'' being called altogether | |||
:'''3. Wanting to do things before/after events have occurred:''' | |||
::e.g. onResourceStart - Client has not been told to start yet, so some things like ''setPlayerTeam'' can't be done. | |||
::Adding ''addPostEventHandler("onResourceStart",...)'' means we can do stuff just after resource has really started on both server and client | |||
===Cancellation rules=== | |||
====Current (As it is now)==== | |||
*All '''addEventHandlers''' are called. | |||
====Proposal #1==== | |||
*All '''addPreEventHandlers''' are called. | |||
*If the event is not cancelled by any '''addPreEventHandler''' then: | |||
:*All '''addEventHandlers''' are called. | |||
:*If the event is not cancelled by any '''addEventHandlers''' then: | |||
::*All '''addPostEventHandlers''' are called. | |||
====Proposal #2 (allows for addPostEventHandlers to detect addEventHandler cancellation)==== | |||
*All '''addPreEventHandlers''' are called. | |||
*If the event is not cancelled by any '''addPreEventHandler''' then: | |||
:*All '''addEventHandlers''' are called. | |||
:*All '''addPostEventHandlers''' are called. ('''wasEventCancelled()''' will be true if event cancelled during '''addEventHandlers''') | |||
====Proposal #3 (allows for addPostEventHandlers to detect addPreEventHandlers and addEventHandler cancellation (but not distinguish which one))==== | |||
*All '''addPreEventHandlers''' are called. | |||
*If the event is not cancelled by any '''addPreEventHandler''' then: | |||
:*All '''addEventHandlers''' are called. | |||
*All '''addPostEventHandlers''' are called. ('''wasEventCancelled()''' will be true if event cancelled during '''addPreEventHandlers''' or '''addEventHandlers''') | |||
== == | == == |
Revision as of 01:02, 7 October 2012
2012 October 7
Propose to add two new functions
addPreEventHandler and addPostEventHandler
Adding these will help solve the following problems:
- 1. Only the function that triggered the event knows if the event was cancelled
- As wasEventCancelled is only valid after all addEventHandlers have been completed
- (This also means its not possible to react to cancelling of inbuilt events)
- 2. Solve issue of cancelling events and really stopping them from doing anything
- i.e. Cancel event in addPreEventHandler will stop addEventHandler being called altogether
- 3. Wanting to do things before/after events have occurred:
- e.g. onResourceStart - Client has not been told to start yet, so some things like setPlayerTeam can't be done.
- Adding addPostEventHandler("onResourceStart",...) means we can do stuff just after resource has really started on both server and client
Cancellation rules
Current (As it is now)
- All addEventHandlers are called.
Proposal #1
- All addPreEventHandlers are called.
- If the event is not cancelled by any addPreEventHandler then:
- All addEventHandlers are called.
- If the event is not cancelled by any addEventHandlers then:
- All addPostEventHandlers are called.
Proposal #2 (allows for addPostEventHandlers to detect addEventHandler cancellation)
- All addPreEventHandlers are called.
- If the event is not cancelled by any addPreEventHandler then:
- All addEventHandlers are called.
- All addPostEventHandlers are called. (wasEventCancelled() will be true if event cancelled during addEventHandlers)
Proposal #3 (allows for addPostEventHandlers to detect addPreEventHandlers and addEventHandler cancellation (but not distinguish which one))
- All addPreEventHandlers are called.
- If the event is not cancelled by any addPreEventHandler then:
- All addEventHandlers are called.
- All addPostEventHandlers are called. (wasEventCancelled() will be true if event cancelled during addPreEventHandlers or addEventHandlers)
2011 November 30
Notes for new ACL request system
In the resource meta.xml:
<aclrequest> <right name="function.kickPlayer" access="true"></right> <right name="function.banPlayer" access="true"></right> </aclrequest>
Console command 'aclrequest'
aclrequest list > aclrequest: resname has 2 aclrequest(s) of which 2 are pending aclrequest list resname > aclrequest: resname [pending] for function.kickPlayer > aclrequest: resname [pending] for function.banPlayer aclrequest deny resname all > aclrequest: resname function.kickPlayer changed to deny (Console) > aclrequest: resname function.banPlayer changed to deny (Console) aclrequest allow resname function.kickPlayer > aclrequest: resname function.kickPlayer changed to allow (Console) aclrequest list resname > aclrequest: resname [allow] for function.kickPlayer (by Console on 2011-11-29) > aclrequest: resname [deny] for function.banPlayer (by Console on 2011-11-29)
Script function #1:
table getResourceACLRequests ( resource theResource )
table return example:
{ {name="function.kickPlayer", access="true", pending="false", who="Console", date="2011-11-29" }, {name="function.banPlayer", access="false", pending="false", who="Console", date="2011-11-29" } }
Script function #2:
bool updateResourceACLRequest ( resource theResource, string rightName, bool access, string byWho )
This only works with right names that are returned from getResourceACLRequests.
Calling updateResourceACLRequest automatically sents the 'pending' to false and also sets the 'date'.
Permissions
The following are protected by default and will need an entry in the ACL:
function.updateResourceACLRequest command.aclrequest
Release dates
History
Version | Date | Highlights | User comments |
1.0 | 22 August 2009 | First release | DP2 was better |
1.0.1 | 02 October 2009 | Crash fixes and less lag | 1.0 was better |
1.0.2 | 24 October 2009 | Crash fixes | 1.0.1 was better |
1.0.3 | 17 December 2009 | Sync improved | 1.0.2 was better |
1.0.4 (r1752) | 7 June 2010 | Security improved | 1.0.3 was better |
1.0.4 (r1854) | 10 July 2010 | Crash fixes | It crashes more |
1.0.4 (r2033) | 14 October 2010 | Crash fixes | It crashes more |
1.0.4 (r2106) | 14 December 2010 | Browser improved | + |
1.0.5 (r2488) | 27 March 2011 | AC improved | It crashes more & 1.0.4 was better |
1.0.5 (r2519/2520) | 4 April 2011 | Performance fixed | 'It's almost as good as 1.0.2 now' |
1.0.5 (r2560) | 16 April 2011 | Performance improvements | |
1.1.0 | 25 August 2011 | Many new features | Possibly the worst thing that has happened in the history of the world |
1.1.1 | 20 September 2011 | Accumulation of post release fixes | Lags more than 1.1 |
1.2 | 17 December 2011 | RakNet fix for serious network related problems | ??? |
1.3 | 24 January 2012 | Map Download fix + loads of misc bug fixes | ??? |
1.3.1 | 03 September 2012 | loads of bug fixes and a boat load of new features | 1.3 was better |