eAi

And sorry to be repetitive, but you'll find it easier long-term if you specify markers (and any other elements) in a map file. You can then use the map editor and everything is generally much better!

Not sure why you'd rather I sent you that via PM, it not exactly secret information. I agree chapter 6 makes little difference either way, I was just saying that what you've said is wrong, even if it is unimportant and could be omitted entirely. I do think the element tree is important for people to understand, obviously it's your call! Maybe there could be an 'advanced' guide in the future covering things like the element tree, proper game mode creation etc... Definitely a good guide, I've added it to the main page of the wiki. Edit: Stickied.

Looks very good, a few points: Page 3 - For resources, I'd discuss how they run - how they're like programs that run independently and can communicate with events. - 'essentialle' should be 'essentially'. I'd argue it's not required too - map files are XML files. - I'd mention that using map files is more efficient (less data is sent to clients than with script functions). - I'd definitely highlight the importance of map files for use with the map editor, and allowing other resources (i.e. maps) to extend a resource without writing code. It's something a lot of people don't seem to get. Page 4: For server/client functions I'd also emphasise that it's best to write server-side code where possible - less risk of people hacking the code and easier to avoid getting out of sync. Page 6: You say coronas are technically markers - they're not really. MTA just munges checkpoints, markers and coronas into one system. In GTA they're three separate systems. Doesn't really matter though... Page 8: You somewhat gloss over the element tree, maybe this should be expanded in more depth with some pretty pictures and some examples of how an event (on say, a vehicle) would get triggered and which elements would see it. Event arguments - maybe make it clear that the arguments depends on the event type. Make it clear the names don't matter, just the order. Custom events should probably mention about using events as a way of making more specific events. A flag in CTF is the example I use on the wiki, where onMarkerHit becomes onFlagPickedUp if the marker was a flag marker, and the player was on the right team (etc). Page 11: Mention accounts and perhaps settings as a way of storing persistent data. Also mention that resources can save map files. I think it'd be useful for someone, whether part of this guide or not, not write a guide to how to create a new gamemode, properly handling map files etc (using getElementsByType etc), writing EDF and making it all work with the editor.

If you use map files, people can write maps for your gamemodes using the editor, you can have elements specified in multiple resources. Making scripters modify your resource asks for errors, it also means that it has to be downloaded repeatedly if the same resource is used on more than one server. Use getElementsByType("mySpecialMarker"), iterate over the list returned and then create markers based on them, or something similar instead.

Well, AI should be interesting to write, so why not do it? It can be optional for users.

You should avoid specifying elements in scripts - use map files instead.

Have you turned debugscript on? Type 'debugscript 3' in the console while in-game. You're using single quotes for your addCommandHandler rather than double quotes, that may be your issue... You shouldn't really worry about Lua being different - the only real difference you need worry about is the syntax being a bit more 'english' - { and } replaced with do / end etc. Play with it for a few days and you'll find it very easy! Of course, there are some more advnaced parts of Lua, but you don't really need to worry about them until you're comfortable with the basics.

http://development.mtasa.com/index.php? ... ver_Manual

You should never loop like that in scripts - it won't work. Scripts are run in the same thread as the rest of the game logic, so nothing will happen (your event packet won't get sent and you won't get any element data returned). MTA will prevent you doing this too, by noticing that your script has been running for too long and terminating it.

Race isn't support on Vista. Use MTA:Deathmatch DP2.3 instead.

I'd suggest storing teleport points in map files - that's the point of map files - storing positions.

Someone could probably add built-in support for the Wiimote, fairly easily if they wanted to...

Your patch has been applied by Arc - sorry it took so long! We haven't tested it, so please check it out from SVN and check it all works as it should.

We already do increase many of these limits in MTA.

Can you drag and drop images/sounds/models etc into the code? Maybe doing so pops up a dialog giving you some options (i.e. how you want to use it and then inserts a relevant snippit), or more simply just inserts the path?

How about "Write stupid question about on MTA forum in broken English"? That would speed things up for a lot of people.

Tooltips look good, but I think it's definitely worth also having a way to jump to the wiki page for that function.

Is it really 'Zombie_spawn' or 'zombie_spawn' - elements names are generally lowercase... Is there an EDF for placing spawns?

No, it doesn't interfere with normal tabbing - you're not likely to want to place a tab in the middle of a function call...

I like the way eclipse does it - it inserts the arguments but in such a way you can set them by tabbing between them - works very neatly. Probably a pain to implement.

You could, yes. It's probably only about 5 lines of code. http://development.mtasa.com/index.php? ... rsed_files

We could make uncached scripts - someone could probably implement that into the client with about half an hours work if they wanted to...

The main advantage of a compiler is that it makes your resource a bit faster to load and smaller to download. It doesn't really provide any security and you shouldn't expect it to. Put 'sensitive' code server-side.

Being able to drag the control points, but being limited to the axis they're on would be fine I think. I agree that completely free movement of control points could get confusing. Having both keys and mouse controls would be nice (and easier for people to pick up and use)....

Looks really good - well done - I'll have a play with it soon How about making it use fewer objects when the track is flat? It seems to use a lot of overlapping objects even if it doesn't need to. What about creating other things that follow the same curve - e.g. walls along the sides of the track? Can you drag and drop the control point's 'power' handles or do you have to use the keyboard keys? It looks like some of the controls/ideas you've got here could be applied to other areas of the editor too.