First pass. Go easy on me. #224
Conversation
MikeJeffers
left a comment
MikeJeffers
left a comment
There was a problem hiding this comment.
Just a first pass for now, statically reading, I'll pull the code soon (tm)
For now just want to hear your thoughts on some of your decisions and if parts could get a little tighter
The big thing that sticks out is that new method on the entityframework and the way its used typechecking a raw object return.
Perpetuum.DataDumper/Factory/DataDumper.ModuleRemoteArmorRepair.cs
Outdated
Show resolved
Hide resolved
MikeJeffers
left a comment
MikeJeffers
left a comment
There was a problem hiding this comment.
Finally pulled the code, some small fixes are needed.
Changed localization parser to use GenXy deserializer Added driller module Removed changes to entity factory Fixed SlotFlags comment Removed some unnecessary comments
… Still need to update property names.
Added option to open exported file Added more module categories
MikeJeffers
left a comment
MikeJeffers
left a comment
There was a problem hiding this comment.
Just a note on all the hardcoded coefficients on the data for display are stored in the DB.
And it looks like the client might actually apply the transforms as the only server side usage appears here: https://github.com/OpenPerpetuum/PerpetuumServer/blob/Development/src/Perpetuum.RequestHandlers/GetAggregateFields.cs#L24-L28
Might save time on transforming other data/fields later.
|
|
||
| // Same as input.GetPropertyModifier(AggregateField.locking_range).Value * 10; | ||
| LockingRange = input.MaxTargetingRange * 10; | ||
| LockingTime = input.GetPropertyModifier(AggregateField.locking_time).Value / 1000; |
There was a problem hiding this comment.
The AggregateField should have things like display units or display multiplier, which are transforms on the number for the purposes of rendering in a view for users.
Still lots of work to do, but to add more modules it's basically just: