IPV6: BGP weight local preference
The metrics "weight" and "local preference" will have exactly the same effect on the routing decisions as they would in any other BGP implementation, because those are part of the spec of BGP - well, actually "weight" is originally a cisco thing and other implementations have done the same thing.
Weight is the most important metric of BGP - a higher weight prefix will win over any other version of the same prefix. Being a "proprietary" feature of certain BGP stacks, there is no attribute for weight in actual BGP protocol messages, so there is no way for one BGP speaking router to communicate its weight attribute to any other BGP router. Weight is strictly internal to a given router.
Local_Pref is the second-highest (it's the highest priority metric in BGP stacks that do not implement weight) - if weights are equal (and if you don't explicitly set up route-map/in-filters to set weights by some policy, then they will always be equal), then the highest local_pref value will win. Unlike weight, local-pref is a standard BGP attribute, thus it is transmitted to iBGP neighbors, so that once a local_pref is set, this becomes the policy of that route throughout your AS (unless the iBGP routers modify local_pref due to your policy designs). So if R1 sets a higher-than-default (i.e. >100) local_pref value for a route, this route will be preferred throughout your entire AS. This is how you would set R1 to be the system-wide gateway for Google (for instance) - whereas weight would only cause a particular router to prefer a certain path but this wouldn't globally affect your AS's routing policy.
Okay - how to set this in Mikrotik. Basically, the in-filter that you configure on any particular peer is where you will set the weight and/or local_pref values on routes. The filters chains work very much like the firewall filter/nat/mangle chains do. The main difference is that there are many more actions that can be taken on the matching prefixes than just "accept" "reject" and "discard" - there is an entire BGP-ACTIONS tab (in winbox/webfix) where you specify that a community should be set / appended, or a weight or local_pref be modified, etc. The BGP actions themselves don't dictate what the chain does next as far as the flow through the rules - this is in the "Actions" tab, with the first field being "action" and this is usually "accept" meaning stop checking rules and accept the route (bgp actions and other "actions" tab actions of the same rule are also performed if the rule's matchers and BGP matchers all return "TRUE" for the prefix in question)
You can get quite creative with these just as you can with route-maps in Cisco / Quagga - but unlike those platforms, the prefix-list filters are also implemented in the same routing filters chain, whereas in Cisco, you may specify a prefix-list in, as well as a route-map in for any peer or peer group. In Mikrotik, they're sort of combined into a single entity - the filter-in chain and the filter-out chain. In general, you'll want to use a custom filter chain for each customer (name it <customer name>-in) for input, and probably a standardized output chain such as full-routes-out, local-only-routes-out, default-gw-only-out.
The main thing I've found that works different than Cisco (in general - ROS BGP has a few quirky behaviors that you just have to get used to in my opinion) is that if you receive a default prefix from an eBGP peer, ROS will not pass this along to its iBGP neighbors. You CAN inject a default route prefix across iBGP sessions, but I've found that this can cause routing loops in some lab scenarios I've done, so you probably need to leave default prefixes within your network to be handled by OSPF, and re-originate a default prefix to your customers at the border router they're peering with based on the presence of an OSPF default GW.
The one "quirky" behavior I'd advise you of is that route filters don't automatically re-evaluate the learned/advertised prefixes and update the routing table / advertisements accordingly when you change the order of filter chain rules. If you modify a rule, then the routes are properly re-evaluated and modified according to your changes (i.e. a prefix will be withdrawn if the new configuration blocks a previously-allowed prefix to be advertised), but if you expect to block an announcement by moving a "discard" rule earlier in the chain than an "accept" rule that was improperly accepting a route, then the route won't be withdrawn until you actually modify a rule in the chain - but all you have to do is modify a comment which doesn't actually change the rule, but it still triggers the filter to re-process its routes.
You didn't ask about as-prepend, or set-community, but these are important for influencing your ingress traffic's behavior - so I thought I'd give them a brief mention here. If you want to do an AS-PREPEND for a prefix when advertising it to peer-X, then the out-filter configured on peer-X should have a rule in the chain which has a BGP action to prepend the AS x number of times (however many times your policy requires to get the desired results). In general, I'd say that these sort of behaviors work best on rules with the primary action = passthrough... In general, I recommend using explicit prefix matches or community matches as the final word for "accept" rules - policy modifications should just stamp their matching routes and leave the final go/no-go decision to the primary filtration mechanism (i.e. prefix matches, community matches, or AS-PATH matches).
I hope this information helps you get up to speed with Mikrotik BGP.