All this info is the currently planned, or can be expanded??? also how do you plan serialiaze extra house data information like for terrain type and category?View attachment 1631
As part of permissions, lots now manage some extra state, such as their category and the terrain type. Here's the current list of extra state the VM is expected to see:
All this info is the currently planned, or can be expanded??? also how do you plan serialiaze extra house data information like for terrain type and category?
FreeSO will not be using the XML format in the final build I think.XML is actually pretty good (known this by my basic knowledge from Civilization 5 and 4) at keeping certain data like that. Given all houses are saved within that seems somewhat logical to assume it may be used to store that data for the time being.
Are you going to keep the "buggy" grass on diagonal walls? Because that doesn't happen in The Sims 1.I don't know what that means. If you mean that grass cuts off on diagonals, try it in The Sims 1.
I'd rather not keep it, but I don't particularly care right now. People seem to make unusually big deals out of non-gameplay features... I'd much prefer to get things which define the gameplay complete first.
Here's a shot of the same effect in The Sims 1. It does it on the right side of any vertical walls. It used to be a bigger problem but I think it's partially fixed in Complete Collection.
View attachment 1634
That was due to the crazy way they did lighting back on DX7, and it didn't translate forward to DX9 32-bit colour that well. I'm still not sure what we will be doing for direct lighting - I'd like to use a deferred model but it will choke with objects overlaying each other.
Will likely be forward lighting for objects, deffered for architecture (no transparency, too many tiles for forward light). Not sure how well we can optimise the forward part, but ts2 does an alright job. Lighting will use object z-buffers to have more directional lighting, though the z-buffers will have to be pre-processed to make them smoother (but keep harsh edges) and convert them into normal maps. This will be disablable for people whose computers cannot handle it.
...Of course, we could always bake a 3d cube lightmap with 8x8 resolution on tiles, which would be sufficient. It would also be incredibly intensive to generate, but it's what The Sims 3 does.
The XML format will be extended for sandbox purposes, though it will not be used in the final server. For normal lots, we will be using the full binary save state format that we currently use to connect users to lots and resync their state, as I have said before.
Lot metadata will be stored in the Database, and will be transformed into and out of the VM format on every save. Saves will occur when users enter/leave lots and periodically, and will update sims in the lots' budget, roommate status, relationships, etc. These saves will be transactional, so that if the server crashes after you buy a few objects, everything both relating to the lot state AND the sim state is reverted. The database operations will be transactional by using the reliable SQL feature for that, but the house save states will need to be hacked into it. I'm thinking they might have two copies, with the switch between copies as part of the SQL transaction.
public enum TTABFlags
{
AllowVisitors = 1,
Joinable = 1 << 1,
RunImmediately = 1 << 2,
AllowConsecutive = 1 << 3,
Debug = 1 << 7,
AutoFirstSelect = 1 << 8,
Leapfrog = 1 << 9,
MustRun = 1 << 10,
AllowDogs = 1 << 11,
AllowCats = 1 << 12
}
public enum TSOFlags
{
AllowNonRoomie = 1,
AllowObjectOwner = 1 << 1,
AllowRoommates = 1 << 2,
AllowFriends = 1 << 3,
AllowVisitors = 1 << 4,
AllowGhost = 1 << 5,
UnderParentalControl = 1 << 6,
AllowCSRs = 1 << 7
}
public enum InteractionMaskFlags
{
AvailableWhenCarrying = 1,
IsRepair = 1<<1,
RunCheckAlways = 1 << 2,
AvailableWhenDead = 1 << 3,
}
Just worked out all important TTAB flags. Only one I'm not sure about is "Allow Non-Roomies"... It's not a real flag in edith and just seems to combine existing ones.