icedsun

After searching the mantis site, I found that they changed it on purpose to be this way starting in v1.0 -- so I'll just have to rewrite all my stuff

After searching the mantis site, I found that they changed it on purpose to be this way starting in v1.0 -- so I'll just have to rewrite all my stuff

Hmm, well if it is proper syntax, then I'll have to do a bugreport because it seems as though it's not supported anymore. Here's an example script to see: (if i'm just screwing something up let me know!!!) executeSQLCreateTable("mytable","id INT,type TEXT,xloc REAL") executeSQLInsert("mytable","'101','vehicle','482.456'") local out = executeSQLSelect("mytable","*") outputServerLog("Regular: "..tostring(out)) outputServerLog("ColName: "..tostring(out[1].id)) outputServerLog("ColNum: "...tostring(out[1][1])) outputs this: Regular: table: 01BA3C88 ColName: 101 ColNum: nil It's sometimes really useful to iterate through when they're returned numerically, but I'm sure it's possible to do through the actual names as well. But, like I said, if it's supposed to perform both ways, it doesn't seem to be.

Hmm, well if it is proper syntax, then I'll have to do a bugreport because it seems as though it's not supported anymore. Here's an example script to see: (if i'm just screwing something up let me know!!!) executeSQLCreateTable("mytable","id INT,type TEXT,xloc REAL")executeSQLInsert("mytable","'101','vehicle','482.456'")local out = executeSQLSelect("mytable","*")outputServerLog("Regular: "..tostring(out))outputServerLog("ColName: "..tostring(out[1].id))outputServerLog("ColNum: "...tostring(out[1][1])) outputs this: Regular: table: 01BA3C88 ColName: 101 ColNum: nil It's sometimes really useful to iterate through when they're returned numerically, but I'm sure it's possible to do through the actual names as well. But, like I said, if it's supposed to perform both ways, it doesn't seem to be.

I've recently returned from a long coding absence (haven't been active since dp2). I've been trying to get some of my old scripts updated for 1.0.3 and have been having trouble with some basic SQL stuff. It seems that there were some changes between the dp2 version and 1.0.3. The executeSQLDropTable function now works correctly. The executeSQLQuery also seems to be working correctly now, and the 512 character limit has been increased. Both are wonderful! However, the trouble I'm running into now is that in dp2, I could do this: local itemVis = executeSQLSelect("objectVisuals","shape,size,texture,fixins","id='taco'") outputConsole("The taco's shape is "..itemVis[1][b][1][/b]) outputConsole("The taco's size is "..itemVis[1][b][2][/b]) --and so on and so on... Whereas now in 1.0.3 the syntax has to follow this: local itemVis = executeSQLSelect("objectVisuals","shape,size,texture,fixins","id='taco'") outputConsole("The taco's shape is "..itemVis[1][b].shape[/b]) outputConsole("The taco's size is "..itemVis[1][b].size[/b]) --and so on and so on... Was I just using improper syntax when I did it the old way? Just curious if anyone has any experience with this... Thanks.

I've recently returned from a long coding absence (haven't been active since dp2). I've been trying to get some of my old scripts updated for 1.0.3 and have been having trouble with some basic SQL stuff. It seems that there were some changes between the dp2 version and 1.0.3. The executeSQLDropTable function now works correctly. The executeSQLQuery also seems to be working correctly now, and the 512 character limit has been increased. Both are wonderful! However, the trouble I'm running into now is that in dp2, I could do this: local itemVis = executeSQLSelect("objectVisuals","shape,size,texture,fixins","id='taco'")outputConsole("The taco's shape is "..itemVis[1][b][1][/b])outputConsole("The taco's size is "..itemVis[1][b][2][/b])--and so on and so on... Whereas now in 1.0.3 the syntax has to follow this: local itemVis = executeSQLSelect("objectVisuals","shape,size,texture,fixins","id='taco'")outputConsole("The taco's shape is "..itemVis[1][b].shape[/b])outputConsole("The taco's size is "..itemVis[1][b].size[/b])--and so on and so on... Was I just using improper syntax when I did it the old way? Just curious if anyone has any experience with this... Thanks.

Christmas comes early this year - thanks guys! I hope Santa brings you all something good! Your work is greatly appreciated.

Yeah, I've noticed the same thing previously. The reason basically is that a pickup is just an object loaded, sized, and collisions turned off and a colsphere added on it. Any object that has collisions disabled won't register any kind of click. My solution was to do my own custom "pickups" and whenever the cursor is enabled, collisions are enabled... it kind of sucks though because then the player could theoretically crash their car into the object, etc. (Oh, and the collisions will be the size of the actual object, not the resized pickup's size.) On a funny note, if one of these pickups is in the middle of the road, and you have your cursor enabled, then when someone else drives by it looks like they crash their car and they go flying, but then suddenly they are back to driving normally down the road (the other players all just see the car driving by normally though.)

Clever idea!

Ugh, I can't stand when people don't parse their conditions inside ( )'s... especially when it's a massively long list of conditions like you have! Please, for the love of Bob: if(conditions) then Then again, I have OCD.

Hey all - I just installed GTASA and MTA on an older computer I have. It's a: 800MHz PIII nVidia GEForce 2 MX400 graphics card w/32mb of RAM (Yes, the advanced graphics settings even work fine - YAY nVidia) 256mb of RAM It's definately below the "required" system specs for GTASA but guess what - it runs really well (albeit in "Low" graphics mode!) MTA dp2.3 starts up fine and connects to my server wonderfully. I even killed some players, flew around in a chopper, etc. with no laggy graphics or any problems ) So, now I'm curious - what's some other crappy systems that people have successfully gotten MTA to run on?

It's really easy to scale objects already - the only problem is that the collision-data for the object stays the same size... so, you could put a massively huge wheelchair on top of a building, but if someone flew into it with a helicopter they wouldn't hit anythign until they reached the very tiny center of the object.... Or, you could shrink a massively tall building down to a size that would fit into your pocket, but if you tried to walk up to it you'd hit the building walls long before you got close enough. (unless you turned its collisions off completely, which is also possible.) Anyhow, it can all be done, but has to be done clientside... easiest would be to do the following: in your map file, specify something like scale="2.0" when you load objects from a map file, use setElementData() to set a property "scale" on the object to 2 (the value that was in your map file) use clientside onElementStreamIn event, check if what's being streamed in is an "object" and if getElementData "scale" isn't false, setObjectScale() to that numeric value... optionally, setElementCollisionsEnabled to false for the object if "scale" does not equal 1.0 But, like i said, you run into the collision-data problem mentioned above. Also, it wouldn't be hard to edit any of the scripted map editors to give the option to setObjectScale of whatever item you're playing with...

Just in case you didn't already notice - the script provided above will make that command available on the server - and unless you restrict it in the ACL, it'll be available to all players. So anybody could give themselves money, thus defeating the purpose of having money on most servers. We could all be chairmen of the Federal Reserve.

You're amazing - thank you for taking the time and effort to look into this and even compile a working library for me. This community is very lucky to have such dedicated, helpful, and courteous members. It's much appreciated. When I finish the fruits of my scripting labor, I hope you find the end result enjoyable... (more details to come as I near completion) Thanks again. Wow, after figuring out the proper way to include modules, it worked perfectly! This will do exactly what I needed and I can't possible thank you enough!!!

I'm still confused as to why he WAS able to connect and play before. Seems strange that his serial would "disappear" from mtabeta.com, doesn't it?

If that functionality is already there, I would be quite happy!!! (And something amazing would be added to my server... not going to spoil it yet though.)

The dm mod, sorry... should have been more specific. (I'm a latecomer to MTA and dp2 is the only thing I've ever used.)

To any brave soul with the knowledge and expertise necessary to use the MTA:SA Module Devkit: I'm in need of some help in compiling some pre-existing C code into a module for MTA:SA. I have no idea if it's even feasible. The program performs several sets of mathematic and comparator operations on a set of data, and returns an array of the computed results. Sounds simple enough to write in Lua, but due to the length of it - it would take a very long time to convert. So, if anyone has some experience compiling anything for the module devkit, I'd appreciate any help or advice you could give. (Even if it's: "That's just not possible to do.") If it isn't an option, would anyone have any ideas on how to write a module for MTA:SA that would give serverside script the option to call/open a ".exe" file with arguments? (For instance, exporting a function like: executeFile(".\taco.exe 15A 99E 34B") Since I'm able to already compile that C program into a .exe, something like this would be a fair-enough workaround to accomplish the same thing (and probably easier to do than converting the whole program into a module.) Any advice/help/information is always greatly appreciated. Thanks everyone.

Even bigger question is: Why in the heck would you even use an .xml file for that kind of data? If one day you had a huge playerbase, it would bog your server down like something crazy to start up. An SQL database with that kind of information would be much more efficient, and you don't have to load/read the whole thing from a file when the resource starts. XML should be used only for semi-static data that is only customized/changed via a human being from outside of the game. (Such as gamemode settings and that kind of thing, being opened/changed with an XML editor or notepad or something.) Then again, that's just my stupid opinion and I am legally retarded by several states' definitions.

Read their descriptions before asking retarded questions.

You just pasted an example straight from the wiki entry for the onPlayerChat() event... It should work just fine. What are you trying to do to modify it??? And that example is for server-side code, so make sure you're running it that way.

For one, this is the wrong section to be posting in. Those types of things aren't "add-ons" they are scripts. There are plenty of examples already made for you, if you'd take the time to actually look them up in the proper location. Visit the MTA Community --> Resources page and download some scripts such as "mabako-services" which does exactly what you're talking about. Play around with the scripting and see how it works, and eventually you'll become comfortable enough to write your own.

And remember that setObjectScale() is client-side only! (client-side would be nice someday (would just have to set it as element data or something, really)) but it still works well.

1) setObjectStatic() function... that's going to help me make some awesome gamemodes!!! 2) Even just basic pedestrian functions are going to open up fun scripting opportunities. 3) New camera system 4) All the tiny bugfixes that we've been waiting for 5) A temporary end to the lamers writing "MTA is dead!!!" when they haven't seen an update in the last 5 minutes. All in all, I think the long wait will guarantee that some lame people will complain about "this isn't fixed" and "that still is bugged" which they will point at as proof of some kind of failure. However, those people would complain regardless, so ignore their comments and continue to enjoy this amazingly comprehensive mod and write awesome scripts for the community!!!

That was just an example - the problem of having only around 512 characters per query makes any large operation impossible, regardless of how the database tables are structured.