botanist

But Orange, there are no functions for that. So he will have to do calculations with the positions + size, and when the second dx position is less then the previous result, they will collide. Eg: dx1 starts at x=40, and is 60 wide. dx2 starts at 90. 40+60=100, so dx2 will collide. But what if dx2 starts at x=10? Then do it vice versa; dx2 will be calculated as dx1.

We already discussed some, and some not, so may this be a reminder for some urgent feats. - CTRL+X support - When using CTRL+V when having some text selected, the pasted text doesnt overwrite the selected text. - Home / End / Insert / Delete / Page down / Page up buttons have no effect - Same size characters so code will be be shown as in notepad++ or whatever editor. - Multi-script editting to prevent unsaved loss. - Not needing to restart resedit upon adding a resource Those are really important, got some possible features too. - Resourcebrowser as in MTASE. - Add a possibility to hide the functions list, or make F7 just full-full-screen - Option to restart the resource after being saved, and some button to do that.

I love to bump lol There was a method with pawn to add some code which makes it impossible to decompile the script. Well, impossible, the decompiled file only showed three lines of includes which might not even be present in the script itself. Just read some other topic about compiling, so that's what remind me of this. Now I'm wondering; isnt't there some code for lua to achieve the same?

getVehicleHandling returns a table indeed. If you do the following: local handlingTable = getVehicleHandling ( veh ) and you want to get the mass value, you usew the following: handlingTable["mass"] the centerOfMass is a bit trickier, as that returns a table itself. So, in order to get the Z position of centerOfMass, use the following: vehicleTable["centerOfMass"][3] -- Numbers: 1 = X, 2 = Y, 3 = Z Yes, a nested table But you ifyou dont want to get a complete table, and just retrieve the mass you could also use this: getVehicleHandling ( veh )["mass"]

But it's not in the handling editor as theres always just one edit opened. So it's a possible feature.

No, this error was caused by Izstas' object sync. I already linked you in the bugtracker to #5886, and has been fixed lately by ccw in r2846.

But I saw DoomedSpaceMarine doing this somehow on objects in his snow script

So you got an element containing spawnpoints? See the wiki for getElementChildren, this function returns a table which you can use to get a random spawnpoint. If thats not what youre looking for, please post an example of your elements containing the spawnpoints.

Lolwut, you developed the handling functions too?

That's no helping him, is it? He asked for an explanation, not stock unusable code. To your spawnpoints: Depends on what the parent is of the positions. Is it a table? Then you can use the above code in something like setElementPosition. That function will return all values in the table separated by a comma. So if you only got XYZ positions in your table, the following code should fit: setElementPosition ( element, unpack(theTable[math.random(#theTable)]) ) Loops might be a bit tricky for new users indeed. The most used loops are loops for tables and loops for numbers. Lets start with numbered tables. for i=1, 10 do -- block end In that code we want to loop all numbers from 1 to 10. This will be done in steps by one, and the var 'i' will store the current number. Now this shouldn't be hard You might also want to use other steps then by one. In the code below we added one extra argument to the loop, indicating how big our steps are. In this case we count from 10 to 1. for i=10, 1, -1 do -- block end Now we've had the easy part, we will loop some tables. These are quite different compared to regular tables, as they return two variables in the loop. Lets begin with the numbered tables. We all know them, table[1] = something. A function like getElementsByType will return such a table. We can loop this table using 'ipairs'. local allPlayers = getElementsByType ( "player" ) for i, v in ipairs ( allPlayers ) do -- block end As you see we have two variables now: i and v. 'i' will contain the current number being looped, so that's the 1 in table[1]. 'v' will contain the data of table, which is in this case the player. And yes, v is basically the same as table But theres also a second type of tables: The ones using a string as a key. For example table["somekey"] = something. In this case we can't usw ipairs, as ipairs only supports numbers. 'pairs' however supports string AND numbers. And theres another difference, pairs does not sort your table. So 1,2,3 might be looped as 2,3,1. for k, v in pairs ( sometable ) do -- block end We replaced the i variable for 'k' but basically contains the same. And once again, v is the same as table[k] Succes

@ JR10: That's called rough code, used to just show your scripting method. As Hyunsu said, the script runs fine. Ofcourse he isn't using such a code for real, as that wont even execute. @ Hyunsu: What do you mean exactly? Is the script running slower after an hour of playing? If that's the case, your system might get overheated and drop performance to cool down.

thats kinda here in this subforum, no need for a topic imo.

Weird, probably something messed up in the commit. No problems here, and I didn't made any changes since then. (I'mah lazy D:) Possible to do now. Some maths calculating the label position absolute to the screen to enable it to move around, and copy the menu's children to a new menu. Wouldn't even require template modifications. First going to fix import though, tried to make this, but a dead fly can do more than this function can at the moment..

Pwnalazord! Maybe someone used to much triggers? ^^ just kidding

Is that, nameless , server yours?

The scrollbar is a GUI, so clientside. EVERY calculation in handling is managed clientside either. But, if the calculation is done, and the data is ready to send to the server, it will use triggerServerEvent which is unavoidable. Set is only possible serverside. Get Hedit yourself to experience the problem. Get on your server with maybe 1 or 2 players, go the the modelFlags/handlingFlags menu, and get debugscript on 3. Now, keep clicking some checkbox as fast as you can. After a few seconds, nothing will happen, and you might get network trouble. A few seconds more, and something appears on your debug: Stack overflow. This means the script can't handle what you're doing, and will be aborted. Note this is only clientside, all the other triggers before this error are sent to the server. That's why you had network trouble. I'm able to fix this problem for the chatboxes by disallowing so much triggers, but it will be much harder to do so with scrollbars. I could only apply the settings after the scrollbar has been released, but this will give no smooth effect; thus no improvements to the current functionality.

Already thought about this, but I'm not going to do it unfortunately. I would be nice indeed, but the problem is that the GUI is clientside (ofcourse), and the set functions are serverside. So, imagine how much triggerServerEvents that will be when some noob is having fun with sliding the scrollbars. The checkboxes of modelFlags and handlingFlags are already causing problems which I need to fix. Might be doing this, but will have a low priority. There's a problem though. Some stuff is depending on the vehicle model, and might result in a block or crash if loading wrong data on the wrong vehicle.

You're correct, I dont know how I can automatically build downloads on GoogleCode. But, fortunately, a friend is willing to create a 'nightly'-like page for me. Might be online tomorrow already, were both gonna script it

Third demonstration video! It shows you the new, fully working GUI! Also, the new save/load functions and the stable utilities bar! And, a vehicle based log + flag support with checkboxes!

https://community.multitheftauto.com/index.php?p= ... ls&id=2229

L2script.

He added "function block end". That newbie probably doesn't know that I'm an experienced scripter, though my signature should make that clear... I'm only posting the part people need, not the whole script. He even forgot the () part after function

I see, the width of the scrollpane is nil. Obviously MTA bug, since nothing what I do solves it. But, when I fill in the width manually, the scrollpane will be created. But the thing I want still wont work. Doing guiSetVisible ( vehLog[pVeh], true ) later-on will return no error, but I dont see anything though. Also, outputting tostring ( vehLog[pVeh] ) just after the scrollpane has been created will output other userdata then outputting that in another file, where I want to show the scrollpane. E.g: create.lua outputs: "Userdata: 0005769" show.lua outputs "Userdata: 00057B0" So, those userdata are clearly different. The pVeh value will output everywhere the same though, so that value is not the problem. I'm pretty sure this is a MTA bug, but I need someone to confirm this. I'm getting really stressed because of this, I just want to get it working.

pVeh = getPedOccupiedVehicle ( localPlayer ) vehLog = {} if not vehLog[pVeh] then logX, logY = guiGetPosition ( logPane, false ) lodW, logH = guiGetSize ( logPane, false ) vehLog[pVeh] = guiCreateScrollPane ( logX, logY, logW, logH, false, mainWnd.window ) guiSetVisible ( vehLog[pVeh], false ) end -- logPane is a VALID gui scrollpane, with mainWnd.window as parent. -- mainWnd.window is a VALID gui-window ofcourse. No errors yet. Remember that pVeh is global, it's not getting changed until I get another vehicle. Whenever I use vehLog[pVeh], it will return false/nil. Making pVeh a string doesnt solve anything. So, whatthefack is going on here? Second time I'm trying to implement a vehicle-based log now in hedit, and it still won't work goddamnit.

That's the worst code possible. Better use this instead, since this one can have a queue infinetly long without having more script, and it calls itself after it's finished.. But this opened my eyes though, I can surely use it in my script local msg = {} local curMsg = 0 local acceptNew = true -- This could even be removed, just don't have the desire to do it -- on event/other function: msg[#msg+1] = "text" output ( ) end -- the function function output ( ) if acceptNew then acceptNew = false outputChatBox ( msg[curMsg] ) setTimer ( function ( ) if not curMsg == #msg then curMsg = curMsg + 1 output ( ) else acceptNew = true end, 1000, 1 ) end end @NeXTreme: That's just a normal table? eeh?