User:Ccw: Difference between revisions

From Multi Theft Auto: Wiki
Jump to navigation Jump to search
No edit summary
(Undo revision 47302 by Bonzo1 (talk))
 
(25 intermediate revisions by 4 users not shown)
Line 3: Line 3:


== ==
== ==
=2011 October 22=
=2015 June 16=
==How do you solve a problem like my server stalling?==
==onPlayerNetworkStatus / onClientPlayerNetworkStatus==
''Answer: coroutines and threaded database access''
Experimental network interruption detection introduced in r7295. Both client and server have to be r7295 or later for it to work<br/>


=====Propose 3 new database access functions:=====
==Event Parameters:==
==dbQuery==
* '''status''': A number which is 0 if the interruption has begun, or 1 if the interruption is ending
* '''ticks''': Number of ticks since the interruption started
 
 
Server example:
<syntaxhighlight lang="lua">
<syntaxhighlight lang="lua">
handle dbQuery( sting query )
addEventHandler( "onPlayerNetworkStatus", root,
  function( status, ticks )
    if status == 0 then
      outputDebugString( "(packets from " .. getPlayerName(source) .. ") interruption began " .. ticks .. " ticks ago" )
    elseif status == 1 then
      outputDebugString( "(packets from " .. getPlayerName(source) .. ") interruption began " .. ticks .. " ticks ago and has just ended"" )
    end
  end
)
</syntaxhighlight>
</syntaxhighlight>
*'''dbQuery''' starts a database query and returns a handle


==dbPoll==
 
Client example:
<syntaxhighlight lang="lua">
<syntaxhighlight lang="lua">
table dbPoll( handle[, int timeout = 0, bool autoFree = true ] )
addEventHandler( "onClientPlayerNetworkStatus", root,
  function( status, ticks )
    if status == 0 then
      outputDebugString( "(packets from server) interruption began " .. ticks .. " ticks ago" )
    elseif status == 1 then
      outputDebugString( "(packets from server) interruption began " .. ticks .. " ticks ago and has just ended" )
    end
  end
)
</syntaxhighlight>
</syntaxhighlight>
*'''dbPoll''' returns the result of the query started with the supplied handle, or nil if the query has not completed yet. Setting timeout above 0 will make the function wait a bit longer if the query is not ready. A timeout of -1 will make it wait for ever. If autoFree is true, the query handle gets automatically freed when '''dbPoll''' is able to return a result


==dbFree==  
 
 
== ==
=2013 July 14=
==Things==
* Projectiles get removed (or not added, or something) by GTA, but MTA thinks it has a projectile, except it's got like a building. (SetMatrix == crash)
* <strike>Player customizing resource keybinds no worky</strike>
 
== ==
=2013 May 10=
==Random crashes in GTA==
===Consider this===
*During "onClient.." events, entities can be created/destroyed/change model etc.
*"onClient.." events can occur in the depths of GTA game processing.
This could be one of the causes of the random crashes we get.
 
===Solution:===
Queue the events, and trigger them once GTA has finished it's main loop.<br/>
Although a few events require immediate feedback, so can't be queued. These events are:
*onClientPlayerChoke
*onClientPlayer/PedDamage
*onClientPlayer/PedHeliKilled
*onClientPlayer/PedHitByWaterCannon
*onClientObjectDamage
*onClientObjectBreak
*onClientExplosion
*onClientWeaponFire
 
 
Not queueing the above events means:
* They will always get triggered before the (now) queued events, for that frame. (I don't think this change of behaviour will be a big problem though.)
* If create/destroy/anything is done during these events, there will still be a problem with crashes. But we can worry about that later.
 
 
''Might I suggest source elements cannot be deleted in events as a generic rule?''
--[[User:Cazomino05|Cazomino05]] 22:07, 12 July 2013 (UTC)
 
== ==
=2013 March 2=
==Propose source file banner credit overhaul #2==
===Problems with current source file credits:===
* Little value as a goto guy guide
* No one knows when to add their name to the list
* Encourages file additions, rather than feature additions
* As an information source is it quite useless and eventually misleading
 
===Proposal:===
* Remove the 'DEVELOPERS:' section in the source files where the current listed devs agree.
* In files they do not agree, add the names of all the other devs to teach them a lesson.
* Add a 'developers.txt' somewhere with all devs names (and what they did if anyone can be bothered to document it).
* Include developers.txt in each module
 
 
== ==
=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''')
 
 
== ==
=2011 November 30=
==Notes for new ACL request system==
 
====In the resource meta.xml:====
<syntaxhighlight lang="lua">
<syntaxhighlight lang="lua">
dbFree( handle )
<aclrequest>
    <right name="function.kickPlayer" access="true"></right>
    <right name="function.banPlayer" access="true"></right>
</aclrequest>
</syntaxhighlight>
</syntaxhighlight>
*'''dbFree''' makes a handle go away and never come back




===Example usage of the above three functions:===
====Console command 'aclrequest'====
Perform a query such as UPDATE, without waiting for the result (super fast)
<syntaxhighlight lang="lua">
<syntaxhighlight lang="lua">function dbQueryExec(...)
aclrequest list
    local handle = dbQuery(...)
> aclrequest: BobsGame has 2 aclrequest(s) of which 2 are pending
    dbFree(handle)
end</syntaxhighlight>


aclrequest list BobsGame
> aclrequest: BobsGame [pending] for function.kickPlayer
> aclrequest: BobsGame [pending] for function.banPlayer


Perform a query such as SELECT, and wait for the result (super slow)
aclrequest deny BobsGame all
<syntaxhighlight lang="lua">function dbQueryResult(...)
> aclrequest: BobsGame function.kickPlayer changed to deny (Console)
    local handle = dbQuery(...)
> aclrequest: BobsGame function.banPlayer changed to deny (Console)
    return dbPoll(handle,-1)
end</syntaxhighlight>


aclrequest allow BobsGame function.kickPlayer
> aclrequest: BobsGame function.kickPlayer changed to allow (Console)


Perform a query such as SELECT, and yield until the result is ready (avoids server stalling, but must be called in a coroutine)
aclrequest list BobsGame
<syntaxhighlight lang="lua">function dbQueryLatent(...)
> aclrequest: BobsGame [allow] for function.kickPlayer (by Console on 2011-11-29)
    local handle = dbQuery(...)
> aclrequest: BobsGame [deny] for function.banPlayer (by Console on 2011-11-29)
    local result
</syntaxhighlight>
    do
        coroutine.yield()
        result = dbPoll(handle)
    until result ~= nil
    return result
end</syntaxhighlight>




====Script function #1:====
<syntaxhighlight lang="lua">
table getResourceACLRequests ( resource theResource )</syntaxhighlight>


== ==
table return example:
=2011 October 2=
<syntaxhighlight lang="lua">
==Master Plan 8012==
{ {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" } }
</syntaxhighlight>


===Outline===
To enhance MTA, keeps devs motivated and ensure stuff actually gets tested and used, I propose that features developed in the trunk be backported to the current version where possible.


===Problem===
====Script function #2:====
However, when scripters start to use the new features, there will be compatibility problems with some servers & clients.
<syntaxhighlight lang="lua">
bool updateResourceACLRequest ( resource theResource, string rightName, bool access, string byWho )</syntaxhighlight>


===Solution===
This only works with right names that are returned from getResourceACLRequests.<br>
Therefore I present to you 'Master Plan 8012', which is:
Calling updateResourceACLRequest automatically sents the 'pending' to false and also sets the 'date'.


* When a script is loaded into a server, its minimum version requirement is evaluated.
** If the script requires an updated server, it should not run and instead inform the server owner to update
** When the script is running, connecting clients below the script required minimum version are auto-updated
==== Benefits of this plan are:====
* Scripters can use latest functions and not worry about checking version numbers and such
* Server owners can use any scripts without have to worry about setting <minclientversion> etc
* And more players will update because they will have a compelling reason to do so. (i.e. To join fav server)


====Permissions====
The following are protected by default and will need an entry in the ACL:
<syntaxhighlight lang="lua">function.updateResourceACLRequest
command.aclrequest
</syntaxhighlight>




Line 127: Line 240:
| 14 December 2010
| 14 December 2010
| Browser improved
| Browser improved
| +
|  
|-
|-
| 1.0.5 (r2488)
| 1.0.5 (r2488)
Line 148: Line 261:
| Many new features
| Many new features
| Possibly the worst thing that has happened in the history of the world
| Possibly the worst thing that has happened in the history of the world
|
|-
|-
| 1.1.1
| 1.1.1
Line 154: Line 266:
| Accumulation of post release fixes
| Accumulation of post release fixes
| Lags more than 1.1
| 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
|-
| 1.3.2
| 05 May 2013
| Added features, improved performance
| No thanks, I'm sticking with 1.3.1
|-
| 1.3.3
| 01 July 2013
| Anti-cheat updates and "optimus" fixes
| The game might run better when "optimus" fix is enabled so sticking with 1.3.1
|-
| 1.3.5
| 24 Feb 2014
| Anti-cheat updates and Lua additions
| 1.3.5 broke my internet
|}
|}
<br>
<br>

Latest revision as of 14:54, 1 April 2016

Coder.gif This user is an MTA developer

2015 June 16

onPlayerNetworkStatus / onClientPlayerNetworkStatus

Experimental network interruption detection introduced in r7295. Both client and server have to be r7295 or later for it to work

Event Parameters:

  • status: A number which is 0 if the interruption has begun, or 1 if the interruption is ending
  • ticks: Number of ticks since the interruption started


Server example:

addEventHandler( "onPlayerNetworkStatus", root,
  function( status, ticks )
    if status == 0 then
      outputDebugString( "(packets from " .. getPlayerName(source) .. ") interruption began " .. ticks .. " ticks ago" )
    elseif status == 1 then
      outputDebugString( "(packets from " .. getPlayerName(source) .. ") interruption began " .. ticks .. " ticks ago and has just ended"" )
    end
  end
)


Client example:

addEventHandler( "onClientPlayerNetworkStatus", root,
  function( status, ticks )
    if status == 0 then
      outputDebugString( "(packets from server) interruption began " .. ticks .. " ticks ago" )
    elseif status == 1 then
      outputDebugString( "(packets from server) interruption began " .. ticks .. " ticks ago and has just ended" )
    end
  end
)


2013 July 14

Things

  • Projectiles get removed (or not added, or something) by GTA, but MTA thinks it has a projectile, except it's got like a building. (SetMatrix == crash)
  • Player customizing resource keybinds no worky

2013 May 10

Random crashes in GTA

Consider this

  • During "onClient.." events, entities can be created/destroyed/change model etc.
  • "onClient.." events can occur in the depths of GTA game processing.

This could be one of the causes of the random crashes we get.

Solution:

Queue the events, and trigger them once GTA has finished it's main loop.
Although a few events require immediate feedback, so can't be queued. These events are:

  • onClientPlayerChoke
  • onClientPlayer/PedDamage
  • onClientPlayer/PedHeliKilled
  • onClientPlayer/PedHitByWaterCannon
  • onClientObjectDamage
  • onClientObjectBreak
  • onClientExplosion
  • onClientWeaponFire


Not queueing the above events means:

  • They will always get triggered before the (now) queued events, for that frame. (I don't think this change of behaviour will be a big problem though.)
  • If create/destroy/anything is done during these events, there will still be a problem with crashes. But we can worry about that later.


Might I suggest source elements cannot be deleted in events as a generic rule? --Cazomino05 22:07, 12 July 2013 (UTC)

2013 March 2

Propose source file banner credit overhaul #2

Problems with current source file credits:

  • Little value as a goto guy guide
  • No one knows when to add their name to the list
  • Encourages file additions, rather than feature additions
  • As an information source is it quite useless and eventually misleading

Proposal:

  • Remove the 'DEVELOPERS:' section in the source files where the current listed devs agree.
  • In files they do not agree, add the names of all the other devs to teach them a lesson.
  • Add a 'developers.txt' somewhere with all devs names (and what they did if anyone can be bothered to document it).
  • Include developers.txt in each module


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: BobsGame has 2 aclrequest(s) of which 2 are pending

aclrequest list BobsGame
> aclrequest: BobsGame [pending] for function.kickPlayer
> aclrequest: BobsGame [pending] for function.banPlayer

aclrequest deny BobsGame all
> aclrequest: BobsGame function.kickPlayer changed to deny (Console)
> aclrequest: BobsGame function.banPlayer changed to deny (Console)

aclrequest allow BobsGame function.kickPlayer
> aclrequest: BobsGame function.kickPlayer changed to allow (Console)

aclrequest list BobsGame 
> aclrequest: BobsGame [allow] for function.kickPlayer (by Console on 2011-11-29)
> aclrequest: BobsGame [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
1.3.2 05 May 2013 Added features, improved performance No thanks, I'm sticking with 1.3.1
1.3.3 01 July 2013 Anti-cheat updates and "optimus" fixes The game might run better when "optimus" fix is enabled so sticking with 1.3.1
1.3.5 24 Feb 2014 Anti-cheat updates and Lua additions 1.3.5 broke my internet