User:Snert: Difference between revisions
No edit summary |
|||
(One intermediate revision by the same user not shown) | |||
Line 107: | Line 107: | ||
onClientVehicleDamage ( float loss ) -- Server-side version already exists, if only there'd be an easy way for it client-side... | onClientVehicleDamage ( float loss ) -- Server-side version already exists, if only there'd be an easy way for it client-side... | ||
</syntaxhighlight> | </syntaxhighlight> | ||
==Nitro builds== | |||
TODO: | |||
* Fix issue where activating NOS without actually having NOS installed would make the car act extremely weird | |||
* Add a function to allow players to re-activate NOS while it's recharging | |||
* Add events | |||
* Sync nitro to remote players (only on/off state would be necessary for remote players, I guess) | |||
* Fix some more stuff | |||
* Commit, document, and all that | |||
Work-in-progress patch: http://dl.dropbox.com/u/4504893/patches/nitro.patch | |||
==FX functions== | ==FX functions== | ||
Line 146: | Line 159: | ||
setSunSize | setSunSize | ||
setFarClipDistance | setFarClipDistance | ||
setHeatHaze | |||
-- We'll need | -- We'll need | ||
setLightningEnabled | setLightningEnabled | ||
setMoonSize -- Like if you shoot the moon, it resizes. Hopefully it will be possible to hide it altogether, or make some sort of half-moon out of it | setMoonSize -- Like if you shoot the moon, it resizes. Hopefully it will be possible to hide it altogether, or make some sort of half-moon out of it |
Latest revision as of 19:43, 23 May 2011
Resources
Debug monitor
Resource to easily be able to view server and client debug messages. (remotely)
Created as an example to demonstrate the use of on(Client)DebugMessage.
Images:
Server-side debug message viewer: http://dl.dropbox.com/u/4504893/images/debugmonitor_editor_s.png Client-side debug message viewer: http://dl.dropbox.com/u/4504893/images/debugmonitor_editor_c.png
Download (Note: Only works in 1.1 r2091 and later)
Camo vehicles
When this resource is enabled, boats will get the same color as the water, and planes will get the same color as the sky. What's not to like?
Created as an example to demonstrate the use of getWaterColor, getSkyGradient and RGB vehicle colors.
Camoplane example: http://www.xfire.com/video/3bcb4b/
Download (Note: Only works in 1.1 r2093 and later)
Runcode++
Guess you should be able to guess it's related to runcode, but it's not a simple command. It's a GUI version of Runcode, with functions like:
- Multi-line input
- Being able to save and load script files
- Being able to edit multiple script files at the same time
Please note that this is an old resource of mine, and I'm just releasing it because it might be useful for development or someone might simply like the idea. I'm planning to continue on this if there's some sort of getFilesAtLocation to store script files client-side, without hassle.
Download (Note: Work-in-progress, old and not extensively tested)
Other potentially useful stuff
SA Weather table
I'm trying to make the timecyc.dat file a lot more readable, mostly for me to be able to make new functions. But I guess it might be useful to scripters as well, if they're for instance intending to use the weather functions to create their own weather system.
Download (Note: Work-in-progress)
Function suggestions
Some functions I should work on sometime soon. (sort of my "TODO")
Server-side
table getAllAccountData ( account theAccount ) bool setAllAccountData ( account theAccount, table theData ) bool setVehicleAdjustableProperty ( element theVehicle, int value ) int getVehicleAdjustableProperty ( vehicle theVehicle )
Client-side
-- None at the moment
Both
setVehicleNitrousActivated ( vehicle theVehicle, bool toggle ) -- Being able to influence NOS would be great (should block GTA from disabling it as well) isVehicleNitrousActivated ( vehicle theVehicle ) -- Obvious function is obvious setVehicleNitrousRechargeDelay ( vehicle theVehicle, int delay ) -- Function to set the amount of time the driver has to wait to reactivate NOS getVehicleNitrousRechargeDelay ( vehicle theVehicle ) setStreetLightsEnabled ( bool toggle ) -- Got to try and find the address for this first though setBackgroundGunshotsEnabled ( bool toggle ) -- Gotta find this one as well.. again... setBirdsEnabled ( bool toggle ) -- I hate those pesky poopers at times.. Besides, it doesn't fit in some circumstances.. There seems to be a function for this in the source areStreetLightsEnabled ( ) areBackgroundGunshotsEnabled ( ) areBirdsEnabled ( ) setPedBreath ( ped thePed, float breath ) -- For breath, as used underwater. Gotta find a way to set it for all peds, not just for the local player getPedBreath ( ped thePed ) isEventAdded ( string eventName ) -- Should be fairly obvious isEventHandlerAdded ( string eventName, element attachedTo[, function handlerFunction ] ) -- Should be fairly obvious as well
Event suggestions
Events which might be quite useful. I should work on these sometime soon.
Server-side
onElementCreate ( ) -- Triggered when an element was created onVehicleNitrousActivated ( ) -- Should be fairly obvious onVehicleNitrousDeactivated ( ) -- Should be fairly obvious onVehicleTireStateChanged ( int tire, int state ) -- If you'd want vehicles with bulletproof wheels or something, you'd need to detect the state change first
Client-side
onClientElementCreate ( ) -- See server-side onClientVehicleNitrousActivated ( ) -- See server-side onClientVehicleNitrousDeactivated ( ) -- See server-side onClientVehicleTireStateChanged ( int tire, int state ) -- See server-side onClientVehicleDamage ( float loss ) -- Server-side version already exists, if only there'd be an easy way for it client-side...
Nitro builds
TODO:
- Fix issue where activating NOS without actually having NOS installed would make the car act extremely weird
- Add a function to allow players to re-activate NOS while it's recharging
- Add events
- Sync nitro to remote players (only on/off state would be necessary for remote players, I guess)
- Fix some more stuff
- Commit, document, and all that
Work-in-progress patch: http://dl.dropbox.com/u/4504893/patches/nitro.patch
FX functions
Doomed_Space_Marine did research on some particle effects on custom models. It would be very cool if we could make functions to do this instead, like we already can with some particle effects. (for instance: fxAddBlood) This would especially be very cool if we would be able to alter the fx, so for instance we could create colored smoke.
fxAddHeliKillBlood fxAddCarWashEffect fxAddCement fxAddClouds -- Note: It's a rather vague type of effect fxAddCokeTrail fxAddShower -- Note: Classed as "some water effect", but unknown what type of water effect. Assuming shower fxAddSmoke fxAddPour -- Seems more like it should be fxAddPee or fxAddPiss though fxAddLeaves fxAddSpray fxAddFireExtinghuiserEffect fxAddFlamethrowerFlame fxAddInsects
Weather functions
Warning: This section is for serious weathermen only!
I recently noticed how many functions MTA actually has to influence the weather. It would be quite awesome if we would be able to influence litterally every factor.
-- We currently have setWaveHeight setSkyGradient setWindVelocity setCloudsEnabled setWaterColor setRainLevel setFogDistance setSunColor setSunSize setFarClipDistance setHeatHaze -- We'll need setLightningEnabled setMoonSize -- Like if you shoot the moon, it resizes. Hopefully it will be possible to hide it altogether, or make some sort of half-moon out of it setSandStormEnabled -- Some more stuff that might be good to give scripters control of (all from timecyc.dat) setAmbienceColor -- Sets the color (filter) of objects (or so I assume) setDirectLightColor -- Sets the color (filter) of vehicles and peds setSpriteBrightness setShadowIntensity setLightShadingValue setLightOnGround setLowerCloudColor -- NOTE: It is assumed that this is the clouds which sort of fly around low, the type of clouds which aren't disabled yet by setCloudsEnabled. Thus, important setUpperCloudColor setColorCorrection -- Prolly the heck of a lot more
MTA proposals
Getting contents of folders
The current system for files is fine, but it could be better. For instance, there's no way to know what files are in a folder, unless you specifically try to keep track of them. In most cases this is fine, but it could of course be very useful in some cases to be able to locate all files / folders inside a specific folder.
Proposed functions
Note: Names pending
getFilesAtLocation getFoldersAtLocation
Possible uses
- Radio scripts could easily allow players adding their own music, without having to edit a XML file or any manual setup
- Script editors could immediately detect all available scripts without having to inspect the meta.xml
- Scripts will be able to store things like replay files without having to keep track of them in an XML file
Obstacles
- It should be compatible with both Linux and Windows server-side. Client-side windows only isn't an issue, but on the server it is
- Filepaths were always intended to point towards individual files instead of folders. A workaround for this should be found, if there functions were to be added
- Possibly some other stuff
Basic hackpatch
I've attempted to make support for these functions a few days ago. I actually "succeeded" in it, client-side only, getFilesAtLocation only and very hackily implemented. But oh well, it'd give the general idea.
Example usage:
crun getFilesAtLocation(":runcode")
What's wrong with just exporting the POSIX functions into MTA? Could even make them Lua iterators, so you could do for entry in directory(":runcode") do print(entry.name .. ", file? " .. entry.isFile) end --Alberto Alonso 03:15, 21 December 2010 (UTC)
Serverlist independence
The server browser has always been an issue in MTA. People often complain about game-monitor being down or just being plain slow. Also, servers only show up on game-monitor after a long amount of uptime, or sometimes they don't show up at all. So, we'll need to change something. That's for sure.
Note: I didn't do a lot of reseach as to how it works currently
My proposal
In short: Support third-party server browsers
In a bit more detail:
- Servers will get new options in which they'll be able to make their own list of server browsers they want to appear on
- Clients will get a new GUI in which they'll be able to make their own list of server browsers to request the server lists from
- The server will update all server browsers in its list periodically (and at startup, of course)
- The client can now check out all server browsers, and merge all results into a list
This should remove dependency on specific server browsers, and therefore it should make the server browser so much more useful. (Because of less downtime and probably fuller serverlists)
Problems to overcome
- The server should not wait for the server browser query to be completed
- Each server browser should get its own update thread, to ensure they won't block eachother either
- The merging of the server browsers at the client might be tricky. You'd have to know which entry is the most recent one, and use that, while not waiting until all browsers have finally returned their results
- Not sure how the server browser works currently, but in case the client queries the data directly from the MTA server, ignore this. If not, it would still be a good idea
- There should be multiple official server lists
- All server lists should use the same protocol
Other stuff
Servers should have a setting like this:
<serverlists> <serverlist location="www.game-monitor.com"/> <!-- not sure bout the link itself, but it's the general idea --> <serverlist location="www.mtasa.com"/> <serverlist location="www.mtaserverlist.com"/> <...> </serverlists>
Client-side there should also be a GUI for this, with the possibility to name specific server browsers to make organising the list a lot easier. It should also list stuff like average ping, results and downtime, for convenience. Also, it would be useful to have another GUI which will fetch a list of server browsers from the internet, so people can quickly add new server browsers, or re-add official server browsers they previously removed.
Memory addresses
Here are a couple of memory addresses which might be useful for implementing new functions, so I can't forget them.
Variables
Variables I've discovered through playing around with Cheat Engine
Purpose | Address | Address type | Comments |
---|---|---|---|
LS Street lights enabler | 0x0960CF4 | bool (byte) | Automatically 1 at night (in LS); Setting this to 0 causes a new light corona to be created at all LS street lights |
Functions
Functions which are setting the above variables. Got these from Cheat Engine as well.
Related to | Address | Bytes | Assembly | Comments |
---|---|---|---|---|
LS Street lights enabler | 0x0408989 | c6 87 d0 4c 8e 00 02 | mov byte ptr [edi+008e4cd0],02 | |
LS Street lights enabler | 0x040cea3 | c6 45 10 03 | mov byte ptr [ebp+10],03 | |
LS Street lights enabler | 0x040cb71 | c6 83 d0 4c 8e 00 01 | mov byte ptr [ebx+008e4cd0],01 |
TODOcument
Functions
getRainLevel ( ) setRainLevel ( float rainLevel ) resetRainLevel ( ) getFogDistance ( ) setFogDistance ( float distance ) resetFogDistance ( ) getFarClipDistance ( ) setFarClipDistance ( float distance ) resetFarClipDistance ( ) getSunColor ( ) setSunColor ( [ int coreR, int coreG, int coreB, int coronaR, int coronaG, int coronaB ] ) resetSunColor ( ) getSunSize ( ) setSunSize ( float size ) resetSunSize ( ) areInteriorSoundsEnabled ( ) setInteriorSoundsEnabled ( bool enabled ) isElementFrozen ( element theElement ) -- Also mark the functions it replaced as "deprecated" setElementFrozen ( element theElement, bool frozen ) -- Same here, of course
Element map properties
Vehicle: - frozen = bool frozen Ped: - frozen = bool frozen Object: - frozen = bool frozen - collisions = bool collisionsEnabled - scale = float objectScale