IIYAMA

If it was open source you wouldn't understand a damn about it. If you did(0.1% of the scripters), you would be able to make it on your own. So I don't see a ***** reason why it shouldn't be compiled.

The element(timer) will be destroyed. But the variable will still contain the userdata of the element(timer), which is invalid and can't be considered as a reference to an element. For example: (execute these lines in your code) -- We start a timer: local timer = setTimer(function()end,1000,1) -- We check the timer: outputChatBox("The userdata of the timer: " .. tostring(timer) .. ", is the timer an element: " .. (isTimer(timer) and "yes" or "no") .. "." ) -- Now we destroy it: killTimer(timer) -- And now we check the timer again: outputChatBox("The userdata of the timer: " .. tostring(timer) .. ", is the timer an element: " .. (isTimer(timer) and "yes" or "no") .. "." )

@#meS Line 11, a timer isn't the same as a function. @Rob A table isn't the same as a timer and a typo on line 3. Only Dimos7 code might work if you(#meS) add the event onClientGUIClick + killTimer part. Which you still haven't posted yet, it is stupid to say that it isn't working when you are not showing everything that is required to finish the code.

Another function will be implemented soon: (it is already finished, but for next version 1.0.1) [b]getPlayerMapStatus()[/b] Require: [i][color=#00FF00]element [/color]player, [color=#00FF00]string [/color]mapName[/i] Returns: [i][color=#00FF00]string [/color]status[/i] Or [i][color=#00FF00]boolean [/color]false[/i] Possible status: "DOWNLOADING" [color=#00FF00]-- Player is downloading the map.[/color] "LOADING" [color=#00FF00]-- Player is generating/loading the map[/color] "LOADED" [color=#00FF00] -- Player has loaded the map.[/color] false [color=#00FF00]-- Player variable is invalid or the player hasn't started downloading this map.[/color] And a new event: [color=#0000FF]"onPlayerCancelMapDownload"[/color] Source: [i][color=#00FF00]element [/color]player Arguments: [color=#00FF00]string [/color]mapName[/i] RELEASED 1.0.1

Hmm there you got a point, away with that word.

Map loader This is a map loader, which can let specific players download a map of choice. Maps will be generated clientside and the resource is capable of loading extreme large maps. Loading the map will be done with a speed the pc can handle. The code execution time will be reduced to circa 10 ms. Which is the frame time of a player with 100 fps. So technically when you have 100 fps you still have 98/100 fps when this resource is loading a map. But this is based on running only this resource and based on predictions/knowledge. Which you can't trust... The .map files are unloaded afterwards reading them. But the resource will keep a buffer of the processed data until no more players are using that map. This will speed up the resource when it is used for multiply players. The resource can be managed with the following functions (serverside): loadMapForTarget() Require: element player/root, string mapName Returns: boolean success, string message unloadMapForTarget() Require: element player/root, string mapName Returns: boolean success, string message getPlayerDownloadProgress() Require: element player Returns: int percentages or boolean false Version 1.0.1 or higher getPlayerMapStatus() Require: element player, string mapName Returns: string status or boolean false Status list: string "DOWNLOADING" -- Player is downloading the map. string "LOADING" -- Player is generating/loading the map string "LOADED" -- Player has loaded the map. boolean false -- Player value is invalid or the player hasn't started downloading this map. Events(serverside): "onPlayerLoadedMap" Source: element player Parameters: string mapName int loadTime "onPlayerUnloadedMap" Source: element player Arguments: string mapName Version 1.0.1 or higher "onPlayerCancelMapDownload" Source: element player Arguments: string mapName Events(clientside): "onClientPlayerLoadedMap" Source: element localPlayer Arguments: string mapName, int loadTime "onClientPlayerUnloadedMap" Source: element localPlayer Arguments: string mapName The same information about the functions and the events can be found inside the meta.xml Element types that are supported: objects, peds, vehicles, markers and pickups If you found any bugs, which might be in there. Don't be shy and let me know, I will exterminate them. And don't forget, this resource require some rights in order to read map files from other resources: DOWNLOAD 1.0.2 For developers a quick source code preview: Server Client

2 hours? > /debugscript 3 > 2 seconds.

No, just an unstable model(id or file) or MTA/GTA bug.

function myFunctionName () end myFunctionName = nil -- delete

Anyway, I will install this weekend 1.6, so I can release full project train directly after 1.6 comes out. (If there will be another beta, it will be in 1.6 too.) Another thing, the name of the resource(project train) sounds a little bit standard. So I might change it in something more creative. If you guys have any idea's for a better name, let me know.

Possible, yet you will use more bandwidth and server power.Two things you don't want. And the most critical part of moveObject is that it isn't using lightweight_sync when those objects aren't streamed out. The reason why I know this, is because I once created serverside projectiles with moveObject.

Because it is stupid to give clients rights for editing their score. This is what serverside and serverside only should do.

Yea, I have to calculate a lot. But that isn't really a problem, because I know how to do it. About spawning trains at the nearest spawnpoint, I don't have to spawn them at a spawnpoint. When you take the railroad, which is ... long, you splits it up in the amount of trains. You calculate the progress and you keep moving them on the correct location. Full version: Al thought there are no elements when the trains are streamed out. You still have to calculate where they are in order to keep it perfect synced. About timers, did you ever used the resource missiontimer? Well the thing about timers is that MTA is handling those. But somehow if I use too much of them they are starting to lagg. So if you have too much timers, you can also choose for lua to handle them. And in my opinion it works pretty well. Edit it as you want. (I just wrote it, it is NOT checked if everything is correct) local globalTimer = false local globalTimerContainer = {} local globalTimerFunction = function () local timeNow = getTickCount() for i=#globalTimerContainer,1,-1 do -- inverse the loop, important for table.remove. local timerData = globalTimerContainer[i] if timeNow > timerData["endTime"] then timerData["callbackFunction"](unpack(timerData["arguments"])) table.remove(globalTimerContainer,i) end end if #globalTimerContainer == 0 then killTimer(globalTimer) globalTimer = false end end local addTimer = function (...) local timerData = {...} local endTime = timerData[1] table.remove(timerData,1) local callbackFunction = timerData[1] table.remove(timerData,1) globalTimerContainer[#globalTimerContainer+1] = {["endTime"]=endTime,["callbackFunction"]=callbackFunction,["arguments"]=timerData} if not globalTimer or not isTimer(globalTimer) then globalTimer = setTimer(globalTimerFunction,100,0) end end --addTimer(endTime,callbackFunction,argument1,argument2,argument3, etc.) -------------------------------- function callThisFunctionBack(argument) outputChatBox(argument) end --addTimer(endTime,callbackFunction,argument1,argument2,argument3, etc.) addTimer(getTickCount()+1300,callThisFunctionBack,"IIYAMA")

Yea, about that competition I probably misunderstood. Since you mentioned it, it was bugging me. About the onClientRender > onClientPreRender part. (onClientRender is too slow) If players have different fps, they both see the same train-speed. Yet, the one with the highest fps will see a smoother animation. When players their fps are not the same, the collision detection is not the same. Not only with onClientPreRender but the same with setControlState, because this is something from gta. To prevent misunderstandings, I am not setting any trainspeed but it's position. Why position instead of trainspeed? You can predict it's next position(per frame) when you know how long the railroad is + how fast the custom trainspeed is. That is the big secret behind it... getTickCount() Which gives me the problem with stopping the train at stations. Why not using peds? There are too many players with bad internet, circa 70% of players that visit my stealth server. I just want stable trains controlled by serverside and executed by clientside. That's main reason why I build it this way. Anyway your script can also use some optimisation. You don't need a sync timer for all trains. Serverside can only execute every(all timers from the whole server) timer once in the circa 65 ms. Within those circa 65 ms no timer can get executed. You might think those timers are accurate, but they are far from it. 1 timer executing a loop would be enough. You can test it yourself with:(serverside) local lastExecution = 0 local executionFunction function (timerName) local timeNow = getTickCount() outputDebugString(timerName .. " " .. timeNow-lastExecution .. " delay (ms)") lastExecution = timeNow end addEventHandler("onResourceStart",resourceRoot, function () local startNextTimer = function () -- prepare the code of the second timer, so it has no delay when creating. setTimer(executionFunction,50,0,"timer2") end lastExecution = getTickCount() setTimer(executionFunction,50,0,"timer1") setTimer(startNextTimer,75,0) -- add an extra delay of 25 ms. end)

I took a look at it. But my inspiration came from gta itself. GTWtrain also took it's inspiration from GTA san, so... Or well I can better say you did... About the usage. As I said on top, client side isn't optimised. (far from it) - Trains are never be destroyed and they are clientside. - Yes, onClientPreRender. In order to keep it perfect synced without lagg. And no, I am not changing the speed. If I do this by changing the speed, the result would be a desync. You might say that rendering a position uses too much memory, I disagree with that. Your info about performance is based on 15* trains, which will be in the full release the streamed in trains(1). - I didn't disable the streamed in/out functionality and it doesn't have to be. When the trains are created they can't change track. *Depends how many you enable. AND a both all, this IS A BETA. What matters is that it works, optimisation comes with the full release. Go record these performance statics with the full release. Using them on a beta resource vs full resource is just... You might see this as a competition, but I am not busy with that part. I just want to build a perfect project which I like and doing it my way. If you want a competition, then I will decline it. /me not interested in that kind of childish stuff.

Aren't you listening? You have to prevent that the account gets bugged, not work around.

Nice! For 1.6 I assume? Because setTrainTrack+getTrainTrack will be released in 1.6 too.

http://www.steve-m.com/downloads/tools/colleditor2/ Afaik I got this software from this site, to split a castle mod.

True, but since there is no "onPlayerTeamChange" event, he has to search the whole dayz script to find places where the team has been set. And after that(+ adding exports), he can only use it for the dayz gamemode. That's why I suggested it that way. Woow, 2750 posts I am now a Foot Soldier O_o"

Why don't you fix the problem instead of solving it after it went wrong?

You have to check the players their team with an: infinity timer + player loop + table with their last team/teamcolor.

Btw. The beta resource is only available here. (not on the resource page) When the time comes, I will add full release on both. In my opinion beta resources are not meant for the resource page. Also if you find any more bugs next to misplaced trains or missing traincarts. Let me know, the more feedback I get the more I can fix.

@xXMADEXx Tip: Creating a gui to add child's to xml file. + - Checks if files exist. - Checks the info. (allowed characters etc.) Because if inexperience people make a typo, the whole xml file will be corrupted.

You can center the text inside it's boundingbox. No need for extreme calculations.

The root element, which is the result of the function getRootElement() (root = getRootElement()), is a dynamic element. Which can be anything and everything. While resourceRoot can't. If I pass down resourceRoot through my triggerEvent, it will be the source of next the eventHandler which is attached to that event. And now coming back to your question. When I define root in an addEventHandler, it will trigger at any element I am passing down. Which can be a player, a marker, a ped, a vehicle. But when I define the element I am passing down from the triggerEvent to the eventHandler, it can only be that element. The reason why I am using resourceRoot, is because I don't want to have conflicts with custom triggerEvents. Yet, it is not very important since that doesn't happen very often. Normally people write longer and complexer event names(like I did in this code). When you take a close look at your code now: Client triggerServerEvent([color=#0000FF]"onPlayerRequestingMusicData"[/color],[color=#FF0000]resourceRoot[/color]) Server addEvent([color=#0000FF]"onPlayerRequestingMusicData"[/color],true) addEventHandler([color=#0000FF]"onPlayerRequestingMusicData"[/color],[color=#FF0000]resourceRoot[/color], function () [color=#FF0000] -- source [/color] if isElement(client) then triggerClientEvent(client,[color=#00FF00]"onClientPlayerReceiveMusicData"[/color],[color=#FF0000]resourceRoot[/color],Music) end end) Client addEvent([color=#00FF00]"onClientPlayerReceiveMusicData"[/color],true) addEventHandler([color=#00FF00]"onClientPlayerReceiveMusicData"[/color],[color=#FF0000]resourceRoot[/color], function (Music) [color=#FF0000] -- source [/color] local row,col = guiGridListGetSelectedItem( grid ) if Music[row+1] and Music[row+1][2] then local sound = playSound3D (Music [row+1][2], x,y,z,true) if sound then setSoundVolume ( sound , 1 ) end end end)