ページ "Homes and Properties"
が削除されます。ご確認ください。
Right now the different attributes of the current home are tracked in several variables.
curr_home = 4 // The ID of the home
$home_name = 'Old town apartment' // The name that gets displayed on some pages
$home_town = 'oldtown' // the town where the home can be found , curently only by the busking events
$home_location = 'liames' // the hub connecting to the home
$home_entrance = 'korr2x' // the enatrance location of the home
The variables are not really consistent in name and type - curr_home
really should be `home_curr'.
And yes, I'm aware that that's on me, I was tinkering with this ages ago to fix the "date doesn't show up in certain locations" issue.
To set the current home right now we need to assign a numeric value to the curr_home
variable: curr_home = 1
My main issue with this is that people have to remember which number means which home.
Right now there are 16 homes and we can assume that the number will grow.
curr_home = 1: 'City residential apartment'
curr_home = 2: 'Parent''s home in Pavlovsk'
curr_home = 3: 'My cottage in the cooperative farm'
curr_home = 4: 'Old town apartment'
curr_home = 5: 'Matryona mansion'
curr_home = 6: 'My hotel room in Pavlovsk'
curr_home = 7: 'Nicholas'' Apartment'
curr_home = 8: 'Niko''s apartment'
curr_home = 9: 'Uncle Sergey''s apartment'
curr_home = 10: 'Lyceum school'
curr_home = 11: 'University halls'
curr_home = 12: 'Hunter''s lodge in Gadukino'
curr_home = 13: 'Shared apartment in Pavlovsk'
curr_home = 14: 'Grandparent''s house in Gadukino'
curr_home = 15: 'City residential house'
curr_home = 16: 'Meynold Household'
The full flow of setting the current home right now is:
gs 'set_home', 1
....
curr_home = ARGS[0]
if curr_home = 1:
$home_name = 'City residential apartment'
$home_town = 'city'
$home_location = 'city_residential'
$home_entrance = 'korr'
elseif curr_home = 2: ...
end
When checking for different attributes the inconsistent names and the fact that the home has a numeric ID comes up.
Checking whether the current location is the current home of Sveta we need: if curr_home = 1: ....
, while to check where the date with her boyfriend will be we need to check if $home_location = 'city_residential
.
The only way to know if Sveta is at home is to do a check like
if curr_home = 1:
'Sveta is home'
else
`'Sveta is not at home
However, this only works for the current home, therefore if Sveta own multiple properties, the way to tell if Sveta is at home is by running
if home_owned[1] > 0 and home_owned[1] < 3:
'Sveta is at home'
else
'Sveta is not at home'
end
The reason for the and
because the there are several numeric values possible for both the true
and the false
case.
0 - Home not owned and not rented
1 - Home rented
2 - Home owned
3 - Owned by rented out to tenants
Another issue for this is that there are places where whether Sveta is at home or not can matter, but the location doesn't know the curr_home home value it would have to check for, thinking about the laptop - komp.qsrc
- and some music related locations - music_actions
and music_online
- for example
With the current structure, the only property we can query easily is the current home.
If someone wants to check the attributes of a non-current home it’s not straightforward.
For example, if Sveta lives in the city residential apartment - curr_home = 1
, and owns the village cottage too - curr_home = 3
-, there is no easy way to get the name or some other attribute of the village cottage unless we set the current home to the village cottage first, check the attribute we are interested in, and then set the current home back to the original one. It's a bit risky.
The plan is to set the home Sveta is being at when she is entering - this would be the location currently defined in $home['entrance'], so for the parents' home it would be korrPar
, for the Old Town apartment it would be korr2x
.
This would work just as well with using a home_id
and setting the numeric values currently in use, however that still has the same proble - Is the village cottage 3 or 4?
$home_address
will allow us to use a more human way to check if $home_address = 'parents_home':
is easier to remember than 2. At least for me.
Also, when searching for something, looking up 'parents_apartment' is easier than looking up 2.
1: 'city_apartment': 2: 'parents_home': 3: 'village_cottage': 4: 'old_town_apartment': 5: 'matryona_mansion': 6: 'pavlovsk_hotel': 7: 'maid_bedroom': 8: 'nikos_apartment': 9: 'sergeys_apartment': 10: 'lyceum_dorm': 11: 'university_dorm': 12: 'hunters_lodge': 13: 'shared_apartment': 14: 'grandparents_house': 15: 'city_house': 16: 'meynold_household':
0: '' - 'none'
Setting a $home_name variable here would allow us to know what home Sveta is at no matter what other, unconnected location a the goes to, be it using the laptop, doing a phone call, doing something with music, etc.
To check if Sveta is at her current home if $home['current'] = $home_name:
can be used, to check if Sveta is at a home, if $home_name ! '':
can be used.
Also, $home_name
is used for the home based monthly subscriptions - see Internet and Mobile: Homes, properties, locations
There are two things that need to be worked out:
It has to be guaranteed that the $home_name value is always correct, and is an empty string if Sveta is in a location that is not a viable home.
I am not 100% sure what the right solution would be, the easiest one I can think of is to set the $home_name in every location that belongs to that home and run a killvar 'home_name'
every time a location is left (placed in loca.qsrc
? That runs every time there is a move between locations.)
Apart from this, there are a few more options:
Implement a 'leave'
function that has to be called every time a home is left and would do the cleanup. This could either be something that every entrance location has, and then the acts that leave the home should call it that , plus every scene that teleports Sveta from the home somewhere else - e.g. if it's Mum taking Sveta from the kitchen to the gynecologist, then it would be `gs 'korrPar', 'leave'. This is a good solution if we expect that there will be location specific things that need clean up, the downside is that every scene needs to keep track of different departing points.
The other solution would be to have it as in the location holding all the other home and property related functions, then the call would be gs 'home_properties', 'leave_home'
from everywhere. The advantage of this is that the scene doesn't need to know anything, every scene and exit event has the same call, and if any specific cleanup or action is needed, then that logic would be added to this function.
A simpler solution would be that instead of doing a gs .....
every exit from a home would simply add a killvar 'home_name'
line and that's it.
For entering the home through a different location the entrance, I can think of two options beyond the one mentioned above:
'enter'
function similar to the 'leave'
function mentioned above that needs to be called every time an action or a scene makes Sveta enter a home. This too could be both a location specific action or a generic one, the scene should know which home she is moved to, so it can call the correct location, or pass it as a parameter.'$home_name = ....'
to every scene that brings Sveta home but not to the entrance location.An option that would kind of sidestep this is to allow the scenes to take Sveta anywhere, and simply run killvar 'home_name'
only if the scene leaves her in a public public place. Although I can immediately think fo the travel from Gadukino to Pavlovsk where this is not entirely correct and potentially can cause an issue.
So this needs a bit of thinking.
From the current setup where the attributes of the current home are stored in several different variables, I plan to move everything an array called home
This has several advantages:
home
and $home
are the same variables, but killvar 'home'
eliminates both.In addition, I plan to change the current home identifier from a number to a string. The number is not really informative and requires effort from people (I always have to look what 15 or 13 or 6 stands for) to a string that is much easier for humans.
As checking for the current home is relatively rare, I don’t think this change will cause any performance issues.
And if we want to keep the numeric id, we can still keep it in addition to the string one.
Based on that, the new structure would look like this:
$home['current'] = 'old_town_apartment'
$home['id'] = 4 // optional, if we want to keep it. Doesn't need food or water,
// don't have to take it for walkies, so it's not a huge burden.
$home['name'] = 'Old town apartment'
$home['town'] = 'oldtown'
$home['location'] = 'liames'
$home['entrance'] = 'korr2x'
Instead of having everything under the home section, I am moving the different home attributes under properties
.
The reason for this is that I find that it can be handy to simply look up attributes for different locations without setting them as a home, and also, I can see that in the future we may want to add locations that Sveta can own, rent, use, manage, e.g. has some control over, and those could also be added to this list to keep everything in one place.
$property['name'] = 'City residential apartment'
$property['id'] = 1
$property['town'] = 'city'
$property['location'] = 'city_residential'
$property['entrance'] = 'korr'
Also, this block will be the part of a “function” called 'get_property_attr'
which would allow us to get any existing attribute for any property/home, and to allow people simply to check whether a location can be a home or not - I think this could be useful for mods.
On mods: If a mod wants to introduce a new property, like the existing ones, I added a
'mod_property_query_hook'
that is called when$ARGS[0]
is not recognised as a property.
The 'get_property_attr'
will look like this
if $ARGS[0] = 'get_property_attr':
if $ARGS[1] = 'city_apartment':
$property['name'] = 'City residential apartment'
$property['display'] = 'your city residential apartment'
$property['town'] = 'city'
$property['location'] = 'city_residential'
$property['entrance'] = 'korr'
elseif $ARGS[1]= 'parents_home':
....
else
gs 'homes_properties', 'mod_property_query_hook'
if $property = '': $property = 'none'
end
end
This is currently used when an home internet connection is transferred to a new home, to check that the internet subscription belongs to a property that allows the transfer, and is being moved to a property that also allows the transfer.
This filters out mistakes like someone trying to transfer a subscription that is not linked to a home, for example a mobile subscription, as the $property
returned will be ‘none’
and not a valid property, and will prevent the transfer from or to a property that doesn’t allow it.
IMPORTANT!
After calling 'get_property_attr'
the property variable should be killed so it won’t hang in the memory forever. This is a function that is not used too frequently, therefore there is no need keeping the result around for too long. So when you are done with the variable: killvar 'property'
- and use property
not $property
because the former removes both, the latter doesn’t.
Setting the home will simply look up the right property based on the home name and then copy that content into the home
array - have to use home
not $home
to ensure that potential integer values are copied too.
The new code will look like this:
if $ARGS[0] = 'get_property_attr':
if $ARGS[1] = 'city_apartment':
$property['name'] = 'City residential apartment'
$property['town'] = 'city'
$property['location'] = 'city_residential'
$property['entrance'] = 'korr'
elseif $ARGS[1] = 'parents_home':
....
end
end
if $ARGS[0] = 'set_home':
gs 'homes_properties', 'get_propery_attr', $ARGS[1]
COPYARR 'home','property' // using the plain (i.e. without $) variables because that will effect the $ variables too.
$home['current'] = $ARGS[1]
killvar '$property'
killvar 'property'
end
One thing that already kind of relies on this is the Internet and Mobile subscription transfer that uses the ‘get_property_attr’
to check the validity of the two locations participating in the action.
A handful of attributes are added to the properties. Some of them are required by some other feature - for example the new internet subscriptions - or for make things convenient or just some already existing, but until now unlinked attributes - for example the price of the home.
$property['display'] = 'your city residential apartment'
// a string that can be used in the middle of a sentence: "You wake up from your thoughts as you turn the corner,
// reaching the entrance to *your city residential apartment."*
$property['type'] = 'permanent_residence'
// permanent_residence: This is a home that can be used for everything. Certain things don't allow the
// more "transient" homes, like the dating app which requires that Sveta lives in one of a handful homes.
// When this happens there is usually a very long if X or Y or Z or V check that can be replaced with
// if $property['type'] = 'permanent_residence'
//
// temporary_residence: These are not real long term homes, some examples are the Pavlovsk Hotel,
// Uncle Sergey's apartment (the Shulga home), the Hunter's Lodge, the grandparents' house in Gadukino.
//
// A rule of thumb could be that if Sveta can rent it alone or own it, or if it comes with a job or school
// (like the maid/servant bedroom or the university dorm room) then it's a permanent residence,
// otherwise it isn't.
//
// However, the types are not 100%, need some agreement on what types we want, what they mean, etc.
$property['price'] = '800,000'
// The sales price of the property as a string, used to include the price in any text.
// This is not a new variable, it is currently stored in the $home_value[] variable,
// but to me it makes more sense to have the attributes of a property in one place.
$property['rent'] = '15,000'
// The monthly rent Sveta has to pay as a string, used to include the rent in a text.
// This is not a new variable, it is currently stored in the $home_rent[] variable,
// but to me it makes more sense to have the attributes of a property in one place.
property['price'] = 800000
// The sales price of the property Used to take the money from Sveta - and to make sure she
// has enough money. Same as with property['price'], right now it is the home_value[] variable.
property['rent'] = 15000
// The monthly rent of the property as a number. Used to take the money from Sveta -
// and to make sure she has enough.
// At the moment it is the home_rent[] variable.
property['rental']= 1
// If the value is 1, the property can be rented. If the value is 0, the property can't be rented.
property['internet_enabled'] = 1
// This variable tells whether an internet subscription for the property can be bought,
// cancelled or transferred.
// If the value is 1 Sveta can do everything with the connected internet subscription,
// if it's 0 then she can't.
// The deciding factor generally is whether Sveta can rent or buy the property.
// As such for the parents' home in Pavlovsk: property['internet_enabled'] = 0
// For the city residential apartment: property['internet_enabled'] = 1
Because I’m lazy, if a property has ‘’ or 0 as a value for an attribute - for example, if the property can’t be rented - then I don’t add them to the property values, because an unitialised variable will have either 0 or ‘’ as its value.
Example where everything has a value:
if $ARGS[1] = 'city_apartment':
$property['name'] = 'City residential apartment'
$property['display'] = 'your city residential apartment'
$property['town'] = 'city'
$property['location'] = 'city_residential'
$property['entrance'] = 'korr'
$property['type'] = 'permanent_residence'
$property['price'] = '800,000'
$property['rent'] = '15,000'
property['id'] = 1
property['price'] = 800000
property['rental']= 1
property['rent'] = 15000
property['internet_enabled'] = 1
And an example where some attributes don’t have any value other than 0 or ‘’
elseif $ARGS[1]= 'parents_home':
$property['name'] = 'Parent''s home in Pavlovsk'
$property['display'] = 'your parent''s home in Pavlovsk'
$property['town'] = 'pavlovsk'
$property['location'] = 'pav_complex'
$property['entrance'] = 'korrPar'
$property['type'] = 'permanent_residence'
property['id'] = 2
Right now the renting and buying properties uses several different variables and these are spread out over different locations:
home_owned[]
holds the numeric id of the different properties Sveta can buy, rent, live at, etc. and has a value of 0..3
0
- Home not owned and not rented / can't stay here (for example when Mum kicks her out of the parents apartment, we get home_owned[2] = 0
1
- Home rented
2
- Home owned
3
- Owned by rented out to tenants
Except for the Matryona mansion where 1
, 2
and 3
mark the status of the construction:
1
- Bought the land
2
- Foundation build and utilities are connected
3
- The whole building is finished
home_rent[]
holds the numeric id of the different properties Sveta can rent and what the monthly rent is .
home_value[]
holds the numeric id of the different properties Sveta can rent and what the price Sveta has to pay to buy it.
I would replace it with an array called prop_owned[]
where the index would be the property name - same as in the properties
and home
arrays - and some additional attributes.
prop_owned[<property name]: integer
// 0: no access 1: accessible
prop_owned[<property name>-status']: integer
// 1: rented 2: owned 3: rented out
prop_owned[<property name>-habitable']: integer
// 1: yes 0: no
// this can be used to check whether Sveta can live in it. I would prefer this to
// checking where a construction status is because I can seen that we end up with
// more mansion like buildings, and also properties that are not habitable but can
// be rented/own, for example a news stand kiosk, an office, etc.
prop_owned[<property name>-construction']: integer
//1: land works 2: foundation built 3: building done 4: interior finished 5: furnished
// This is more than the mansion has - see above - but adding the last 2 status
// would allow us to "simulate" renovations. A building is not habitable until it is
// furnished, or the interior is finished (and then the description could reflect the
// unfurnished status of the place)
Obviously, we can simply go with the prop_owned[<property name>]
and keep the current 0..3
distinction but I think that would be less useful.
hcount_util
the number of properties where Sveta has to pay utilities
hcount_cable
the number of properties where Sveta has cable
These always equal number of properties Sveta owns, and whether Sveta sets foot in them or not, the utility bill will be equalt to connsumption multiplied by this number - Sveta even pays for the utilities of the tenants.
Example:
If Sveta owns the city apartment and lives there: hcount_util = 1
She consumes 1,500 in electricity, and her utility bill will be 1500 * hcount_util = 1500
.
If Sveta owns the city apartment and the village cottage: hcount_util = 2
She lives in the village cottage, doesn't go to the city apartment and consumes 1,500 in electricity, her utility bill will be 1500 * hcount_util = 3000
If Sveta owns the city apartment and the village cottage: hcount_util = 2
She rents out the city apartment and moves to the village cottage, consuming 1,500 in electricity, her utility bill will be 1500 * hcount_util = 3000
The same happens if she has cable subscription, the will always be multiplied by the number of properties she owns.
With the changes described above, we could track what she consumes in different locations, where she has cable subscription, etc. and not make her pay for what she isn't actually using.
Although, this could be done with the current code too, as elektro
that tracks the electricity consumption tracks it for every property together therefore multiplying it with hcount_util
makes no sense.
If we want to simulate the standing charge, that's a daily charge anyway, independent of consumption and should be separate from the consumption, a fix tariff multiplied for each owned home.
If we want to do that.
ページ "Homes and Properties"
が削除されます。ご確認ください。