[DEV] MTA Framework

[DutchCaffeine]

Hello scripters and server owners,

Today i started with the MTA Framework, some of you may noticed it on the wiki.

About

About the MTA Framework. I started this project to make it easier to create an server.

This framework is based on a MVC pattern, why it is based on an MVC pattern. Uhm i just like that pattern.

Also this project is OOP based.

Become a developer

If you want to be a part of this framework, you may send your information (e.g. scripting knowledge, couple of examples and something about you) to Alexander.

Also bear in mind that our project is stored on google code. So you need an google account in other to contribute to our svn.

Links

Google code page: http://code.google.com/p/mtaframework/

Wiki page: https://wiki.multitheftauto.com/index.ph ... _Framework

If you have questions or anything else. Just reply to this topic. And i will try to answer them.

Alexander de Jong

[robhol]

No offense, but if you're going to make a wiki page, it should be readable and include some proper information. I don't really see the need for half a paragraph on your reason for being interested in MTA.

Also, what exactly is this? A branch? A module? A resource?

While it's certainly an interesting project, I think it works a bit against its purpose - stuff like:

Event.onPickupHit(function(player) 
    local ch = ChatBox:init(player); 
    ch:say("L_PLAYER_HIT_GOLD", getPlayerName(player)); 
end); 

seems awkward both to code, interpret and execute, and in no way simpler than the normal MTA scripting.

As I said, no offense intended, just my thoughts on the matter.

[DutchCaffeine]

It is an resource.

And that peace of code you showed it is work in progress. The event package is not yet finished. I'm busy with it.

[robhol]

That's not my point though: I thought the point was to make scripting LESS complicated, this seems to make it MORE complicated if anything.

[DutchCaffeine]

True. But what i have in mind creates it simpler that that example code on the wiki.

It is an MVC pattern based resource.

It will be allot easier when it is finished.

[50p]

I think, to make things easier and make code look more clean you'd better make classes for "elements" and some base classes for the most events. For instance:

local ak47 = Pickups:Create( 30, 0, 0, 3 ); -- ammo would have some default values 
ak47:OnPickup( function( player ) 
    player:TellMe( "You just picked up AK-47!" ); 
end ); 

This way, you just get rid of ChatBox:init(player) or some funky Event.onPickupHit style. You can look up my GUI lib again to see how I made the event handlers (I'm pretty sure you learnt from it how to OOP in Lua).

I think MTA should have built-in classes. Like this:

local vehicle = Vehicle:Create( 560, 0, 0, 3 ); 
vehicle:GetName();     -- instead of: getVehicleName( vehicle ); 
vehicle:Position();    -- instead of: getElementPosition( vehicle ); 
vehicle:Position( 10, 0, 3 ); -- instead of: setElementPosition( vehicle, 10, 0, 3 ); 
vehicle:Color( 6, 6 ); -- instead of: getVehicleColor( vehicle ); 
------ 
vehicle:OnEnter( function( player ) 
    player:TellMe( "You entered: "..vehicle:GetName() ); 
end ); 
-- instead of: 
addEventHandler( "onVehicleEnter", getResourceRootElement( getThisResource( ) ), function( player ) 
    if source == vehicle then 
        outputChatBox( "You entered: "..getVehicleName( source ), player ); 
    end 
end ); 

I wish I had more time... I'd spend some time on making such classes for every element but I have to catch up with my college work.

[DutchCaffeine]

_50p, That is the idea around the framework.

[50p]

Yeah, but from your example it doesn't seem to simplify scripting or keep it in clean. You said at the end it will be easier but not it's not. Before you start making "framework" you should look ahead and organize things to keep it clean from its start rather than when it's finished because you'll have to change lots of things to make it clean afterwards. Also, when giving example on wiki (documenting) you should show the way it is going to be used so that people know how easy it will be to script. Just an advice.

PS. Don't call me _50p because I'm 50p I use _ on irc because it doesn't allow me to use digits as the first character of my nickname.

[SpZ]

May I ask why you guys use semicolons?

It's not a language different from LUA, right?

[robhol]

May I ask why you guys use semicolons?

It's not a language different from LUA, right?

Semicolons are optional, unless you use it in lines with multiple statements in them. I use them all the time, because I think they look better, and because I'm used to it in several other programming/scripting languages I use.

[eAi]

This looks interesting, but from the one code example on the wiki I'm a bit dubious about some of your design choices...

- You appear to not allow specifying which elements events are attached to - this reduces the efficiency of events significantly

- You're making the chatbox an object which seems unnecessary and a bit unusual, again this prevents you sending messages to multiple players

Anyway, I'm not really clear what the point of this framework is - is it just for outputting localized strings?

If it's an aim to add OO to more of MTA, this is something a number of people on the team are interested in, we'd be happy to discuss this with you on IRC.

Either way, we'd prefer it if you didn't call this the "MTA Framework" - can you give it a more specific name? The name as it stands suggests that the framework is part of MTA.

[arc_]

As has been said in above posts, this project only seems to be making things *more* difficult. It's making things OOP for the sake of being OOP, not for making them easier. Especially the MVC pattern, with its separation of code and data, really needlessly complicates things and seems completely overkill for gamemode scripts. And needing to initialize something as basic as the chatbox just goes too far...

As for localized strings, there's really no framework with parsers needed for that. A simple table will do:

langstrings = { 
    English = { 
        welcome = "Welcome" 
    }, 
    German = { 
        welcome = "Willkommen" 
    } 
} 
_ = langstrings[chosenlang] 
  
outputChatBox(_.welcome, player) 

Also I think you should edit your first post to give a bit more details, as when I first read it I had no idea what the Framework was actually about. Only when I looked at the examples from the wiki did I realise that it was an OOP conversion of the MTA scripting system.

[Phat Looser]

As has been said in above posts, this project only seems to be making things *more* difficult. It's making things OOP for the sake of being OOP, not for making them easier. Especially the MVC pattern, with its separation of code and data, really needlessly complicates things and seems completely overkill for gamemode scripts. And needing to initialize something as basic as the chatbox just goes too far...

As for localized strings, there's really no framework with parsers needed for that. A simple table will do:

langstrings = { 
    English = { 
        welcome = "Welcome" 
    }, 
    German = { 
        welcome = "Willkommen" 
    } 
} 
_ = langstrings[chosenlang] 
  
outputChatBox(_.welcome, player) 

Also I think you should edit your first post to give a bit more details, as when I first read it I had no idea what the Framework was actually about. Only when I looked at the examples from the wiki did I realise that it was an OOP conversion of the MTA scripting system.

Thats true, but that framework idea gave me an idea.

For the case I got the time, I'll create sort of a framework which does nothing but replace some of the function names.

At the moment, the function names use the OOP standarts, which means they are called like "getPlayerName".

I'd prefer "PLAYER_getName" or "OBJECT_getPosition". The reason is, the sourcecode is easier to read that way - at least, it is for me - also, it is sort of OO since the object itself stands at the front, while the function name is behind the object name. Also, I think using functions like "PLAYER_getPlayerName" is sort of redundant, so don't ask me why I won't use those.

Of course, thats all a convention problem. Some prefer the one way, others prefer the above way. I'd say, let him do his stuff, since LUA is a meta language which has no issues allowing several ways of solving a problem.

[DutchCaffeine]

As has been said in above posts, this project only seems to be making things *more* difficult. It's making things OOP for the sake of being OOP, not for making them easier. Especially the MVC pattern, with its separation of code and data, really needlessly complicates things and seems completely overkill for gamemode scripts. And needing to initialize something as basic as the chatbox just goes too far...

As for localized strings, there's really no framework with parsers needed for that. A simple table will do:

langstrings = { 
    English = { 
        welcome = "Welcome" 
    }, 
    German = { 
        welcome = "Willkommen" 
    } 
} 
_ = langstrings[chosenlang] 
  
outputChatBox(_.welcome, player) 

Also I think you should edit your first post to give a bit more details, as when I first read it I had no idea what the Framework was actually about. Only when I looked at the examples from the wiki did I realise that it was an OOP conversion of the MTA scripting system.

I hate that idea about the language table. If you got hundreds of words to translate, really you want to put it into separate files.

This looks interesting, but from the one code example on the wiki I'm a bit dubious about some of your design choices...

- You appear to not allow specifying which elements events are attached to - this reduces the efficiency of events significantly

- You're making the chatbox an object which seems unnecessary and a bit unusual, again this prevents you sending messages to multiple players

Anyway, I'm not really clear what the point of this framework is - is it just for outputting localized strings?

If it's an aim to add OO to more of MTA, this is something a number of people on the team are interested in, we'd be happy to discuss this with you on IRC.

Either way, we'd prefer it if you didn't call this the "MTA Framework" - can you give it a more specific name? The name as it stands suggests that the framework is part of MTA.

You got an couple of points their, the example was something i had in mind to do it that way, but really it can be easier.

And this doesn't go about some function rewrites. No sorry bob, it will add some more features to MTA. For example the ped package, you can let a pad walk with a couple of functions and some coords.

I will update my very first post later, when i got more code.

And about the name, i can't think of an other name. But you got a point there it ain't a part of MTA, but it is for MTA. I keep this name as a dev. name. I will think about it later.

But today i got some more important things to do, like discovering Adobe Stratus.

Alexander de Jong

[arc_]

I hate that idea about the language table. If you got hundreds of words to translate, really you want to put it into separate files.

No problem.

-- lang/english.lua 
langstrings = langstrings or {} 
langstrings.English = { 
    welcome = "Welcome" 
} 
  
-- lang/german.lua 
langstrings = langstrings or {} 
langstrings.German = { 
    welcome = "Willkommen" 
} 
  
-- meta.xml 
<script src="lang/english.lua"/> 
<script src="lang/german.lua"/> 
  

But ok, extra prepackaged functionality like ped walking would indeed be useful.

[DutchCaffeine]

Ahhhhh don't put it in the meta file. That is a mess.

Take a look in this class: http://code.google.com/p/mtaframework/s ... parser.lua

I ain't using the meta file to parse these files.

[arc_]

Ahhhhh don't put it in the meta file. That is a mess.

If you think so...

Take a look in this class: http://code.google.com/p/mtaframework/s ... parser.lua

I looked and saw a 117-line script which has the single purpose of loading another script, but ok . It's your resource so I'll stop making comments like that now. I saw a mistake though.

          local buffer = ""; 
         while not fileIsEOF(fh) do 
                 buffer = fileRead(fh, 500); 
         end 

You will only ever get the last 500 bytes (or less) of the file this way. It may "work like a charm" (@ commit message) with small test files but will fail with real files. Do "buffer = buffer .. fileRead()". Or just use fileGetSize and read the file in one go (I'm assuming your framework is targeted at MTASA 1.0 here).

[DutchCaffeine]

The target version is 1.0. And maybe you right about that language system. I going to think about it. I don't want a meta file that is so big that you need to wait ours to upload to an server.

[eAi]

I'm not sure why the meta file being big affects uploading to a server. I mean a meta file listing a lua file for every language in the world is only going to be about 2KB.

I'd be wary of reinventing the wheel - the meta is meant to define every file in a resource.

It appears to me that some of the things you're doing (e.g. better ped walking ) should be improved inside the MTA code (we'd be happy to help you get started).

Is this a localization framework or an MVC framework?

[DutchCaffeine]

I just going to get rid of the mvc pattern.

And with a better ped walking package i mean:

  
local myPed = Ped:Create(0.0, 0.0, 0.0, 0); -- x, y, z, skin 
  
addCommandHandler("gopedgo", function(cmd) 
    myPed:walkTo(2.5, 0.0, 0.0, 2.0); -- x, y, z, speed 
    -- Or just load an ped file where you declare every position where the ped will walk to. 
    myPed:loadFromFile("myPed.xml"); 
end); 
  

The .xml file

  
<?xml version="1.0" encoding="UTF-8"?> 
<ped> 
    <walkto>x, y, z, speed</walkto> 
</ped> 
  

This is just what i have in mind, the ped package is not yet created.

[eAi]

Positions should be defined in map files, they don't really need to be defined in a custom xml format. You can add a node to xml files to do what you want:

<walknode posX="0" posY="555" posZ="666" speed="5" /> 

This is then editable with the map editor and a standard everyone knows.

If you want paths, you can do this in map files too.

  
<path speed="5"> 
    <node posX="0" posY="555" posZ="666" /> 
    <node posX="0" posY="455" posZ="666" ease="true" /> 
    <node posX="100" posY="355" posZ="666" /> 
</path> 
  

Adding object-oriented functions is a useful thing to do, but I'd be wary of reinventing the wheel with other things - it'll just confuse anyone who uses your scripts.