Old Wiki:ModuleManager Conversations with Luck

Conversations with Luck on Module Manager design:

PART I

11:15  Aknor|working   ah, so we need to supply a crateID
11:15   Aknor|working   so, we do not use item->Move()
11:15   Almamu  yes
11:15   Aknor|working   it is insufficient
11:15   Aknor|working   we need to make a new function for contracts that handles this stuff
11:15   Aknor|working   hmmmm
11:15   Almamu  the problem is, how can i create a "crate" and what type is it ?
11:15   Almamu  hmmmm
11:16   Almamu  wait a sec, i will search in the db for something related
11:16   Aknor|working   it's an object... it's not a game object
11:17   Aknor|working   something behind the scenes
11:17   Aknor|working   it is not in invTypes
11:17   Aknor|working   its not like a ship or cargo container
11:17   Aknor|working   they do the same thing for trades
11:17   Aknor|working   there is a tradeContainerID i think
11:17   Aknor|working   this is gonna take us some work to make this work right
11:18   Almamu  the stations are like "items" at the entity table, why not handle crates like them ?
11:18   Aknor|working   well.... since i haven't seen the whole progression of packets from the start of creating one, adding items to it, and then finishing it... i'm not sure what to do at this point
11:19   Aknor|working   well, yeah, we can... put "crates" in the entity table
11:19   Almamu  and the items can have locationID = crateID
11:19   Aknor|working   and then they have their own ID, so we have a crateID, then we change locationID for all items in the contract to that crateID
11:19   Almamu  so i can delete one more table from the DB( contract_items )
11:19   Aknor|working   but, there is way more... we need to send that packet instead of that OnItemChange packet that gets sent when you do Move()
11:19   Aknor|working   i would say so... did you add that?
11:19   Almamu  maybe its cause the new client
11:20   Almamu  let me search for OnItemChange
11:20   Almamu  on the capture
11:20       *** Code_Red joined #evemu
11:20       +++ ChanServ has given op to Code_Red
11:20   Aknor|working   i have no idea if its because of the new client... i've never seen packet logs of contracts stuff for apoc, so... idk
11:20   Aknor|working   o/ Code_Red
11:20   Code_Red    \o
11:20   Almamu  hey!
11:20   Almamu  ok, OnItemChange is not in the packet
11:20   Almamu  so it will be cause the client version
11:21   Almamu  or something
11:21   Code_Red    so whats new
11:21   Almamu  trying to work in contracts system
11:21   Almamu  *on
11:21   Code_Red    kewl
11:21   Aknor|working   yeah... this is getting pretty complicated, Almamu
11:22   Almamu  yeah, i know
11:22   Aknor|working   we still need a contract class, contract manager class
11:22   Almamu  and maybe some caching for them too
11:23   Almamu  if the contract list is too big it will take a while for the server to fetch it -.-"
11:23   Aknor|working   and then when you make a contract, it makes a new contract class object, makes a new contractID, a new crateID, then when you start adding things to the contract, the right stuff happens, moves items to that container from your station items, then sends that right packet to the client with the new crateID and contractID
11:23   Aknor|working   yeah
11:23   Aknor|working   um, dont worry about caching...
11:23   Aknor|working   why caching?
11:24   Aknor|working   oh, i see why... right
11:24   Aknor|working   but we dont have that now, so dont worry about it
11:24   Almamu  ok
11:24   Aknor|working   we dont have caching of the market either, but it is also very inefficient packing the sql query, so, that's not of our concern right now
11:25   Aknor|working   this is educational, not like we're trying to make a server that serves 100's or 1000's or more... c'mon
11:25   Aknor|working   we'll make a cache later to learn about cache systems and stuff
11:25   Almamu  thats what i was trying to talk about
11:25   Aknor|working   ok
11:26   Aknor|working   man.... we have some bubble/warping issues... we have contract work going on.... we need to work on module manager....
11:26   Almamu  -.-"
11:27   Almamu  the next time i will try to fix something that is already here
11:27   Almamu  xD
11:27   Aknor|working   hmm... well, i gotta fix the warping/bubble stuff first, then decide whether to work on module manager or help you with contracts
11:27   Aknor|working   hahaha
11:27   Aknor|working   yeah
11:27   Almamu  module manager would be better
11:27   Aknor|working   well, it will take longer than contracts i bet
11:27   Almamu  woking on*
11:27   Aknor|working   contracts might only be a couple weeks
11:28   Aknor|working   and luck and captnoord are kinda inactive right now, even though luck has popped back in
11:28   Aknor|working   i really dont wanna work on the MM without both of them
11:28   Almamu  xD
11:29   Aknor|working   sooooo..... let's do contracts, and then let's take a look at private trades
11:29       *** Luck joined #evemu
11:29       +++ ChanServ has given op to Luck
11:29   Aknor|working   O.O
11:29   Luck    oh hi
11:29   Almamu  hey!
11:29   Aknor|working   Code_Red, stop fooling around
11:29   Luck    lol
11:29   Almamu  xDDDD
11:29   Code_Red    hiya luck
11:29   Aknor|working   right.....
11:29   Luck    hey man
11:29   Luck    quick question aknor
11:30   Luck    you did your attribute patch against 1049 right?
11:30   Aknor|working   ok, "Luck", what chemicals did you mention to me the other night?
11:30   Luck    hf and h2so4
11:30   Code_Red    he thinks your me kev LOLOLOL
11:30   Luck    :p
11:30       Aknor|working hears ChanServ announce "Luck Identity Confirmed"
11:30   Code_Red    noob manuver
11:30   Aknor|working   ok
11:30   Luck    lol
11:30   Luck    anyways
11:30   Luck    you did your patch against 1049 right?
11:30   Aknor|working   dude, there's been soooooo many impersonators of Luck in here....
11:30   Aknor|working   ok, yeah
11:31   Luck    hmm
11:31   Aknor|working   trying to remember what that was... Celestial stuff?
11:31   Luck    the attribute merge
11:31   Code_Red    i haven't impersonated luck ever
11:31   Aknor|working   wait... what patch?
11:31   Luck    http://forum.evemu.org/viewtopic.php?f=8&t=507
11:31   Aknor|working   attribute merge is already committed
11:31   Luck    ah
11:31   Luck    i didn't see that it was committed
11:31   Luck    my fault
11:31   Luck    that would explain a lot
11:32   Luck    :p
11:32   Aknor|working   HAHAHAHAHAHA
11:32   Aknor|working   ok, i see i said r1049, but we're on r1078 now
11:32   Luck    yea
11:32   Luck    that's why i was a little confused
11:32   Aknor|working   and it pretty much works dude!
11:32   Luck    it was also 4 am
11:32   Aknor|working   LMAO
11:32   Luck    so that might have had something to do with it too
11:32       Code_Red continues his minecraft
11:32   Luck    :)
11:32   Luck    okay then
11:32   Aknor|working   i was sleeping in my computer chair at 4am
11:32   Aknor|working   >_>
11:33   Almamu  O.o
11:33   Luck    so i can just checkout and program for the mm then
11:33   Luck    cool
11:33   Luck    makes my life easier
11:33   Aknor|working   yep
11:33   Aknor|working   OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
11:33   Aknor|working   he said MM !!!!
11:33   Luck    yes i did
11:33   Almamu  lol
11:33   Aknor|working   HE SAID MM !!!!!!!!
11:33   Luck    :)
11:33   Luck    no promises
11:33   Almamu  aknor, youre crazy!
11:33   Almamu  xD
11:33   Aknor|working   so, you have a newer version than what's in SVN now?
11:33   Aknor|working   cuz i re-enabled some stuff that captnoord had disabled in his attribute branch
11:34   Aknor|working   just to try stuff out
11:34   Luck    not that will work with the new attribute system
11:34   Aknor|working   this morning, i fitted a microwarpdrive and a pulse laser and a cloaking device to an Ashimmu and undocked
11:34   Luck    i'm probably just gonna start from scratch
11:34   Luck    nice
11:34   Aknor|working   i got a couple exceptions from the client when i fitted the laser
11:34   Aknor|working   the ship did not disappear after undocking
11:34   Luck    did your ship go invisible?
11:34   Luck    really?
11:34   Aknor|working   however, it DID disappear when i re-docked
11:34   Aknor|working   XD
11:34   Luck    ah
11:34   Aknor|working   you'll see the client exceptions
11:34   Almamu  xD
11:34   Aknor|working   one was about turrets
11:35   Luck    yea
11:35   Luck    yep
11:35   Luck    that's the old one
11:35       Code_Red hates creepers
11:35   Aknor|working   see, i can help code up features on the server side, but i really have ZERO clue what kinds of packets and info need to go back to the clients when stuff gets changed on the fitting or module usage
11:35   Aknor|working   oh ok
11:37   Luck    yea
11:37   Luck    there's some update that needs to be sent to the client
11:37   Luck    to tell it to update the render of the ship
11:37   Luck    but it's not being sent
11:37   Luck    so it stops rendering the ship
11:37   Luck    at least that's what I think happenes
11:37   Luck    *happens
11:38   Aknor|working   ok... well, i've been thinking about the client, mm, ship, modules OOD....
11:38   Luck    :)
11:38       Code_Red bobs head in TS
11:38   Aknor|working   it makes sense now that the MM is owned by the client, not the ship
11:38   Aknor|working   but the MM should have a direct reference to whatever ship it is "managing"
11:38       *** Code_Red is now known as Code_Red|TS3
11:38   Luck    cool
11:39   Luck    that was what I was thinking
11:39   Aknor|working   but the ship owns the modules, not the module manager
11:39   Aknor|working   the module manager needs access to them but does not own them
11:39   Luck    yea
11:39   Aknor|working   the existing MM i've seen has its own containers for modules
11:40   Luck    yea
11:40   Aknor|working   actually, i've been thinking we'd want std::map<> not std::vector<> containers, and separate ones for low, medium, high, rig, and subsystems
11:40   Luck    so we need to rewrite ship, and the mm
11:40   Luck    yea
11:40   Luck    probably a good idea
11:40   Luck    separating them makes sense
11:40   Aknor|working   so, we should put those containers into the Ship class then provide functions on the Ship class that fit/unfit modules
11:41   Luck    yea
11:41   Aknor|working   and also Get module references so we can then Activate, Deactivate, Reload/Unload charges
11:41   Aknor|working   see, each module should also be an object
11:41   Luck    i feel like the fit/unfit should go though the mm
11:41   Aknor|working   ShipModule base class
11:41   Aknor|working   then derive ActiveModule and PassiveModule and SubsystemModule
11:42   Luck    yea
11:42   Aknor|working   then derive ArmorRepairerModule from ActiveModule, HullUpgradeModule from PassiveModule
11:42   Luck    yea
11:43   Aknor|working   they inherit proper routines like Activate() or Deactivate() that would only come from ActiveModule, but not from PassiveModule
11:43   Aknor|working   Subsystems are more complicated because they actually modify the slot configuration
11:43   Aknor|working   THAT should be managed INSIDE the ship object
11:43   Aknor|working   this is too funny... i'm making a lot of sense now and all this is just coalescing right now, actually XD
11:43   Luck    yea
11:43   Luck    probably
11:43   Luck    :)
11:44   Aknor|working   :D
11:44   Mobbel  hey luck
11:44   Luck    so which part do you want to write?
11:44   Luck    :p
11:44   Aknor|working   hmm....
11:44   Luck    hey mobbel
11:44   Mobbel  how are you???
11:44   Luck    pretty good man
11:44   Aknor|working   how about i start modifying the Ship class to contain the module containers
11:44   Luck    done with school for the semester
11:44   Luck    taking a break
11:44   Luck    kk
11:45   Luck    i will look at reworking the mm class
11:45   Aknor|working   ok
11:45   Aknor|working   i think we need a separate Modules.h/.cpp file set
11:45   Aknor|working   to pull ShipModule and other stuff OUT of ModuleManager.h/.cpp
11:46   Aknor|working   ok, and i'll pull a lot of stuff out of ShipModule and make that the abstract base class
11:46   Luck    kk
11:46   Aknor|working   and start deriving the different module child classes off that
11:46   Luck    i'm basically trashing the mm as it exists in 1078
11:46   Aknor|working   HAHA, ok
11:46   Luck    since most of it is redundant/in the wrong place
11:47   Mobbel  looks like luck is back for doing great things :D
11:48   Aknor|working   ok, so here's my list:
11:48   Aknor|working   1) expand Ship class to contain module containers, module reference Get(module_slot_flag), FitModule(), UnfitModule(), RigInstall(), RigRemove(), SubSystemInstall(), SubSystemRemove()
11:48   Aknor|working   i'll leave those mostly empty for now
11:49   Aknor|working   2) move ShipModule into Modules.h/.cpp, clean it out, make it abstract, and start deriving child classes for the various specific modules we need
11:49   Luck    yea
11:49   Aknor|working   that will allow us to do polymorphism on ship->GetModule(slot_flag)->Activate()
11:50   Luck    atm i have an empty ShipModule class and an empty ModuleManager class
11:50   Aknor|working   and it will just work
11:50   Aknor|working   :D
11:50   Aknor|working   k
11:50   Luck    yea
11:50   Luck    thank god
11:50   Luck    so lets see
11:50   Luck    the constructor for the module manager
11:50   Luck    should get a reference from the client
11:50   Aknor|working   for the ship, yeah
11:50   Aknor|working   AND the client
11:51   Aknor|working   that's the thing that had me frustrated
11:51   Aknor|working   you reference all the way down to these lower objects and then you need info from one of the higher ones, but there's no reference BACK
11:51   Aknor|working   client->Destiny()->GotoDirection() and then you're inside DestinyManager with NO access to the Client object, LOL
11:51   Luck    lol
11:51   Luck    wonderful
11:52   Aknor|working   but, that might be because not all the info needed by DestinyManager() was provided... idk
11:52   Aknor|working   anyway, got a meeting, talk to you chaps later
11:52   Luck    kk

PART II

[13:47] <+Luck> okay aknor
[13:47] <+Luck> so
[13:47] <+Luck> base classes
[13:47] <+Luck> module, subsystem
[13:48] <+Luck> h/o
[13:48] <+Luck> im gonna draw it up
[13:48] <+Luck> i have to to get it in my head :p
[13:48] <+Aknor> oh hey
[13:48] <+Luck> figured we could talk in here
[13:49] <+Luck> since it will be less busy or w/e
[13:57] <+Nick> r1079 on linux x64 doesn't build Aknor
[13:57] <+Aknor> heh, "less" busy... but, i cant talk much anymore for a while.. .got stuff to do
[13:57] <+Nick> http://pastebin.com/LT5zbkHm
[13:57] <+Aknor> i'll be back tonight i think
[13:57] <+Luck> kk
[13:57] <+Luck> im gonna work on some of the modules then
[13:57] <+Nick> is the tonight op still in place?
[13:57] <+Aknor> i'm planning on it... we'll see
[13:58] <+Aknor> each time is play by ear
[13:58] <+Nick> it'll be 4 am for me
[13:58] <+Nick> i need to know :))
[13:58] <+Aknor> haha, you dont have to
[13:58] <+Aknor> just sleep man
[13:58] <+Aknor> idk why evilnumber won't build
[13:58] <+Nick> well if it is on i'll be there
[13:58] <+Aknor> on linux 64
[13:59] <+Aknor> so, luck, before i go, you understand the whole deal with that proposed architecture?
[13:59] <+Luck> yea
[13:59] <+Luck> i believe so
[13:59] <+Aknor> how all the attribute mods are done deep in the module classes themselves
[13:59] <+Luck> yea
[13:59] <+Aknor> keeps everything separate so the "real" knowledge of what effects mod what attributes is hidden in each module group class
[14:00] <+Luck> yea
[14:00] <+Aknor> so, we need to pass a copy of ship attributes down into the module class calls along with the character skills
[14:01] <+Aknor> oh... just realized... how about if the ModuleManager figures out if online/activate/load charge/fit module can even happen BEFORE those functions are called on the actual module classes?
[14:02] <+Luck> yea
[14:02] <+Aknor> then we dont need those ConfirmFitModule etc calls
[14:02] <+Aknor> that seemed ugly to me
[14:02] <+Luck> i wasn't sure where you were going with those anyways
[14:02] <+Luck> :p
[14:02] <+Aknor> well, i just talked myself back into it again
[14:02] <+Aknor> how does the MM know if a module CAN be onlined?
[14:03] <+Aknor> only the module knows that info
[14:03] <+Aknor> cpu load/power load/capacitor need/ etc
[14:03] <+Aknor> unless we breakout just that stuff up into the MM
[14:03] <+Luck> the mm has access to the ship attributes and the module attributes?
[14:03] <+Luck> or just the ship
[14:03] <+Aknor> the rest, like effect specific mods go on only inside the module class
[14:04] <+Luck> well the mm needs info on the module itself
[14:04] <+Aknor> mmmm
[14:04] <+Luck> so it can check skills and such
[14:04] <+Aknor> well, but the modules themselves know about what skills are needed
[14:04] <+Luck> hmm
[14:04] <+Aknor> so we get a DogmaIMBound::Handle_Activate() call
[14:05] <+Aknor> it calls client->ModuleManager()->ActivateModule(moduleID)
[14:06] <+Aknor> which, calls m_shipRef->GetModule(moduleID)->Activate(charSkillList, shipAttribList, &externalAction)
[14:06] <+Aknor> hmm
[14:07] <+Aknor> yeah, there seems to be some things that we just cant take out of the MM
[14:07] <+Luck> i feel like the mm should check skills/pg/cpu
[14:07] <+Aknor> i'm trying to find a way to keep the MM from becoming this giant super class that has all knowledge of all things and does all things to every thing
[14:07] <+Aknor> hmmm, sounds like that would be right
[14:08] <+Luck> lol
[14:08] <+Luck> it is going to need access to the character, the ship and the module
[14:08] <+Luck> pretty much any way you do it
[14:08] <+Aknor> right
[14:08] <+Luck> unless each of the modules become superclasses that have like 8 arguments
[14:08] <+Luck> :p
[14:08] <+Aknor> access to module goes through the new Ship::GetModule(uint32 moduleFlag) that i will write
[14:09] <+Luck> you'll need more than a access by flag
[14:09] <+Aknor> pulls the module from the right container and returns the ShipModuleRef
[14:09] <+Luck> you need access by itemID
[14:09] <+Aknor> nope
[14:09] <+Luck> yes
[14:09] <+Aknor> there is a unique flag for every low slot, medium slot, and high slot, rig slot and subsystem slot, i think
[14:09] <+Luck> the client sends a itemID packet to reference a module
[14:09] <+Luck> when it's activated
[14:09] <+Luck> so there has to be a bridge between the itemID and the module
[14:10] <+Aknor> well...ok, then we just do m_shipRef->GetModule(moduleItemID), and that returns a ShipModuleRef
[14:10] <+Luck> yea
[14:10] <+Luck> that's fine
[14:10] <+Luck> im just saying that in order to handle the packet we have to have a way to look up by id
[14:10] <+Aknor> that, through polymorphism calls the right specific derived class functions
[14:11] <+Aknor> yeah the other way would have required using the itemID to get the flag and then using the flag in that GetModule() function
[14:11] <+Luck> yea
[14:11] <+Aknor> would work either way because i was planning on making the five std::map<> containers using the flag as the key, not itemID
[14:12] <+Luck> that's fine
[14:12] <+Luck> and probably easier to understand
[14:12] <+Aknor> this is why:  how do you know which itemID of the module adjacent to the one you just overloaded and is causing heat damage to the adjacent modules?
[14:12] <+Aknor> you dont.. all you know is the itemID and flag of the module you just overloaded
[14:13] <+Luck> m_ShipRef->GetModuleByItemID(itemID)->GetFlag()
[14:13] <+Aknor> so when the m_ship->GetModule(moduleItemID)->Overload() function modifies its externalAction class object
[14:13] <+Luck> hmm
[14:13] <+Luck> overloading is gonna be a bitch
[14:14] <+Aknor> nah
[14:14] <+Aknor> when the externalAction class has overload damage asserted in it, we just apply it to the adjacent modules
[14:15] <+Aknor> using this:  m_shipRef->GetModule(moduleFlag +/- 1)->OverloadDamage(blah)
[14:15] <+Aknor> or something like that
[14:15] <+Aknor> so if the only way you can access a module via the Ship::GetModule() function is by 'flag' instead of itemID , then this makes accessing the right slot easier
[14:15] <+Aknor> we can easily get the flag of the module we're working with from the itemID
[14:16] <+Aknor> it just fits... would be more clunky if we had containers for the modules where the keys were itemIDs instead of flags
[14:16] <+Luck> yea
[14:16] <+Aknor> then ya gotta iterate through each module in the container looking for the right flags
[14:17] <+Aknor> in paket_types.h there are flags for every unique slot
[14:17] <+Aknor> so that will work
[14:17] <+Luck> sounds fine to me
[14:17] <+Luck> i was just pointing out that we needed a search by itemID function
[14:17] <+Luck> :)
[14:17] <+Aknor> we can even have Ship::FitModule(moduleID) that returns 0 or 1 based on whether the slot was occupied
[14:18] <+Aknor> oh.. gotta pass the flag in as well
[14:18] <+Aknor> but, then it's already part of the InventoryItem of that module
[14:18] <+Aknor> hmmm
[14:18] <+Aknor> i've used the GetItem from ItemFactory
[14:18] <+Aknor> but that might be too inefficient
[14:18] <+Aknor> i dont think there is any other way
[14:19] <+Aknor> except query the DB
[14:19] <+Aknor> does this already exist?   m_ShipRef->GetModuleByItemID(itemID)->GetFlag()
[14:19] <+Luck> i believe so
[14:21] <+Aknor> nope. nowhere in the source
[14:21] <+Luck> hmm
[14:22] <+Aknor> ItemFactory:    InventoryItemRef GetItem(uint32 itemID);
[14:23] <+Aknor> ItemFactory is a singleton for the entire server
[14:23] <+Luck> lol
[14:23] <+Aknor> it holds a std::map<uint32, InventoryItemRef>
[14:23] <+Aknor> THAT has EVERY item ever created in the entire game universe
[14:23] <+Aknor> and THAT is how ALL items are "found" throughout the server code, so far as i can tell
[14:24] <+Luck> lol
[14:24] <+Aknor> so, InventoryItemRef GetItem(uint32 itemID)  just does m_items.find( itemID )
[14:24] <+Luck> i can see that getting pretty bogged down
[14:24] <+Aknor> m_items is the private std::map<uint32, InventoryItemRef> container
[14:24] <+Aknor> well, i have no idea how to do it better
[14:24] <+Aknor> distributed containers?
[14:24] <+Aknor> idk
[14:25] <+Luck> multi-thred it
[14:25] <+Aknor> yeah
[14:25] <+Luck> more than 1 container
[14:25] <+Aknor> eve-server is single thread single process
[14:25] <+Luck> more memory usage
[14:25] <+Aknor> yeah
[14:25] <+Luck> much faster execution
[14:25] <+Aknor> yeha
[14:25] <+Luck> w/e
[14:25] <+Luck> it's not a big deal now
[14:25] <+Aknor> well, cant fix that now... ha, yeah
[14:25] <+Luck> lol
[14:26] <+Aknor> so... almost every major class has access to the singleton ItemFactory object somehow, so all it does is m_factory->GetItem(itemID)->GetFlag()
[14:26] <+Aknor> boom, got the item flag
[14:27] <+Aknor> ah, it's just "flag()" not "GetFlag()"
[14:27] <+Luck> :)
[14:27] <+Aknor> so, what do you think so far?    Ship class gets some new functions to fit/unfit modules, provide a way to get the pointer to module classes by flag...
[14:28] <+Luck> yep
[14:28] <+Aknor> then the rest is done on the module classes themselves with their methods
[14:28] <+Aknor> all inside the MM
[14:28] <+Luck> do you agree with the mm checking skills?
[14:28] <+Aknor> so, then the MM will check cpu/power grid, right?
[14:28] <+Luck> or do you think that should be done inside the modules themselves
[14:28] <+Aknor> cpu/power grid, definitely
[14:28] <+Luck> what about skills though?
[14:28] <+Aknor> so that leaves skills, right?  nothing else to check?
[14:28] <+Luck> yea
[14:29] <+Luck> pg/cpu/skills
[14:29] <+Luck> oh
[14:29] <+Aknor> ok, so what skills and check them for what exactly?
[14:29] <+Luck> actually
[14:29] <+Luck> it has to check certain ship attributes as well
[14:29] <+Aknor> hmmm, well
[14:29] <+Luck> i did some of this in the old mm
[14:29] <+Luck> basically it has to check spaceship command skills
[14:29] <+Aknor> like i asked, for what reasons exactly do you think the MM needs to check things like skills and some ship attributes?
[14:29] <+Luck> and gunnery skills
[14:30] <+Aknor> to determine what exactly?
[14:30] <+Luck> because it seems weird
[14:30] <+Aknor> whether they can even be fitted?
[14:30] <+Luck> to split up the fit checks
[14:30] <+Luck> between the mm and the modules themselves
[14:30] <+Luck> yes
[14:30] <+Luck> because otherwise you have a situation where you have the pg and cpu to fit it
[14:30] <+Luck> so the module manager fits it
[14:30] <+Luck> then the module says NOPE from the skils
[14:30] <+Luck> so it unfits it
[14:30] <+Aknor> hmmm
[14:31] <+Luck> it seems odd to me to split up the checks
[14:31] <+Luck> mm does checks
[14:31] <+Luck> modules do effects
[14:31] <+Luck> makes more sense to me
[14:31] <+Aknor> but you know that it requires knowledge of specific needs and requirements of modules to be embedded in the MM itself
[14:31] <+Luck> if you have a ShipRef you already have all of that
[14:31] <+Aknor> so each time we add a module group, you gotta add more specific knowlege of how that module is used to the MM
[14:31] <+Luck> you need a ShipRef and a ClientRef
[14:32] <+Luck> ShipRef gives you ModuleRef which gives you it's attributes
[14:32] <+Luck> you need the ShipRef for the cpu and pg
[14:32] <+Luck> so you already have a ptr to the modules
[14:33] <+Aknor> right
[14:34] <+Luck> idk does that make sense?
[14:34] <+Aknor> but you see what i mean about specific knowledge of modules having to be in the MM?
[14:34] <+Aknor> if we had a ValidateOnline() function for each module
[14:34] <+Aknor> that could do all the checks
[14:34] <+Luck> so pg/cpu/skills
[14:34] <+Luck> all inside the module
[14:35] <+Aknor> because each module knows what skills, ship attributes, etc are required to fit/online/overload/ etc
[14:35] <+Aknor> sounds crazy i know
[14:35] <+Luck> yea
[14:35] <+Luck> lol
[14:35] <+Luck> no it doesn't
[14:35] <+Aknor> well, otherwise, i think the MM becomes some super class
[14:35] <+Luck> so what your suggesting is that the module manaager really is only an barebones interface
[14:35] <+Aknor> hehehehe, almost like the modules manage themselves, eh?
[14:36] <+Luck> between the ship modules and the client class
[14:36] <+Luck> lol
[14:36] <+Aknor> HA, but not really
[14:36] <+Luck> yea
[14:36] <+Luck> no that makes sense
[14:36] <+Luck> okay
[14:36] <+Luck> im with you on this
[14:36] <+Luck> that makes sense
[14:36] <+Aknor> well, the MM would still take the results of the ValidateXXX() calls and make decisions
[14:36] <+Luck> yea
[14:37] <+Luck> kk
[14:37] <+Aknor> it would take the modified externalAction class object that has the overload info, target effect info, whatever, and act on that
[14:37] <+Luck> yea
[14:38] <+Aknor> ok, well i gotta go.. this was good discussion.... hope ya dont think i'm trying to take over around here >_>
[14:38] <+Luck> lol
[14:38] <+Luck> i don't
[14:38] <+Luck> and even if you were
[14:38] <+Luck> i'd be more happy that things were getting done
[14:38] <+Aknor> LOL
[14:39] <+Aknor> well, so just think about this stuff i proposed some more.. see if it makes sense and in the meantime i'll start working on the Ship class, adding the std::map containers, the GetModule(flag) function, FitModule(moduleID), UnfitModule(moduleID), same for rigs and subsystems
[14:40] <+Aknor> by then we'll have had more discussion and brainstorming
[14:40] <+Luck> lol
[14:40] <+Luck> sounds good
[14:40] <+Aknor> ok, cool
[14:41] <+Aknor> as you most likely know way more than i do about the packets for all this module stuff (i know zilch), maybe you could handle that stuff?
[14:41] <+Aknor> and then i'm sure as we're integrating this stuff and actually trying to use it, i'll be examining the packets myself and learning how that part of it works
[14:41] <+Luck> yea
[14:41] <+Luck> there aren't that many we have to worry about
[14:42] <+Luck> most of the packets are for graphics stuff
[14:42] <+Aknor> for instance, how does the client handle packets for grouped modules?
[14:42] <+Luck> well that I haven't looked at yet
[14:42] <+Aknor> one packet sent if you activate the group?
[14:42] <+Luck> since i never had any info on it
[14:42] <+Aknor> haha
[14:42] <+Aknor> so, the MM might need to retain some info about module 'groups'
[14:42] <+Luck> possibly
[14:42] <+Aknor> then inside the MM, it makes the iterative calls to all the modules in that group
[14:43] <+Aknor> unless the client just sends rapid-fire activate packets for all modules in the group, OR it attaches all the itemIDs of the modules in the group inside the activate packet
[14:43] <+Aknor> bah... we'll figure it out
[14:43] <+Luck> yea
[14:43] <+Aknor> anyway. got to go, so i'll talk to you later dude
[14:43] <+Luck> it could just expand the tuple
[14:43] <+Luck> k
[14:44] <+Aknor> yeah
[14:44] <+Luck> ttyl man
[14:44] <+Aknor> ok
[14:44] ->> You are now known as Aknor|afk

PART III

[00:15] <+oza> hey hey Luck
[00:15] <@Luck> hey
[00:15] <@Luck> what's up
[00:15] <+oza> just been logging with aknor
[00:15] <+Aknor> hey
[00:15] <@Luck> hey
[00:15] <+Aknor> logging buy/sell orders
[00:15] <+oza> apart from that tring to get a stupid local vm fixed
[00:16] <@Luck> lol
[00:16] <@Luck> less log more code :p
[00:16] <@Luck> jk
[00:16] <+oza> lol
[00:16] <+oza> less chat more code
[00:16] <@Luck> lol
[00:16] * oza whips luck
[00:16] <@Luck> :(
[00:16] <+oza> :P
[00:16] <@Luck> lol
[00:17] <@Luck> aknor any progress on the ship modules?
[00:17] <+Aknor> nah
[00:17] <@Luck> lol
[00:17] <+Aknor> haven't worked on them at all
[00:17] <@Luck> ...
[00:17] <+Aknor> today was mother's day so was away all day
[00:17] <@Luck> ah
[00:17] <+Aknor> yesterday had stuff to do
[00:17] <@Luck> i understand being busy :p
[00:18] <+Aknor> i'll be doing some writing of that stuff soon :)
[00:18] <+Aknor> you waiting on them?
[00:18] <@Luck> well
[00:18] <@Luck> somewhat
[00:18] <+Aknor> hahah
[00:18] <@Luck> i want to see what your base class looks like
[00:18] <+Aknor> ah
[00:18] <@Luck> so i can A) derive more of the 138
[00:18] <+Aknor> ooooo
[00:18] <@Luck> and B) work on the mm
[00:18] <+Aknor> ok
[00:19] <+oza> 138?
[00:19] <@Luck> 138 module types
[00:19] <+Aknor> LOL
[00:19] <+Aknor> not types, groups
[00:19] <+oza> 0.0
[00:19] <@Luck> well
[00:19] <@Luck> yea
[00:19] <@Luck> oh
[00:19] <@Luck> and
[00:19] <@Luck> one more thing that's gonna make our life a little bit more of a pain in the ass
[00:19] <+Aknor> \o/
[00:19] <+oza> WAIT FOR IT
[00:19] <@Luck> we may have to include a gfx function in the derived classes
[00:19] <@Luck> as some of them are different
[00:19] <@Luck> *very different
[00:19] <+Aknor> what does that do?
[00:19] <@Luck> to send the correct graphics packets
[00:20] <+Aknor> send a gfx packet to the client(s) ?
[00:20] <@Luck> tell it what type of graphics to display
[00:20] <+oza> wouldn't it jsut be an id
[00:20] <+Aknor> ok
[00:20] <@Luck> for something like turrets yes
[00:20] <@Luck> but it may get a little screwy with boosters and shields and such
[00:20] <+Aknor> only active modules have that gfx function yeah?
[00:20] <@Luck> yes
[00:20] <@Luck> and they don't vary much between the major types of modules
[00:21] <+Aknor> ok, so that would be virtual void SendGraphicsPacket() = 0;
[00:21] <+Aknor> in the ActiveModules class
[00:21] <@Luck> something like that yea
[00:21] <+Aknor> then all of the active modules inherit it and then have to implement it on their own
[00:21] <@Luck> yea
[00:21] <+Aknor> and that would just use one of the Client send packet functions?
[00:21] <@Luck> yep
[00:21] <+Aknor> ok, so we could do this one of two ways
[00:22] <@Luck> you just create the packet, encode it and send it on it's way
[00:22] <+Aknor> one, we have this separate SendGraphicsPacket() function in EACH module class
[00:22] <+Aknor> OR, the MM does every one of them
[00:22] <@Luck> i was just about to suggest that
[00:22] <+Aknor> but, i gotta ask, it's module specific info that goes in there?
[00:22] <@Luck> what I did before was write a really general one that took a buch of input from the particular module
[00:22] <@Luck> umm
[00:22] <@Luck> more like group specific
[00:23] <+Aknor> ok
[00:23] <+Aknor> fair enough
[00:23] <@Luck> like laser turrets do laser effects
[00:23] <@Luck> etc
[00:23] <@Luck> h/o one second
[00:23] * Luck searches for table
[00:23] <+Aknor> remember that "externalAction" class thingy i suggested that we would create in the MM then pass into the module functions Activate/Online/etc that the module class would modify?
[00:23] <+Aknor> we could just put the packet to be sent in there
[00:24] <@Luck> yea
[00:24] <@Luck> that could work
[00:24] <+Aknor> then the MM would just use some CheckForGFXPacketToSend()... returns boolean
[00:24] <+Aknor> then sends the packet because the MM has access to Client object, module classes do not
[00:24] <+Aknor> so, we get best of both worlds
[00:24] <@Luck> yea
[00:24] <@Luck> or
[00:24] <@Luck> wait
[00:24] <+Aknor> module classes make the packet and send it up to MM
[00:24] <@Luck> lol
[00:24] <@Luck> nvm
[00:25] <+Aknor> then MM sends it out using Client object reference
[00:25] <@Luck> yea
[00:25] <+Aknor> but there's something else here
[00:25] <+Aknor> it's not just the client who owns that module that gets these packets right?
[00:25] <@Luck> the client doesn't own the module...
[00:25] <@Luck> im not sure i understand what you mean
[00:26] <+Aknor> ok, ok... i mean the client that owns the ship that owns the module being activated or whatever
[00:26] <+oza> wow what a headfuck
[00:26] <@Luck> lol
[00:26] <@Luck> :p
[00:26] <+Aknor> player X activates module Y, right?
[00:26] <@Luck> yes
[00:26] <+Aknor> MM calles Activate() for module X
[00:26] <+Aknor> MM then sees a GFX packet goes out
[00:26] <+oza> module Y*
[00:26] <@Luck> :)
[00:27] <@Luck> yes
[00:27] <+Aknor> but player X is in a bubble with players A, B, and C
[00:27] <+Aknor> don't all players A, B, C, and X get that gfx packet?
[00:27] <@Luck> h/o
[00:27] <+Aknor> ok
[00:27] <+oza> log and u shall see
[00:27] <+Aknor> i know, i know
[00:27] <+oza> :P
[00:27] <+Aknor> haven't gottn there yet ;)
[00:28] <@Luck> i had it working in the old one, just checking the source
[00:28] <@Luck> trac seems to be very slow
[00:29] <+Aknor> i assumed all clients in the "bubble" need to receive the gfx packet for just one ship activating a module that had an external effect like an armor repairer, so that all clients would "see" the gfx effect
[00:29] <+oza> you would think so
[00:29] <+oza> or they wouldn't get all effects
[00:29] <+Aknor> so, it needs some kind of multicast, but this might already be handled through the bubblemanager
[00:30] <@Luck> yea
[00:30] <@Luck> i only remember sending a destiny update packet
[00:30] <@Luck> and i believe that the destiny manager handled it internally
[00:30] <+Aknor> ok, so maybe that is already handling sending the packet to all clients in the bubble and the MM does not need to know HOW to do that
[00:30] <@Luck> i don't believe it does
[00:30] <@Luck> and in any case
[00:30] <@Luck> it shouldn't
[00:30] <+Aknor> it just tells the bubblemanager or whatever class does it, then it gets done
[00:30] <+Aknor> which is what makes sense
[00:30] <@Luck> that should be handled elsewhere
[00:31] <@Luck> yea
[00:31] <+Aknor> right, encapsulated elsewhere
[00:35] <@Luck> ah
[00:35] <@Luck> okay
[00:35] <@Luck> found it
[00:35] <@Luck> in dgmeffects
[00:35] <@Luck> the guid column
[00:35] <@Luck> effects.whatever
[00:35] <@Luck> that's basically what is unique about what is sent
[00:35] <@Luck> most of the time at least
[00:36] <@Luck> except effects.Laser doesn't work
[00:36] <@Luck> idk why :(
[00:39] <+Aknor> huh, weird
[00:39] <+oza> does that send it to all clients?
[00:41] <@Luck> does what send it to all clients?
[00:41] <+oza> the effects
[00:41] <+oza> dgmeffects
[00:42] <+oza> or are you jsut sayign thats where the id for it is
[00:42] <@Luck> that's where the info is
[00:42] <+oza> k
[00:45] <+Aknor> so, luck, do you think that makes sense?  have the module classes encode the gfx packet then attach it to that externalAction class instance passed into the module functions?
[00:46] <+Aknor> then the MM takes that packet, when present, and sends it out?
[00:46] <@Luck> yea
[00:46] <+Aknor> ok
[00:46] <@Luck> should be relatively simple
[00:47] <+Aknor> i haven't thought of all that would go into this externalAction class, but since it's a class object, we can add to it later without breaking what's already there
[00:47] <@Luck> the mm just does client->send(m_shipRef->GetModule(flag)->encodeGFXPacket()) or w/e
[00:47] <+Aknor> yeah, kinda
[00:47] <@Luck> i guess that's not really how i'd work if your wrapping all that up in a different class
[00:48] <@Luck> i'm kind of thinking of it as a function inside the mm kind of way
[00:48] <+Aknor> my idea was we make this ModuleAction class, that holds things like overload info on what slots get damaged due to overload and how much, this gfx packet, whatever else we need
[00:48] <@Luck> which isn't necessarily the way it should be done
[00:48] <@Luck> yea
[00:48] <+Aknor> kind of a way for the modules to "tell" the MM what needs to happen now that the module has been Onlined or Activated or Overloaded or the reverse
[00:48] <@Luck> i feel like that should be owned by the mm
[00:48] <+Aknor> yes
[00:49] <@Luck> kk
[00:49] <+Aknor> so, when dogmaIMBound calls ModuleManager->Activate(moduleID)
[00:49] <+Aknor> inside there, the MM makes a new instance of the ModuleAction class, and passes it into the module's Activate or w/e
[00:49] <+Aknor> then the Module class modifies that instance
[00:50] <+Aknor> and when the execution returns to the MM, it checks the instance of the ModuleAction class object for what's new/changed
[00:50] <+Aknor> and takes action on it, whether it's sending out the gfx packet or applying overload damage to adjacent slots' modules
[00:50] <@Luck> yea
[00:50] <@Luck> everytime i think about handling overload damage my head hurts
[00:51] <+Aknor> LOL
[00:52] <+Aknor> when we make this design functional, the design itself should make it rather easy since the modules themselves will calculate heat damage
[00:52] <@Luck> i hope so
[00:52] <+Aknor> then the MM can take that from the modified ModuleAction class object passed into the module class and apply the damage to adjacent modules according to those formulas you mentioned
[00:53] <+Aknor> where have you seen those formulas for overload damage?
[00:53] <@Luck> im looking for the forum post right now
[00:53] <@Luck> but you can read this while i search if you want
[00:53] <+Aknor> you know, again, overload stuff is another thing that EFT does
[00:53] <+Aknor> ok
[00:53] <@Luck> it goes over it from a higher level point of view
[00:53] <@Luck> yea that's true
[00:53] <+Aknor> im gonna head to bed soon, so...
[00:53] <@Luck> http://wiki.eveonline.com/en/wiki/Heat_(Game_mechanic)
[00:53] <+Aknor> ah
[00:54] <+Aknor> figured it be on evelopedia
[00:54] <@Luck> i love this
[00:54] <@Luck> i makes me want to kill the ccp devs
[00:54] <@Luck> Offline modules and empty module slots function as heat sinks, reducing the heat damage taken over time both locally (nearby overloaded module(s) on same rack) and globally (whole ship). Hence such heat dispersion slots will give you middle-term overload as trade-off.
[00:55] <+Aknor> makes sense
[00:55] <@Luck> yea
[00:55] <+Aknor> just not easy to simulate
[00:55] <@Luck> but it's a pain in the ass
[00:55] <@Luck> lol
[00:55] <+Aknor> but again, the module itself knows how much heat will be generated when overloaded, so it just returns that in the ModuleAction class
[00:56] <+Aknor> then the MM is responsible for checking adjacent module slots and assigning or sinking heat damage
[00:57] <@Luck> yea
[00:57] <@Luck> the more we talk about it the less of a pain it seems
[00:57] <@Luck> but it's still a pain :p
[00:58] <+oza> everything is still a pain
[01:01] <@Luck> okay
[01:01] <@Luck> so no one knows the exact formula
[01:01] <@Luck> afaik
[01:01] <+oza> which one?
[01:02] <@Luck> for overload damage
[01:03] <@Luck> im gonna write up what I know on overheating in the wiki
[01:03] <@Luck> so we can attempt to put together a formula
[01:03] * Luck hopes he still has wiki access
[01:03] <+Aknor> Luck, it's in EFT... has to be
[01:03] <+Aknor> LOL
[01:03] <@Luck> it is in eft
[01:03] <+Aknor> i just hate VB, LOL
[01:03] <+Aknor> but i can read it
[01:04] <@Luck> but all the people on the eve forums, including the mods say not to put much stock in his formula for that because the math is unkown
[01:04] <@Luck> that his overload formulas are just his best guess
[01:04] <+oza> why doesn't ccp release the formulas then
[01:04] <@Luck> because they're weird about that
[01:04] <@Luck> they don't release many formulas at all
[01:04] <@Luck> most are figured out by the community
[01:04] <@Luck> with a shitload of data points and excel :p
[01:05] <+oza> if u log enough packets you could come up with soemthign close ?
[01:05] <+oza> or still not close enough
[01:05] <@Luck> logging the packets is probably overkill
[01:05] <@Luck> we just need somone to spend a bunch of time breaking items with overloading and recording the time it takes to break them
[01:05] <@Luck> and the specific configuration
[01:06] <@Luck> and how different configurations affect the time
[01:06] <@Luck> etc
[01:06] <+oza> :S
[01:06] <+oza> where is hur :P
[01:06] <+oza> give him something to do
[01:06] <+oza> hehe
[01:06] <@Luck> :p