Code Fix for inactive slacker sims
twallan:
Greetings:
I've been encountering a problem regarding my inactive sims, where they simply don't go to school or work when not actively selected. With AwesomeMod's "AllowInactivePerfGain" enabled, this tends to cause all my sims to eventually lose their jobs.
(Edit: Removed obsolete code, in favor of later posts)
Good day. :)
J. M. Pescado:
Quote from: twallan on 2009 July 18, 03:11:40
I provide this here for use by the El Presidente, if he so chooses. It is not a perfect solution, but it does produce improved results over nothing at all. I'm certain his most Malevolent will think up a better solution.
Uh...that's not a fix. In fact, you're not even in the right code. That function you're looking at? Isn't what controls whether inactive sims go to work when not selected. That's the fallback check in Supreme Commander. Furthermore, your code is based on an OLD version.
twallan:
Quote
Uh...that's not a fix. In fact, you're not even in the right code. That function you're looking at? Isn't what controls whether inactive sims go to work when not selected. That's the fallback check in Supreme Commander. Furthermore, your code is based on an OLD version.
I am aware that it is not a true fix, simply a workaround to the core problem. Until you have an official release of AwesomeMod that corrects the issue, it works for me.
The hooked code block is Sims3.Gameplay.Autonomy.Autonomy.RunAutonomy(), in which I found no AwesomeMod changes. It did make use of a work handler that was available within AwesomeMod, because that was the effect I wanted (namely to push a "Go To Work" interaction on my sims).
If you could direct me to the actual location of the errant "Go To Work" process, I would be most grateful. I would love to debug that process and find out why that system is not pushing my inactive sims to work or school. :)
The code is based on the official release of AwesomeMod, at least the one available via Mirror #1. Since that is the only version I have available, I could not base the changes on anything newer.
Good Day. :)
J. M. Pescado:
The actual go to work handler is buried someplace complex that I haven't found yet, something in the EAxis code involving alarms and whatnot. There are also lots of other things which could disrupt it, and other conflicting things.
twallan:
Quote
The actual go to work handler is buried someplace complex that I haven't found yet, something in the EAxis code involving alarms and whatnot. There are also lots of other things which could disrupt it, and other conflicting things.
Yes, still being a neophyte to this particular code-base, I was perhaps too overly impressed with myself when I got my sims actually back to work.
I shall await your future Awesomeness in this regards, and just continue remerging my personal changes with your new versions, at least until you state a fix has been located.
Good Day. :)
----
Update:
Code:
protected virtual void RegularWorkDayTwoHourBeforeStartAlarmHandler()
{
DateAndTime queryTime = SimClock.CurrentTime();
queryTime.Ticks += SimClock.ConvertToTicks(3.1f, TimeUnit.Hours);
if (this.ShouldBeAtWork(queryTime))
{
Sim createdSim = this.OwnerDescription.CreatedSim;
if ((createdSim != null) && (this.mCurLevel != null))
{
if ((!createdSim.IsSelectable || !this.mbCarpoolEnabled) || !this.mCurLevel.HasCarpool)
{
queryTime = SimClock.CurrentTime();
float num = ((this.mCurLevel.StartTime - queryTime.Hour) + 24f) % 24f;
float time = num - this.AverageTimeToReachWork;
if (time < 0f)
{
time = 0f;
}
this.mRegularWorkDayGoToWorkHandle = AlarmManager.Global.AddAlarm(time, TimeUnit.Hours, new AlarmTimerCallback(this.RegularWorkDayGoToWorkHandle), "Career: time to push go to work", AlarmType.AlwaysPersisted, this.OwnerDescription);
}
else
{
StyledNotification.Format format = new StyledNotification.Format(Localization.LocalizeString("Gameplay/Objects/Vehicles/CarpoolManager:CarpoolComing", new object[] { createdSim }), ObjectGuid.InvalidObjectGuid, createdSim.ObjectId, StyledNotification.NotificationStyle.kTip);
StyledNotification.Show(format, this.CareerIconColored);
}
}
}
}
After further investigation, I found that the RegularWorkDayTwoHourBeforeStartAlarmHandler alarm was being fired 2.25 hours before work.
However the ShouldBeAtWork() check at the beginning of the routine originally only allowed for a 2.1 hour tolerance.
Changing the tolerance to 3.1 hours resolved my issue, without the need of any other code changes.
Yes, this is yet another workaround for an error further down in the system, but I did not investigate further into why the alarm was fired early.
Good Day. :)
Navigation
[0] Message Index
[#] Next page