+- Discovery Gaming Community (https://discoverygc.com/forums)
+-- Forum: Discovery General (https://discoverygc.com/forums/forumdisplay.php?fid=3)
+--- Forum: News and Announcements (https://discoverygc.com/forums/forumdisplay.php?fid=13)
+--- Thread: POB changes (/showthread.php?tid=157229)
RE: POB changes - Skorak - 01-20-2018
Yeah sorry to disappoint but for now it's back to usual supplies.
@Alex. is looking into it. We have to rework the whole plugin if we don't want to ruin pobs with this.
Edit: This is what 'test' runs are for I guess.
RE: POB changes - Kazinsal - 04-06-2018
Submitted a pull request to the public FLHook repository to fix what I'm fairly certain is the issue you ran into.
Kind of hard to be sure but considering the base plugin uses (or, used, before this PR) one tickrate for everything, increasing the seconds per tick to reduce wear and tear also increased the seconds per tick on factories etc., right?
RE: POB changes - Alley - 04-06-2018
(04-06-2018, 08:46 AM)Kazinsal Wrote: Submitted a pull request to the public FLHook repository to fix what I'm fairly certain is the issue you ran into.
Kind of hard to be sure but considering the base plugin uses (or, used, before this PR) one tickrate for everything, increasing the seconds per tick to reduce wear and tear also increased the seconds per tick on factories etc., right?
Correct
RE: POB changes - Kazinsal - 04-06-2018
(04-06-2018, 10:15 AM)Alley Wrote:(04-06-2018, 08:46 AM)Kazinsal Wrote: Submitted a pull request to the public FLHook repository to fix what I'm fairly certain is the issue you ran into.
Kind of hard to be sure but considering the base plugin uses (or, used, before this PR) one tickrate for everything, increasing the seconds per tick to reduce wear and tear also increased the seconds per tick on factories etc., right?
Correct
Okay, cool. I separated out the wear and tear to run on a separately specified tickrate from the factories etc. One thing I think I forgot to note is that the wear and tear tickrate must be an integer multiple of the global tickrate. I didn't want to make any changes involving refactoring CoreModule::Timer and I was also helping Laz fix some plugin loading issues (turns out LoadLibrary was failing with ERROR_PROC_NOT_FOUND; it was some unresolved imports from HookExt that were promptly resolved by doing an actual clean rebuild).
RE: POB changes - Skorak - 04-06-2018
Another problem was that wear and tear was tied to repair. So while it made supplying easier, it also made sieging this much easier
RE: POB changes - Kazinsal - 04-06-2018
Yeah, I decoupled that as well.
e: This plugin may be a pile of hacks, but a lot of them are mine. It's like visiting an old friend.
e2: For clarity, the changes are to just run the wear and tear on its own timer. The only connection to the main seconds per ticket counter is that the wear and tear one needs to be a multiple of the main one, and that's only because I didn't want to rewrite half the timer callback in the middle of the night
RE: POB changes - Skorak - 04-06-2018
I assume what you did is that it'll just apply wear and tear ever Xth time the tick runs anyways?
RE: POB changes - Kazinsal - 04-06-2018
CoreModule::Timer runs every second. The code in it checks to see if the current time in seconds is evenly divisible by set_tick_time (configured with tick_time=# in the base.cfg), and if it isn't, it skips the whole wear and tear/FOW/repair sequence. If it is, the wear and tear happens first, then the repair, then the FOW. I have added another tick timer divisor, set_damage_tick_time (configured with damage_tick_time=# in the base.cfg). That will, after checking to see if the time modulo set_tick_time equals zero, check if the time modulo set_damage_tick time equals zero but only for the wear and tear action. Repair and FOW cycles are unaffected.
The rest of the modules with ::Timer functions are unchanged. They all run on the standard tickrate in set_tick_time.
e: The plugin needs a rework at some point, no doubt. But this was a quick and effective fix to enable exactly what you wanted with a degree of flexibility and took ten minutes. The only reasons the damage tickrate is dependent on the main tickrate are that there's some optimizations involved to skip unnecessary checks for some godawful reason (premature optimization is the devil's workshop) that would be hard to work around while making the damage tickrate completely separate from the main tickrate and that I didn't want to refactor CoreModule::Timer at 2:30am when I had to be up in six hours.
e2: For clarity, damage_tick_time is configured in seconds as well. It just needs to be a whole multiple of tick_time.
RE: POB changes - evanz - 04-06-2018
ok.....so....... what does this all mean for us POB owners?
RE: POB changes - Kazinsal - 04-06-2018
It means that, if the admins choose to implement this, they can reduce the number of RAs needed per day without affecting the decay rate of an unsupplied base.
In the interest of full public disclosure I hate base supply runs but that's not why I implemented this fix in the plugin. I implemented the fix because a) I knew it wouldn't take a complete rewrite, b) I was bored and missed working with FLHook, and c) this is clearly something the admins wanted to implement but were unable to do so because of technical restrictions.