Hello There, Guest! Login or Register


Property Handler
#1
Properties in Las Venturas
Quote:A new property handler will have to be created, giving us loads of new features to place these damn things. If you're interested in creating this, please open a topic in the development section of the forums and start a discussion about the feature set is needs to have.

It's time I found something meaningful to do and since this is necessary and I certainly have plenty of property experience, I'm going to take on the prop handler ;)

[Image: 1204595289.png]

After some brief discussion on IRC, the back-end is probably going to be xml but storing the property info in the mysql database is also a possibility and we're keeping our options open for now. For testing I am assuming XML but, as can be seen below, much of the handler can be independent of the actual back-end.

Things which a property handler will need to do (based mostly on the 2.x handler)

Functions which depend on the back-end.
  • Backend Initialization: need to create the property list initially and if it gets reset for some reason
  • In-game Initialization: loading the properties from the back-end into a table for quick access.
  • Updating/Saving: need to save the new list when property attributes change

Functions which can be independent of the back-end by operating on the internal table storage.
  • Creation: need to allow in-game creation of new props.
  • Modification: need to allow names/costs/etc. to be changed and properties to be moved.
  • Deletion: obviously, sometimes properties have to go and it should be easy to do so.
  • Pickups: need to create the pickups for all the properties and display the descriptive text when someone visits one
  • Default earnings: properties should have a set of standard earnings ratios (which can be overridden). In lvp 2.x this was purely based on price; it may be good to take the wealth of the neighborhood into consideration for lvp 3
  • Property info: should be able to retrieve a list of all the properties and their attributes
  • Player owns: should be able to quickly find out who owns what, and get a list of all the props owned by a certain player; should also be able to simply get the number of props a player owns
  • Special attributes: certain properties will be able to do certain special things. we need to have a way to flag the properties and also quickly find out who owns a prop with a certain attribute.
  • Max properties: how many properties can a given player own at once?
  • Pay the money: how much does a player earn on each update? calculate and give it to them
  • Crash protection: when players disconnect, they should still own the props for a brief time so they can be restored on reconnect. If they don't reconnect, the props should be sold off for them.
  • ?? Distance calculation: LVP 2.x has a function to get the distance from a player to a given prop. Still needed?

Anything missing?
Reply
#2
Pretty nice, I like that. As for GUI subjects, I'd like to keep that as limited as possible, probably only for administrators. Would be quite fancy if you would be able to choose icons as well as various options (properties only available for regular members, donators, based on your in-game time or other statistics) which can be modified using dropdown/combo boxes.

I'm not sure yet whether XML or MySQL would be the ideal way, I recon we'll have to create a pro's and con's conparison for the two. Personally, right now, I'd say we go with XML due to the support MTA offers for it, still doubting however.

Pro's (MySQL)
- Better availability for other systems
- Easier searching using queries

Con's
- Increased load time and handing times
- Not always available - less availability
- Harder to backup.
Reply
#3
(03-04-2008, 10:24 AM)Peter link Wrote: Pretty nice, I like that. As for GUI subjects, I'd like to keep that as limited as possible, probably only for administrators.
Yeah, I was thinking the GUI would only be an option for admins when creating/modifying props. Since the main interaction players have is a simple "buy" or "sell" command, a GUI would be needless overkill.

Quote: Would be quite fancy if you would be able to choose icons as well as various options (properties only available for regular members, donators, based on your in-game time or other statistics) which can be modified using dropdown/combo boxes.
Icon choice is an interesting idea and is similar to an odd thought I had last night. SA already has both green and blue house icons. One potential use for these is to have props marked with the green icon if they are buyable (unowned or owned more than 10 mins) and the blue icon if they are not (owned less than 10 mins or perhaps disabled). Haven't really considered how monitoring the state and switching icons will impact server performance though; it was just something that popped into my head. For "custom" icons that don't change, that is certainly something worth considering and shouldn't be at all hard to implement.

As for limited-access props, do we want to support a "level" system (e.g. donators are higher level than regulars so they can buy anything marked for them and also anything marked for regulars) or a flag system (e.g. prop X can be bought only by "regulars", prop Y only by "donators", prop Z by both)? The latter is obviously more flexible but also a bit more complicated.
Reply
#4
I guess just add rights instead of levels, like CAN_BUYPROPS_DONATE kinda things?
Reply
#5
(03-04-2008, 07:51 PM)pdescobar link Wrote: Yeah, I was thinking the GUI would only be an option for admins when creating/modifying props. Since the main interaction players have is a simple "buy" or "sell" command, a GUI would be needless overkill.
Icon choice is an interesting idea and is similar to an odd thought I had last night. SA already has both green and blue house icons. One potential use for these is to have props marked with the green icon if they are buyable (unowned or owned more than 10 mins) and the blue icon if they are not (owned less than 10 mins or perhaps disabled). Haven't really considered how monitoring the state and switching icons will impact server performance though; it was just something that popped into my head. For "custom" icons that don't change, that is certainly something worth considering and shouldn't be at all hard to implement.

As for limited-access props, do we want to support a "level" system (e.g. donators are higher level than regulars so they can buy anything marked for them and also anything marked for regulars) or a flag system (e.g. prop X can be bought only by "regulars", prop Y only by "donators", prop Z by both)? The latter is obviously more flexible but also a bit more complicated.

Your icon idea is pretty nice, however, I don't think it would work. People usually don't pay alot of attention to the icon and walk in regardless, so a message might be more desirable. The level system itself, well, I recon the best way to implement that would be to check the player's information array which will be stored in the getElementData arrays. Documentation for that will follow soonish on the wiki, however, things like whether a player is a regular and their online time will certianly be stored there.

Using a flags system don't seems like something that's really required at this point, perhaps for later updates. Using rights for this.. well, I don't know, perhaps some kind of special properties for donators only using a IS_DONATOR-key or something.
Reply