<<Prev
Next>>
Scroll to Bottom
Stuff goes here
L1[00:03:53] ⇦
Quits: mjevans (mjevans!~mjevans@li984-246.members.linode.com)
(Remote host closed the connection)
L3[00:16:34] ⇦
Quits: AnrDaemon (AnrDaemon!~ZNC@darkdragon-nln.starlink.ru) (Ping
timeout: 182 seconds)
L4[00:21:22] ⇨
Joins: AnrDaemon
(AnrDaemon!~ZNC@darkdragon-nln.starlink.ru)
L5[00:21:38] ⇨
Joins: mjevans
(mjevans!~mjevans@li984-246.members.linode.com)
L6[00:36:12] ⇨
Joins: Kaelten (Kaelten!~Kaelten@luther.kaelten.com)
L7[00:38:07] ⇦
Quits: jk-5 (jk-5!jk-5@D97A1066.cm-3-3a.dynamic.ziggo.nl) (Ping
timeout: 198 seconds)
L8[00:39:03] ⇨
Joins: jk-5
(jk-5!jk-5@D97A1066.cm-3-3a.dynamic.ziggo.nl)
L9[01:11:14] ⇦
Quits: Brokkoli (Brokkoli!~Brokkoli@p5b23c2bf.dip0.t-ipconnect.de)
(Read error: -0x7880: SSL - The peer notified us that the
connection is going to be closed)
L10[01:49:18] ⇨
Joins: immibis
(immibis!~chatzilla@222-155-160-32-fibre.bb.spark.co.nz)
L11[02:00:03] <MCPBot_Reborn> [TEST CSV]
Pushing snapshot_20180511 mappings to Forge Maven.
L12[02:00:07] <MCPBot_Reborn> [TEST CSV]
Maven upload successful for mcp_snapshot-20180511-1.12.zip
(mappings = "snapshot_20180511" in build.gradle).
L13[02:00:17] <MCPBot_Reborn> Semi-live
(every 10 min), Snapshot (daily ~3:00 EST), and Stable (committed)
MCPBot mapping exports can be found here:
http://export.mcpbot.bspk.rs/
L14[02:39:55] ⇦
Quits: AnrDaemon (AnrDaemon!~ZNC@darkdragon-nln.starlink.ru) (Ping
timeout: 198 seconds)
L15[02:45:32] ⇨
Joins: AnrDaemon
(AnrDaemon!~ZNC@darkdragon-nln.starlink.ru)
L16[02:56:21] ⇦
Quits: quadraxis
(quadraxis!~quadraxis@cpc77295-basf12-2-0-cust599.12-3.cable.virginm.net)
(Ping timeout: 198 seconds)
L17[03:29:42] ⇨
Joins: Nedelosk
(Nedelosk!~Nedelosk@ip-109-90-121-64.hsi11.unitymediagroup.de)
L18[03:38:03] ⇨
Joins: arlyon (arlyon!~arlyon@78.194.250.245)
L19[03:41:12] ⇨
Joins: quadraxis
(quadraxis!~quadraxis@cpc77295-basf12-2-0-cust599.12-3.cable.virginm.net)
L20[04:16:53] ⇨
Joins: Lupus590
(Lupus590!~Lupus590@cpc124520-swan5-2-0-cust53.7-3.cable.virginm.net)
L21[05:06:50] ⇨
Joins: Javaschreiber
(Javaschreiber!~Thunderbi@88-209-32-73.nga.highspeed-baumann.de)
L22[05:16:24] ⇨
Joins: Rokiyo (Rokiyo!~Rokiyo@101.167.173.217)
L23[05:35:37] ⇦
Quits: quadraxis
(quadraxis!~quadraxis@cpc77295-basf12-2-0-cust599.12-3.cable.virginm.net)
(Ping timeout: 194 seconds)
L24[05:37:10] ⇦
Quits: arlyon (arlyon!~arlyon@78.194.250.245) (Quit: computer gone
to sleep)
L25[05:47:50] ⇨
Joins: quadraxis
(quadraxis!~quadraxis@cpc77295-basf12-2-0-cust599.12-3.cable.virginm.net)
L26[05:56:49] ⇨
Joins: ben_mkiv
(ben_mkiv!~ben_mkiv@p5797266F.dip0.t-ipconnect.de)
L27[06:11:32] ⇦
Quits: Javaschreiber
(Javaschreiber!~Thunderbi@88-209-32-73.nga.highspeed-baumann.de)
(Ping timeout: 182 seconds)
L28[06:26:45] ⇦
Quits: Dark (Dark!~MrDark@2607:fcc8:d48b:eb00:e47a:b19a:306a:3729)
(Ping timeout: 194 seconds)
L29[06:34:45] ⇦
Quits: Nedelosk
(Nedelosk!~Nedelosk@ip-109-90-121-64.hsi11.unitymediagroup.de)
(Ping timeout: 198 seconds)
L30[06:35:11] ⇦
Quits: Lupus590
(Lupus590!~Lupus590@cpc124520-swan5-2-0-cust53.7-3.cable.virginm.net)
(Ping timeout: 202 seconds)
L31[06:37:31] ⇦
Quits: Upth
(Upth!~ogmar@108-85-88-44.lightspeed.frokca.sbcglobal.net) (Ping
timeout: 198 seconds)
L32[06:37:53] ⇨
Joins: Nedelosk
(Nedelosk!~Nedelosk@ip-109-90-121-64.hsi11.unitymediagroup.de)
L33[06:38:44] ⇨
Joins: Upth
(Upth!~ogmar@108-85-88-44.lightspeed.frokca.sbcglobal.net)
L34[06:50:13] ⇨
Joins: arlyon (arlyon!~arlyon@78.194.250.245)
L35[06:50:21] ⇨
Joins: Javaschreiber
(Javaschreiber!~Thunderbi@88-209-32-73.nga.highspeed-baumann.de)
L36[06:57:31] ⇦
Quits: immibis
(immibis!~chatzilla@222-155-160-32-fibre.bb.spark.co.nz) (Ping
timeout: 194 seconds)
L37[06:57:37] ⇦
Quits: Nedelosk
(Nedelosk!~Nedelosk@ip-109-90-121-64.hsi11.unitymediagroup.de)
(Read error: Connection reset by peer)
L38[07:01:22] ⇦
Quits: ben_mkiv (ben_mkiv!~ben_mkiv@p5797266F.dip0.t-ipconnect.de)
(Ping timeout: 182 seconds)
L39[07:11:08] ⇦
Quits: Javaschreiber
(Javaschreiber!~Thunderbi@88-209-32-73.nga.highspeed-baumann.de)
(Quit: Javaschreiber)
L40[07:19:08] ⇨
Joins: flappy
(flappy!~flappy@88-113-149-197.elisa-laajakaista.fi)
L41[07:19:27] ⇨
Joins: Javaschreiber
(Javaschreiber!~Thunderbi@88-209-32-73.nga.highspeed-baumann.de)
L42[07:30:18] ⇦
Quits: lp (lp!~lordpipe@66.109.211.167) (Quit: WeeChat
2.1)
L43[07:41:53] ⇨
Joins: ben_mkiv
(ben_mkiv!~ben_mkiv@p5797266F.dip0.t-ipconnect.de)
L44[07:51:56] ⇦
Parts: quadraxis
(quadraxis!~quadraxis@cpc77295-basf12-2-0-cust599.12-3.cable.virginm.net)
(Leaving))
L45[07:52:05] ⇨
Joins: quadraxis
(quadraxis!~quadraxis@cpc77295-basf12-2-0-cust599.12-3.cable.virginm.net)
L46[07:53:26] <SquareWheel> I've thought
about this capability stuff some more overnight. I realized I need
to change how I'm saving my data. Storing it in the implementation
itself means duplicate copies of data if other mods want to create
their own implementations.
L47[07:54:55] <SquareWheel> So either I
need a new class to store data that all implementations talk to, or
maybe I should just store it in the Storage class itself. Which
makes sense -- but I thought that was more for handling
serialization stuff.
L48[08:03:08] <ben_mkiv> oO
L49[08:03:22] <ben_mkiv> what is your
capability attached to?
L50[08:08:03] ⇨
Joins: moony
(moony!~moony@tx-76-4-56-242.dhcp.embarqhsd.net)
L51[08:13:11] <gigaherz> what
L52[08:13:14] <gigaherz> the "storage
class"
L53[08:13:17] <gigaherz> you mean the
IStorage?
L54[08:13:25] <gigaherz> that's exclusively
for serializing the default instances
L55[08:13:31] <gigaherz> (or compatible
instances)
L56[08:13:49] <gigaherz> wtf are you trying
to do?
L57[08:13:49] <gigaherz> XD
L58[08:15:35] <SquareWheel> Oh, a
continuation of the discussion last night.
L59[08:15:41] <SquareWheel> Cap is being
attached to the player.
L60[08:16:15] <ben_mkiv> then write the
data to the player nbt?!
L61[08:17:01] <SquareWheel> I do... but I
don't want to be using NBT every time I read/save the value. That
should be abstracted.
L62[08:17:05] <ForgeDiscord> <Ben>
which the cap data should be written to, anyways
L63[08:17:33] <ForgeDiscord> <Ben>
you only change it within your class and store it when writeToNBT()
is called
L64[08:18:55] <SquareWheel> For context, I
was handling all logic and storage in my default implementation
before. I'm now trying to make it more API friendly.
L65[08:19:09] <ForgeDiscord> <Ben> i
mean, you dont have to care about saving at all as this is
automagicly called on world load/unload
L66[08:19:23] <SquareWheel> That part
works.
L67[08:19:35] <SquareWheel> Maybe I
shouldn't be using the word "storing"
L68[08:19:46] <ForgeDiscord>
<JamiesWhiteShirt> there is no need to use NBT internally in
the capability implementation
L69[08:20:04] <ForgeDiscord>
<JamiesWhiteShirt> as long as your storage or capability
provider is capable of converting it to NBT, it's fine
L70[08:20:20] <SquareWheel> Yes, that part
works fine.
L71[08:20:28] <SquareWheel> It's
saved/loaded properly on world saves.
L72[08:20:47] <SquareWheel> I'm just
thinking about where to store the actual data in-memory so it's
readable by all cap implementations.
L73[08:20:57] <SquareWheel> That is, which
class is most appropriate
L74[08:21:05] <ForgeDiscord> <Ben>
and when you load it, the data is assigned to some variables in
your capability handler, for save vice versa
L75[08:21:32] <ForgeDiscord>
<JamiesWhiteShirt> I'm not sure what you mean. the data would
be stored in memory in your capability implementation
L76[08:22:05] <SquareWheel> Oh, is it most
appropriate to store it in the cap implementation? My concern was
that would lead to duplicate data from different
implementations.
L77[08:22:16] <SquareWheel> There should
only be one set of this data.
L78[08:22:24] <ForgeDiscord>
<JamiesWhiteShirt> per...?
L79[08:23:04] <SquareWheel> Per... cap
implementation?
L80[08:23:32] <ForgeDiscord> <Ben> it
does create a "instance" anyways for each thing you
attach it to
L81[08:23:55] <ForgeDiscord>
<JamiesWhiteShirt> yes. the data belongs in the capability
instance
L82[08:24:27] <SquareWheel> Hrmm, well
that's where it is now. I see there being problems later with other
implementations though.
L83[08:24:35] <ForgeDiscord>
<JamiesWhiteShirt> how so?
L84[08:24:53] <SquareWheel> So the mod is
storing player nutrients, based on food eaten. It saves to the
player via cap.
L85[08:25:15] <SquareWheel> If another mod
wanted to read that data, they'd create their own implementation,
or use the default one.
L86[08:25:30] <ForgeDiscord> <Ben>
they would access your capability
L87[08:25:52] <ForgeDiscord> <Ben> as
this is the instance that stores the data, otherwise yea you would
end up with separate datasets for one player
L88[08:26:03] <gigaherz> SquareWheel:
"where to store the actual data in-memory so it's readable by
all cap implementations."
L89[08:26:06] <gigaherz> you are thinking
it wrong
L90[08:26:18] <ForgeDiscord> <Ben> a
capability is what it is, you only attach it once
L91[08:26:26] <gigaherz> if you have data
that is specific to an entity
L92[08:26:28] <gigaherz> and you have a
capability
L93[08:26:33] <gigaherz> the capability
just holds the data
L94[08:26:46] <gigaherz> no need to
overthink
L95[08:27:43] <SquareWheel> So if that data
is stored in let's say DefaultImplementation.class, even though
other mods may have their own implementations, that data won't be
duplicated?
L96[08:28:05] <gigaherz> well
L97[08:28:08] <gigaherz> think about
it
L98[08:28:14] <ForgeDiscord>
<JamiesWhiteShirt> it will not be duplicated, because each
entity would only have one capability instance
L99[08:28:23] <gigaherz> first, what Jamies
says
L100[08:28:31] <gigaherz> you can only
have one instance attached of a capability interface
L101[08:28:36] <gigaherz> if your
capability is IYourData
L102[08:28:53] <gigaherz> there can only
be one instance of Capability<IYourData> in an entity
L103[08:29:09] <gigaherz> there can only
be one instance managed by Capability<IYourData> in an entity
**
L104[08:29:14] <ForgeDiscord>
<JamiesWhiteShirt> (instance of IYourData)
L105[08:29:35] <gigaherz> but someone
could register a IExtendedYourData, managed by
Capability<IExtendedYourData>, and attach that
L106[08:29:43] <gigaherz> even if
IExtendedYourData extends IYourData
L107[08:29:51] <gigaherz> so far as forge
is concerned, they are different
L108[08:29:53] <gigaherz> but then
L109[08:30:12] <gigaherz>
getCapability(IYourData) woudl NOT return the instance of
IExtendedYourData
L110[08:30:28] <gigaherz> so let's leave
that aside
L111[08:30:34] <gigaherz> let's consider 2
possible types of capabilities
L112[08:30:51] <gigaherz> 1. data storage
capabilities, which may or may not be publicly readable, but are
managed internally by your mod, and not implemented by anyone
else
L113[08:31:21] <gigaherz> 2. API accessor
capabilities, which do not necessarily store some predefined data,
and the person who wants to make use of the API will implement and
expose
L114[08:31:26] <gigaherz> yo uare trying
to mix 1 and 2
L115[08:31:31] <gigaherz> and they should
be different capabilities
L116[08:31:40] <gigaherz> probably.
L117[08:33:48] <SquareWheel> Hrmm. That
would require duplicating all the Storage/Provider/Factory stuff as
well then to have two Caps, right?
L118[08:34:05] <SquareWheel> Even if
Storage is unused for the accessor one.
L119[08:35:11] <ForgeDiscord>
<JamiesWhiteShirt> that would complicate the capability
provider a bit
L120[08:35:45] <SquareWheel> Ideally I'd
like to reduce complexity - not add.
L121[08:36:52] <SquareWheel> For now I'll
go back to what I was doing before and have my data in the default
impl class.
L122[08:39:13]
⇨ Joins: moony_
(moony_!~moony@tx-76-4-56-242.dhcp.embarqhsd.net)
L123[08:40:39] ⇦
Quits: moony (moony!~moony@tx-76-4-56-242.dhcp.embarqhsd.net) (Ping
timeout: 194 seconds)
L124[08:43:04] <SquareWheel> Appreciate
the help, by the way. giga, Jamie, Ben.
L125[08:43:28] <SquareWheel> Eventually
these things will click for me.
L126[08:43:59] ⇦
Quits: quadraxis
(quadraxis!~quadraxis@cpc77295-basf12-2-0-cust599.12-3.cable.virginm.net)
(Ping timeout: 202 seconds)
L127[08:44:16] <ForgeDiscord>
<JamiesWhiteShirt> it probably is one of the more confusing
concepts
L128[08:44:35] <ForgeDiscord>
<JamiesWhiteShirt> it didn't click for me until I did it a
few times
L129[08:46:48] <SquareWheel> The worst
part is, when I first wrote this mod a year ago I finished all but
one step: data saving. Disappointment ensused as I rewrote the
whole thing to use caps instead.
L130[08:47:12] <SquareWheel> In hindsight
I would have started there, if I knew what they were.
L131[08:53:01]
⇨ Joins: quadraxis
(quadraxis!~quadraxis@cpc77295-basf12-2-0-cust599.12-3.cable.virginm.net)
L132[09:08:18] <SquareWheel> I was
re-reading this chat to make sure I understood. Could I ask you to
clarify something, Jamie?
L133[09:08:23] <SquareWheel>
<JamiesWhiteShirt> yes. the data belongs in the capability
instance
L134[09:08:40] <SquareWheel> Is the
"instance" here different from the default
implementation?
L135[09:15:04] <ForgeDiscord>
<JamiesWhiteShirt> yes. the instance is some instance of
IYourData. the default implementation is a factory/class
L136[09:16:29] <SquareWheel> And each
entity only has one instance of your cap (interface) type.
L137[09:16:47] <ForgeDiscord>
<JamiesWhiteShirt> generally, yes.
L138[09:17:01] <ForgeDiscord>
<JamiesWhiteShirt> for your purposes, yes.
L139[09:17:36]
⇨ Joins: Fye
(Fye!~Fye@146-241-16-181.dyn.eolo.it)
L140[09:17:50] <SquareWheel> Would a
sister mod using its own cap implementation not have its own
instance?
L141[09:18:27] <ForgeDiscord>
<JamiesWhiteShirt> well, then your would have a
conflict
L142[09:18:31] <ForgeDiscord>
<JamiesWhiteShirt> you*
L143[09:18:43] <SquareWheel> The data
duplication issue I was worried about before?
L144[09:19:15] <ForgeDiscord>
<JamiesWhiteShirt> I see we're back where
L145[09:19:17] <ForgeDiscord>
<JamiesWhiteShirt> we started
L146[09:19:23] <SquareWheel> Afraid
so.
L147[09:20:08] <ForgeDiscord>
<JamiesWhiteShirt> if a sister mod were to have its own
instance per entity that your mod does too, you would have a
conflict. this is something you can assume is avoided
L148[09:22:00] <SquareWheel> Would you
mind elaborating on the assumption part?
L149[09:22:09] <ForgeDiscord>
<JamiesWhiteShirt> OK
L150[09:22:25] <ForgeDiscord>
<JamiesWhiteShirt> so this capability, at the moment, exists
for players, that is EntityPlayers?
L151[09:22:43]
⇨ Joins: Brokkoli
(Brokkoli!~Brokkoli@p5B23C2BF.dip0.t-ipconnect.de)
L152[09:23:25] <SquareWheel> Yes.
L153[09:25:56] <ForgeDiscord>
<JamiesWhiteShirt> assume your capability provider (that you
attach to EntityPlayers) provides an IYourData for
Capability<IYourData>. if some sister mod were to do the
same, you have a conflict as you can't really know which one
overrides which.
L154[09:26:33] <ForgeDiscord>
<JamiesWhiteShirt> it doesn't make sense for two mods to
provide the same capability for the same entity
L155[09:27:30] <ForgeDiscord>
<JamiesWhiteShirt> therefore you can assume that your
capability provider is the only capability provider attached to
EntityPlayer that will provide an IYourData for
Capability<IYourData>
L156[09:28:13] <ben_mkiv> also you could
check on the attach event if the capability is already attached to
the entity
L157[09:29:14] <SquareWheel> Okay, so
there's only one Provider. That's good.
L158[09:29:35] <SquareWheel> Though the
Provider does instantiate the instance from your chosen
implementaion (probably the default one).
L159[09:29:36] <ForgeDiscord>
<JamiesWhiteShirt> what some sister mod might actually want
to do is attach a capability provider for
Capability<IYourData> to some other entity. that is where
default implementations and storage comes in. the sister mod would
probably not have access to your capability provider class and must
make one for itself. the sister mod's capability provider may use
the default implementation and default storage to work
L160[09:30:20] <SquareWheel> Hoo...
L161[09:30:26] <SquareWheel> Okay
L162[09:30:54] <SquareWheel> So they could
use my Storage, but not my Provider, or its associated
instance.
L163[09:31:01] <ForgeDiscord>
<JamiesWhiteShirt> correct
L164[09:31:29] <SquareWheel> As the data
is stored in the instance though... they'd have to read it directly
from NBT using the Storage instead.
L165[09:31:37] <SquareWheel> Could that
create problems?
L166[09:32:29] <ForgeDiscord>
<JamiesWhiteShirt> I don't see why it would
L167[09:32:37] <gigaherz> I'm not sure
that the storage does what you think it does...
L168[09:32:54] <ForgeDiscord>
<JamiesWhiteShirt> the storage is only a tool for NBT
serialization. it doesn't store anything
L169[09:33:11] <gigaherz> the IStorage you
register with a Capability, is just a tool
L170[09:33:13] <ForgeDiscord>
<JamiesWhiteShirt> kind of a misnomer, really
L171[09:33:18] <gigaherz> to serialize and
deserialize a default instance
L172[09:33:36] <gigaherz> for the purpose
of implementing writetoNBT/readFromNBT in your thing
L173[09:33:47] <gigaherz> or
serializeNBT/deserializeNBT in your ICapabilitySerializable
L174[09:33:58] <gigaherz> if you expect
anyone to do anything other than that
L175[09:34:01] <gigaherz> you are using it
wrong.
L176[09:34:15] <gigaherz> basically:
L177[09:34:20] <gigaherz>
ICapabilitySerializable {
L178[09:34:48] <gigaherz> T serializeNBT()
{ return THE_CAP.writeNBT(instance); }
L179[09:34:58] <SquareWheel> I think I
mispoke. Storage is called automatically (by Forge on world save
events or some such), but the methods describe *what* to save,
yeah?
L180[09:35:06] <SquareWheel> And also what
to load
L181[09:35:11] <gigaherz> void
deserializeNBT(T nbtData) { THE_CAP.readNBT(instance, nbtData);
}
L182[09:35:17] <gigaherz> }
L183[09:35:33] <ForgeDiscord>
<JamiesWhiteShirt> no, storage is not called
automatically!
L184[09:35:41] <gigaherz> the
implementation of IStorage is a tool
L185[09:35:43] <ForgeDiscord>
<JamiesWhiteShirt> that's actually an important detail
L186[09:35:52] <SquareWheel> Haha oh
boy
L187[09:35:53] <gigaherz> so that you can
serialize the class returned by getDefualtInstance
L188[09:36:00] <SquareWheel> How does this
code even work at all right now
L189[09:36:10] <gigaherz> YOU implement
the serialization in your provider.
L190[09:36:22] <gigaherz> where YOU = the
person implementing the provider
L191[09:36:33] <ForgeDiscord>
<JamiesWhiteShirt> the Storage is a tool to be used by a
capability provider. but it does not have to use a Storage
L192[09:36:52] <ForgeDiscord>
<JamiesWhiteShirt> the Storage is simply a tool to help
OTHERS implement capability providers
L193[09:36:53] <gigaherz> it's
specifically there to go along with default instances
L194[09:36:55] <gigaherz> nothing more
nothing less
L195[09:37:06] <gigaherz> since you don't
know what interfaces the default instances have
L196[09:37:09] <gigaherz> the IStorage
does.
L197[09:37:17] <gigaherz> so
L198[09:37:27] <gigaherz> someone doing X
= CAP.getDefaultInstance();
L199[09:37:31] <gigaherz> will later want
to do
L200[09:37:36] <gigaherz>
CAP.writeNBT/readNBT
L201[09:37:39] <gigaherz> which in
turn
L202[09:37:50] <gigaherz> internally does
getStorage().writeNBT / readNBT
L203[09:38:12] <gigaherz> you *can* tell
people that it's ok to use your IStorage in other situations
L204[09:38:31] <gigaherz> but its primary
purpose, is to allow the result of getDefaultInstance() to be
opaque
L205[09:38:32] ⇦
Quits: Javaschreiber
(Javaschreiber!~Thunderbi@88-209-32-73.nga.highspeed-baumann.de)
(Ping timeout: 182 seconds)
L206[09:38:35]
⇨ Joins: Zethalion
(Zethalion!~Zethalion@095-097-058-227.static.chello.nl)
L207[09:38:49] <gigaherz> so in
general:
L208[09:39:07] <gigaherz>
Entity/TileEntity/ItemStack have their writeToNBT/readFromNBT
L209[09:39:22] <gigaherz> in those
methods, forge iterates through the attached capabilities
L210[09:39:29] <gigaherz> attached
providers**
L211[09:39:37] <gigaherz> important
distinction -- it iterates attached providers
L212[09:39:41] <gigaherz> then for each
provider
L213[09:39:54] <gigaherz> if the provider
implements INBTSerializable (such as ICapabilitySerializable
does)
L214[09:40:04] <gigaherz> it calls
serializeNBT/deserializeNBT
L215[09:40:09] <gigaherz> this is as far
as forge is concerned
L216[09:40:23] <gigaherz> everything from
there is up to the implementation of the ICapabilityPovider
L217[09:40:35] <gigaherz> you can write
your own code in the provider
L218[09:40:42] <gigaherz> you can use
CAP.getStorage()
L219[09:40:42] <SquareWheel> Okay, I'm
just reviewing what was said to me to make sure I understand.
L220[09:40:50] <gigaherz> you can use
CAP.writeNBT/readNBT
L221[09:41:08] <gigaherz> you can
explicitly say that your instance implements INBTSerializable and
call those methods
L222[09:41:17] <gigaherz> or you can
provide custom methods specific to your use case.
L223[09:42:47] <SquareWheel> So looking at
my code, I am indeed calling write/read NBT from the Provider. I
guess I meant that the serialize method is called on world saves,
where in turn I writeNBT.
L224[09:43:00] <SquareWheel> So just
missed a step
L225[09:46:44] ⇦
Quits: Zethalion
(Zethalion!~Zethalion@095-097-058-227.static.chello.nl) (Read
error: Connection timed out)
L226[09:50:00] <SquareWheel> Okay, think
I'm with you for the most part.
L227[09:51:11] <SquareWheel> Guess I need
to decide if I want my Storage class to be just for default
implementation, or more general.
L228[09:51:17] <SquareWheel> And make that
clear.
L229[10:03:28]
⇨ Joins: Javaschreiber
(Javaschreiber!~Thunderbi@88-209-32-73.nga.highspeed-baumann.de)
L230[10:15:44]
⇨ Joins: Nedelosk
(Nedelosk!~Nedelosk@ip-109-90-121-64.hsi11.unitymediagroup.de)
L231[10:16:06] ⇦
Quits: Lynndis (Lynndis!~Lynn@c-75-71-231-133.hsd1.co.comcast.net)
(Ping timeout: 182 seconds)
L232[10:22:31]
⇨ Joins: auenfx8 (auenfx8!~David@110.150.99.123)
L233[10:23:43] ⇦
Quits: auenf (auenf!~David@110.150.99.123) (Ping timeout: 198
seconds)
L234[10:25:15] ⇦
Quits: arlyon (arlyon!~arlyon@78.194.250.245) (Quit: computer gone
to sleep)
L235[10:29:51]
⇨ Joins: Zethalion
(Zethalion!~Zethalion@095-097-058-227.static.chello.nl)
L236[10:29:55] ⇦
Quits: quadraxis
(quadraxis!~quadraxis@cpc77295-basf12-2-0-cust599.12-3.cable.virginm.net)
(Ping timeout: 202 seconds)
L237[10:31:53]
⇨ Joins: Noppes
(Noppes!~Noppes@ip56530f2e.direct-adsl.nl)
L238[10:34:52] <SquareWheel> So the
CAPABILITY field which is injected in the Provider - is that only
there to act as an identifier for your instance (where the real
work is done)?
L239[10:35:47] <gigaherz> the what?
L240[10:36:10] <gigaherz> I have no idea
what you are talking about
L241[10:36:16] <SquareWheel> Yeah, was
afraid of that.
L242[10:36:27] <SquareWheel> Sorry, not
being a Java programmer I sometimes guess at the terms.
L243[10:36:44] <gigaherz> can you show me
the place in your code you are thinking of? :P
L244[10:37:13] ⇦
Quits: auenfx8 (auenfx8!~David@110.150.99.123) (Remote host closed
the connection)
L245[10:37:19] <SquareWheel> I haven't
committed the mess I'm currently working on yet, but I'll link how
it looked yesterday.
L247[10:38:11] <SquareWheel> So this guy,
NUTRITION_CAPABILITY. I'm wondering if that acts as more of a
reference for talking about the capability, whereas the instance is
doing the real work.
L248[10:38:15] <ForgeDiscord>
<JamiesWhiteShirt> yes, forge will create a shared Capability
for the capability interface and inject it into the fields
L249[10:38:31] <ForgeDiscord>
<JamiesWhiteShirt> that is what identifies the
capability
L250[10:38:44] <SquareWheel> Okay, thanks,
that helps.
L251[10:38:54] <ForgeDiscord>
<JamiesWhiteShirt> it is also what holds the default
implementation and storage
L252[10:39:04] <SquareWheel> Oh
L253[10:39:44] <gigaherz> you knwo how you
have an Item, that manages all the ItemStacks of that item?
L254[10:39:53] <gigaherz> the
Capability<T> manages all the capabilities of T
L255[10:40:21] <gigaherz> the providers
are what ties the objects with the instances
L256[10:41:13] <SquareWheel> Hrmm, I never
looked at Items as managing their ItemStacks. I saw it as more of a
reference from within the ItemStack, but not as a child.
L257[10:41:16]
⇨ Joins: auenf (auenf!~David@110.150.99.123)
L258[10:41:41] <ForgeDiscord>
<JamiesWhiteShirt> it's not that similar, honestly
L259[10:42:04]
⇨ Joins: Lynndis
(Lynndis!~Lynn@c-75-71-231-133.hsd1.co.comcast.net)
L260[10:42:21] <gigaherz> it serves both
as an identifier for the purpose of
getCapability/hasCapability
L261[10:42:39] <gigaherz> as well as a
helper for creating and serializing default instances
L262[10:42:52] <gigaherz> so to me, it's
on the same category as Item or Block
L263[10:44:21] <SquareWheel> So in my
case, player.getCapability(CapProvider.NUTRITION_CAPABILITY, null)
references the instance (of type CapInterface), right?
L264[10:44:41] <SquareWheel> And don't
worry I've already renamed these things to be less silly in my
current code.
L265[10:45:42] <ForgeDiscord>
<JamiesWhiteShirt> yes
L266[10:46:26] <SquareWheel> Okay, great.
So I know the instance also holds the methods as defined in my
implementation set up in the Provider.
L267[10:46:36] <ForgeDiscord>
<JamiesWhiteShirt> though I suggest not referencing the
Capability<CapInterface> via CapProvider. the capability
provider is supposed to be transparent
L268[10:48:17] <SquareWheel> Should I move
the code elsewhere, or approach it differently?
L269[10:48:36] <ForgeDiscord>
<JamiesWhiteShirt> it would be moving the field elsewhere,
that's all
L270[10:48:49]
⇨ Joins: arlyon
(arlyon!~arlyon@89-156-29-233.rev.numericable.fr)
L271[10:48:57] <gigaherz> yeah people
shouldn't even know that there's a provider
L272[10:49:03] <gigaherz> unless they need
to
L273[10:51:51] <SquareWheel> Okay, so move
NUTRITION_CAPABILITY elsewhere not in the Provider, and then it
doesn't need to be referenced by my mod or others.
L274[10:56:44] ⇦
Quits: moony_ (moony_!~moony@tx-76-4-56-242.dhcp.embarqhsd.net)
(Ping timeout: 182 seconds)
L275[11:01:03] ⇦
Quits: Nedelosk
(Nedelosk!~Nedelosk@ip-109-90-121-64.hsi11.unitymediagroup.de)
(Ping timeout: 194 seconds)
L276[11:05:12] <ForgeDiscord>
<JamiesWhiteShirt> the docs actually recommend placing them
in static fields in the classes that need them for locality
L277[11:10:45] ⇦
Quits: arlyon (arlyon!~arlyon@89-156-29-233.rev.numericable.fr)
(Ping timeout: 198 seconds)
L278[11:11:53]
⇨ Joins: arlyon
(arlyon!~arlyon@89-156-29-233.rev.numericable.fr)
L279[11:18:45]
⇨ Joins: Nedelosk
(Nedelosk!~Nedelosk@ip-109-90-121-64.hsi11.unitymediagroup.de)
L280[11:20:01]
⇨ Joins: apexmodder
(apexmodder!~apexmodde@95.145.48.103)
L281[11:26:11] ⇦
Quits: arlyon (arlyon!~arlyon@89-156-29-233.rev.numericable.fr)
(Ping timeout: 194 seconds)
L282[11:28:32]
⇨ Joins: arlyon
(arlyon!~arlyon@89-156-29-233.rev.numericable.fr)
L283[11:32:40]
⇨ Joins: Lupus590
(Lupus590!~Lupus590@cpc124520-swan5-2-0-cust53.7-3.cable.virginm.net)
L284[11:37:55] ⇦
Quits: apexmodder (apexmodder!~apexmodde@95.145.48.103) (Remote
host closed the connection)
L285[11:39:38]
⇨ Joins: moony
(moony!~moony@tx-76-4-56-242.dhcp.embarqhsd.net)
L286[11:41:35] ⇦
Quits: arlyon (arlyon!~arlyon@89-156-29-233.rev.numericable.fr)
(Ping timeout: 182 seconds)
L287[11:43:05] <SquareWheel> Oh, so keep
multiple copies (each using the injection system) in all relevant
classes?
L288[11:43:43] <SquareWheel> For now I
made a sort of manager class that holds a reference.
L289[11:43:56] <SquareWheel> Also handles
registration and keeps the provider/storage as inner classes.
L290[11:43:56] <gigaherz> it's slightly
more efficient that way
L291[11:44:10]
⇨ Joins: arlyon
(arlyon!~arlyon@89-156-29-233.rev.numericable.fr)
L292[11:44:13] <gigaherz> local statics
are a tiny tiny bit faster
L293[11:44:17] <gigaherz> but it's not so
much about speed
L294[11:44:23] <gigaherz> as it is about
design
L295[11:44:34] <gigaherz> since the
capability instance is only useful to those who need it
L296[11:44:35] <SquareWheel> Yeah, I'd
prioritize cleanliness over micro-optimizations.
L297[11:44:39] <gigaherz> why not just
declare it where you need it?
L298[11:45:01] <SquareWheel> I suppose I
figured the injection code might be slow, so didn't want to
duplicate.
L299[11:45:09] <SquareWheel> But if that's
accepted I'll do that.
L300[11:46:31] <SquareWheel> On the plus
side, it cleans up the big ugly .getCapability() calls.
L301[11:56:57] ⇦
Quits: arlyon (arlyon!~arlyon@89-156-29-233.rev.numericable.fr)
(Ping timeout: 194 seconds)
L302[12:35:37] <SquareWheel> Is there a
good way to get the attached entity from within a cap
implementation? Previously I passed the entity it when creating it,
but that approach has problems.
L303[12:36:10] <SquareWheel> *passed it
in
L304[12:36:20] <ForgeDiscord>
<killjoy> are you saving the entity somewhere?
L305[12:36:41] <SquareWheel> The entity is
the player.
L306[12:36:52] <ForgeDiscord>
<killjoy> but are you saving it?
L307[12:36:59] <ForgeDiscord>
<killjoy> or using it to look up?
L308[12:37:24] <SquareWheel> I'm not
sure... I'm attaching a cap to the player to save data.
L309[12:38:04] <SquareWheel> The data is
saved through the Provider.serialize then Storage.writeNBT
methods.
L310[12:39:00] <ForgeDiscord>
<killjoy> so you're just saving some data?
L311[12:39:05] <SquareWheel> Yes.
L312[12:39:12] <ForgeDiscord>
<killjoy> what is the data for?
L313[12:39:35] <ForgeDiscord>
<killjoy> and shouldn't you get the capability from the
player?
L314[12:39:47] <SquareWheel> Sorry for
lack of context - I talked about it a bit earlier. The data is
nutritional information managed by my mod.
L315[12:40:33] <ForgeDiscord>
<killjoy> I'm the wrong guy to help with caps anyway
L316[12:40:52] <SquareWheel> I'm not sure
what you mean by "getting it from the player", but I am
assigning the cap to the player using the attach event.
L317[12:48:34] <ForgeDiscord>
<JamiesWhiteShirt> you need to either add the player as a
parameter to the capability interface
L318[12:48:58] <ForgeDiscord>
<JamiesWhiteShirt> or you must get the player in the
capability attach event and pass it to the capability
provider
L319[12:49:31] <SquareWheel> Darn.
L320[12:49:35] <SquareWheel> I was doing
the latter before.
L321[12:50:16] <SquareWheel> I can get the
player at the attach event because the entity is available there.
Not so during the original registration, when it's looking for a
factory.
L322[12:51:05] <ForgeDiscord>
<JamiesWhiteShirt> yes, if you need access to the player
without using method parameters, the factory cannot be used
L323[12:51:26] <SquareWheel> Bit
problematic because the old method of just passing the class in is
now deprecated.
L324[12:51:58] <ForgeDiscord>
<JamiesWhiteShirt> well, make a dummy factory that just
throws an UnsupportedOperationException
L326[12:53:23] <SquareWheel> Quick
sidenote - can we say Lx's name? I remember that being taboo
before.
L327[12:53:53] <ForgeDiscord>
<JamiesWhiteShirt> try not to mention it in whatever way
notifies people on IRC
L328[12:54:01] <SquareWheel> First three
characters okay?
L329[12:54:11] <ForgeDiscord>
<JamiesWhiteShirt> should be
L330[12:54:25] <ForgeDiscord>
<killjoy> in discord, you can say his name all you want in
non-irc. Just don't @ him
L331[12:54:51] <ForgeDiscord>
<killjoy> that's what i assume at least
L332[12:55:01] <SquareWheel> Okay. So Lex
gave me some critique last night when I asked about the factory
issue. He suggested just removing the player stuff altogether and
doing it in a custom implementation.
L333[12:55:40] <SquareWheel> Custom
implementation kinda has the same problem though, as I understand
it. If registered at the beginning, you don't have a player
reference to use.
L334[12:56:01] <ForgeDiscord>
<killjoy> The general rule is don't mention him unless only
he can help. If someone can help you, just don't.
L335[12:56:07] <ForgeDiscord>
<JamiesWhiteShirt> not providing any default implementation
and factory isn't a big deal
L336[12:56:16] <ForgeDiscord>
<killjoy> though he is good at watching chat.
L337[12:57:08] <SquareWheel> I was
thinking I'd do the default impl as a sort of stripped down
version.
L338[12:57:24] <SquareWheel> Then extend
it and add more features for my custom implementation.
L339[12:57:30] <ForgeDiscord>
<JamiesWhiteShirt> yes, you can do that
L340[12:58:07] <SquareWheel> So for the
initial cap registration I should use DefaultImplementation, and
when attaching the cap use CustomImplementaiton.
L341[12:58:14] <SquareWheel> Does that
seem reasonable?
L342[12:58:36] <SquareWheel> Custom would
add syncing features, which I need the player for.
L343[12:58:52] <ForgeDiscord>
<JamiesWhiteShirt> yes, that makes sense
L344[13:00:01] <SquareWheel> Great, I'll
play around with that. Thank you.
L345[13:00:11] <ForgeDiscord>
<killjoy> SimpleImpl is better name
L346[13:00:34] <SquareWheel> Plus it's
more fun to say.
L347[13:00:52] <SquareWheel> Okay, I'll
rename, thanks
L348[13:05:00] <SquareWheel> Oh so it must
be the registration that defines which implementation is
default.
L349[13:05:06] <SquareWheel> That makes
sense.
L350[13:05:17] <ForgeDiscord>
<JamiesWhiteShirt> yup
L351[13:23:06] <SquareWheel> Hrmm. But if
I use my own implementation with additional methods, how would I
call those? Seeing as they're not available in the Interface.
L352[13:23:16] ⇦
Quits: Javaschreiber
(Javaschreiber!~Thunderbi@88-209-32-73.nga.highspeed-baumann.de)
(Quit: Javaschreiber)
L353[13:23:38] <ForgeDiscord>
<JamiesWhiteShirt> then the methods should be part of the
interface
L354[13:23:49] <ForgeDiscord>
<JamiesWhiteShirt> they have to design it so that it can be
used through that interface
L355[13:24:29]
⇨ Joins: Javaschreiber
(Javaschreiber!~Thunderbi@88-209-32-73.nga.highspeed-baumann.de)
L356[13:24:55] <SquareWheel> Or I suppose,
those additional methods just shouldn't be a part of the cap system
at all.
L357[13:25:27] <SquareWheel> Kinda negates
my reason for having two implementations in the first place
though.
L358[13:25:37] <ForgeDiscord>
<killjoy> if you want to use it from outside the impl, put it
in the api
L359[13:25:41] <ForgeDiscord>
<killjoy> api being the interface
L360[13:28:50] <SquareWheel> Afraid it's
not really doable in this case. What I wanted to implemented was a
network sync feature, which requires the player to sync with. Can't
do that from the simple implementation due to the issues described
above, so it can't be in the API.
L361[13:29:06] <SquareWheel> *wanted to
implement
L362[13:29:13] <ForgeDiscord>
<JamiesWhiteShirt> and it shouldn't, either
L363[13:29:24] <ForgeDiscord>
<JamiesWhiteShirt> be in the API, that is
L364[13:29:38] <SquareWheel> Lex said the
same. Largely why I started this refactor.
L365[13:29:54] <ForgeDiscord>
<JamiesWhiteShirt> you can just design the interface to
accomodate the network sync. default implementation has none, yours
has
L366[13:30:16] <SquareWheel> It would be
in the API then?
L367[13:30:30] <ForgeDiscord>
<JamiesWhiteShirt> not explicitly
L369[13:34:02] <SquareWheel> Any line
specifically, or the whole interface?
L370[13:34:46] <ForgeDiscord>
<JamiesWhiteShirt> pretty much all the methods do some sort
of syncing, but it is entirely possible to implement this interface
both with and without it
L371[13:35:12] <SquareWheel> So I could
have a sync() method and just have it... not work for the default
impl.
L372[13:35:23] <SquareWheel> Pass in null
for the player in the default impl.
L373[13:35:45] ⇦
Quits: Rokiyo (Rokiyo!~Rokiyo@101.167.173.217) (Remote host closed
the connection)
L374[13:35:48] <ForgeDiscord>
<JamiesWhiteShirt> you could, although it would be quite
simple to just auto-sync in the methods
L375[13:36:02]
⇨ Joins: Rokiyo (Rokiyo!~Rokiyo@101.167.173.217)
L376[13:36:23] <SquareWheel> That's how it
works now actually. Well, there's an argument to auto-sync.
L378[13:36:51] <SquareWheel> Lex had
suggested removing the player/network stuff from the default
implementation so that was my plan to move it to an enhanced impl
instead.
L379[13:37:45] <ForgeDiscord>
<JamiesWhiteShirt> yes, it probably shouldn't be in the
default implementation
L380[13:38:12] <SquareWheel> Hrm. So
extend it, run super() for each method, then add sync code.
L381[13:38:36] <ForgeDiscord>
<JamiesWhiteShirt> yup, extend or delegate
L382[13:38:55] <SquareWheel> I'll play
with that approach. It's starting to feel kiinda messy
though.
L383[13:39:06] <SquareWheel> Lots of
boilerplate
L384[13:46:40] <LexManos> 06:29
<gigaherz> there can only be one instance managed by
Capability<IYourData> in an entity ** Not true you can have
up to 7 valid instances.
L385[13:49:04] <LexManos> as for the sync
crap, what if you wanna attach nutrition info to say... a sheep,
and start making it become sick if it doesnt get a balanced diet?
You wouldnt sync all that to the player.
L386[13:49:53] <LexManos> Also, honestly
you could use this nutrition info to attach to all food items. In
the same generic way they way you can just be onEat:
player.getCap(nut).add(food.getCap(nut))
L387[13:50:44] <SquareWheel> I think I
need to fix up my current refactor before that one
L388[13:52:22] <SquareWheel> So your
thoughts are that I should keep the API as dumb as possible, and
handle complex things like syncing outside of capabilities?
L389[13:52:31] <LexManos> yes
L390[13:53:02] <LexManos> leave it up to
the implementor to decide if they ened to sync.
L391[13:53:03] <SquareWheel> Would let me
drop my custom implementation and not worry about any of this null
player stuff, so that works for me.
L392[13:54:37] <SquareWheel> Alright, I'll
play with that approach, thanks. Will find a logical place to put
the sync function.
L393[13:55:07] <SquareWheel> Most contexts
provide the player so I should be able to pass it in from
wherever.
L394[13:56:10] <ben_mkiv> yea thought of
mobs with diet, too. but that also needs some kind of custom diet
plans
L395[13:56:26] <ben_mkiv> cant feed a
bunny with raw meat
L396[13:56:43] <ForgeDiscord>
<JamiesWhiteShirt> not with that attitude
L397[13:56:45] <SquareWheel> Lot of ways
to approach it. Mob inventories, feeding via taming
L398[13:57:08] <LexManos> so cook the meat
first
L399[13:57:17] <ben_mkiv> do they eat
that? xD
L400[13:57:25] <SquareWheel> Maybe if
killer bunnies were still in the game
L401[13:57:26] <LexManos> and make sure
its other bunnies just to be even more disturbing
L402[13:57:59] <ben_mkiv> i think they
need soft meals because their gut works like a full fifo buffer
xD
L403[13:58:20] <LexManos> But ya, there is
a lot of ideas that you can do if you generic it out.
L404[13:59:41] <SquareWheel> It's
something I'd like to leave open for an addon mod.
L405[14:09:53] ⇦
Quits: Zethalion
(Zethalion!~Zethalion@095-097-058-227.static.chello.nl) (Read
error: Connection reset by peer)
L406[14:14:49]
⇨ Joins: Ipsis
(Ipsis!~Ipsis@82-69-71-184.dsl.in-addr.zen.co.uk)
L407[14:15:55] <ForgeDiscord>
<killjoy> fun fact. chickens are cannibles
L408[14:16:20] <ForgeDiscord>
<killjoy> if a chicken in the coop dies and the others are
hungry enough, they will eat it
L409[14:16:23] <ForgeDiscord>
<killjoy> eggs too
L410[14:17:53] <IoP> Actually if one
chicken is even bleeding there will be a death soon
L411[14:21:40] <gigaherz> well, birds are
the only surviving dinosaurs
L412[14:23:18] <gigaherz> "** Not
true you can have up to 7 valid instances."
L413[14:23:19] <gigaherz> well
L414[14:23:30] <gigaherz> one per side, +
null side, I guess you mean
L415[14:23:38] <LexManos> yup
L416[14:23:53] <gigaherz> I meant that you
can't do getAllCapabilities(ITEM_HANDLER, null); and get more than
one at once
L417[14:25:08] <gigaherz> if someone has
previously attached a provider that returns a capability for a
certain side, I can't attach another provider that responds to the
same capability
L418[14:25:33] <LexManos> did i ever
impelement that?
L419[14:26:30] <gigaherz> if you ever
implemented that, it never made it into the public repository
L420[14:26:49] <ForgeDiscord>
<JamiesWhiteShirt> I don't think it would make sense to do
so.
L421[14:27:00] <gigaherz> depends on the
case
L422[14:27:04] <gigaherz> thinking like,
Unity engine
L423[14:27:10] <gigaherz> most components
you can attach to a GameObject
L424[14:27:13] <gigaherz> are unique
L425[14:27:19] <gigaherz> but certain
things can be more than once
L426[14:27:23] <gigaherz> like
Collider2Ds
L427[14:28:35] <gigaherz> in the mc world,
I can imagine more than one mod interested in adding inventories to
an entity
L428[14:28:54] <ForgeDiscord>
<JamiesWhiteShirt> the capability could be designed in a way
that allows composition if this is desired
L429[14:29:05] <gigaherz> like right now,
there's no way to transparently enumerate the extra slots added by
mods into a player
L430[14:29:18] <gigaherz> if I want to
have a combined list of vanilla slots + baubles + other mod's extra
slots
L431[14:29:27] <gigaherz> I have to
explicitly support each of them myself
L432[14:29:58] <gigaherz> a
getAllCapabilities(IItemHandler) would be one possible solution for
that
L433[14:30:21] <gigaherz> but probably not
the best
L434[14:30:27] <LexManos> ya, not gunna do
that
L435[14:30:33] <LexManos> that just
complicates thing
L436[14:30:56] <gigaherz> yeah I get
that
L437[14:31:56] <gigaherz> so in this
specific case, an alternative might be to have a dedicated feature
for it, like an IExtraSlots capability, where mods can voluntarily
add their IItemHandlers, and then forge takes care of returning the
aggregate inventory when someone requests it
L438[14:32:26] <LexManos> maybe
L439[14:35:13] <gigaherz> ffs one of my
neighbours is doing something that is making rumbling noises, a bit
like an old HDD, but loud enough to hear it through the walls
L440[14:35:22] <gigaherz> it's getting on
my nerves
L441[14:39:01] <Ordinastie> am I the only
one who thinks that having the side passed in getCapability is the
wrong design choice ?
L442[14:39:01] ⇦
Quits: Ipsis (Ipsis!~Ipsis@82-69-71-184.dsl.in-addr.zen.co.uk)
(Ping timeout: 194 seconds)
L443[14:39:41] <SquareWheel> It's a bit
repetitive when working with non-block caps.
L444[14:39:45] <SquareWheel> So many
nulls
L445[14:40:05] <gigaherz> yeah but the
alternative would have been a ISidedCapabilityProvider specific to
TileEntities
L446[14:40:18] <SquareWheel> I don't know
if an overload makes sense for situations where it's not
relevant?
L447[14:40:37] <SquareWheel> eg. Default
to null unless specified
L448[14:40:38] <Ordinastie> I think the
cap implementations themselves should handle the sides
L449[14:40:57] <gigaherz> so you'd have
IItemHandler
L450[14:41:01] <gigaherz> and
ISidedItemHandler?
L451[14:41:07] <gigaherz> meh I prefer it
the way it is now
L452[14:41:13] <gigaherz> even if there
are some extra nulls around :P
L453[14:41:33] <gigaherz> it removes that
repetition from capabilities
L454[14:41:37] <Ordinastie> you could just
have the IitemHandler
L455[14:41:40] <gigaherz> sure
L456[14:41:57] <gigaherz> but you'd have
to be able to represent different slot counts and different slot
contents per side
L457[14:42:17] <gigaherz> so either you'd
have IItemHandler#getHandlerForSide(side) which returns another
item handler
L458[14:42:21] <Ordinastie> that's the
implementation's job
L459[14:42:38] <gigaherz> or you'd have a
hack like having ALL the methods in IItemHandler contain a side
parameter
L460[14:42:54] <gigaherz> no it can't be
the implementation's job
L461[14:42:59] <gigaherz> because the
point is it's generic
L462[14:43:14] <gigaherz> if it's the
implementation's job, how do I know where to indicate the
side?
L463[14:43:21] <gigaherz> it has to be
expressed in the interface
L464[14:43:32] <gigaherz> either I request
the inventory contents for a side
L465[14:43:51] <Ordinastie> yeah, by impl,
I mean the capability
L466[14:43:55] <gigaherz> yeah so
L467[14:44:03] <gigaherz> we go back to
how RF worked
L468[14:44:30] <gigaherz> the api had
canConnect(side), extractEnergy(side), insertEnergy(side),
...
L469[14:44:44] <gigaherz> IItemHandler,
would need canConnect(side), extractItems(side),
insertItems(side)
L470[14:44:53] <gigaherz> IFluidHandler
would also need canConnect(side), ...
L471[14:45:19] <gigaherz> since most of
the things a machine exposes are sided
L472[14:45:39] <gigaherz> you'll end up
having the same for most capabilities
L473[14:45:57] <gigaherz> may as well
factor that ouy
L474[14:46:14] <gigaherz>
hasCapability(side) + getCapability(side).extract/insert/...
L475[14:47:20] <gigaherz> the downside is,
as we have established, that this requires having some null
parameters for the cases where the side doesn't matter
L476[14:47:27] <gigaherz> I personally
prefer that.
L477[14:48:18] <gigaherz> and as
SquareWheel said, we could have overloads on the root objects --
Entity could have a getCapability(cap) {return getCapability(cap,
null); }
L478[14:49:12] <gigaherz> brb gotta
confirm I'm not going crazy
L479[14:49:16] ⇦
Quits: gigaherz
(gigaherz!gigaherz@33.red-83-55-9.dynamicip.rima-tde.net) (Remote
host closed the connection)
L480[14:49:36] <SquareWheel> If that
happened I'd gladly clean up my code to match. :)
L481[15:03:28]
⇨ Joins: gigaherz
(gigaherz!gigaherz@33.red-83-55-9.dynamicip.rima-tde.net)
L482[15:14:33] <ForgeDiscord>
<liach> can we just have a cap context
L483[15:17:48] <ForgeDiscord>
<SquareWheel> Let's try this Discord thing out
L484[15:21:10] <ben_mkiv> well different
mods can add their own inventory capability
L485[15:21:25] <ben_mkiv> so its possible
to have several inventories on one thing
L486[15:22:59] <LexManos> players have
sides
L487[15:23:10] <ben_mkiv> even if you
provide null
L488[15:23:29] <LexManos> even if you
provide null doesnt mean that they will respond with a cap
L489[15:23:56] <LexManos> You could ignore
null and only provide access to the plyers shoes when accessing
from DOWN
L490[15:25:06] <LexManos> You SHOULD NOT
send in null as yoiur sefault. You should actually send in the side
you're accessing from.
L491[15:25:21] <LexManos> your
default*
L492[15:34:18]
⇨ Joins: Dark
(Dark!~MrDark@2607:fcc8:d48b:eb00:f596:984:7c9e:d88a)
L493[15:59:09] <SquareWheel> Okay, think
I've finished my refactor.
L494[15:59:34] <SquareWheel> I came up
with a better, probably more obvious solution to the sync problem.
Just fake it on the client.
L495[16:00:02] <SquareWheel> I did use a
second implementation which inherits from the first to add
client-side syncing. Keeps the default impl nice and simple.
L496[16:00:51] <SquareWheel> And most
importantly, I renamed the silly class names.
L498[16:04:46] <SquareWheel> The real test
will be writing a small companion mod and seeing if they can
coexist peacefully.
L499[16:14:35] <SquareWheel> Just realized
the Capability is server-side only. My prediction won't work in
SMP.
L500[16:30:49] ⇦
Quits: ben_mkiv (ben_mkiv!~ben_mkiv@p5797266F.dip0.t-ipconnect.de)
(Ping timeout: 194 seconds)
L501[16:44:15]
⇨ Joins: Doty1154
(Doty1154!~Doty1154@c-73-189-164-179.hsd1.ca.comcast.net)
L502[17:07:02]
⇨ Joins: lp (lp!~lordpipe@66.109.211.167)
L503[17:25:23] ⇦
Quits: Noppes (Noppes!~Noppes@ip56530f2e.direct-adsl.nl) (Read
error: Connection reset by peer)
L504[17:36:02]
⇨ Joins: immibis
(immibis!~chatzilla@222-155-160-32-fibre.bb.spark.co.nz)
L505[17:39:13] ⇦
Quits: Nedelosk
(Nedelosk!~Nedelosk@ip-109-90-121-64.hsi11.unitymediagroup.de)
(Read error: Connection reset by peer)
L506[17:42:41] ⇦
Quits: Hanii
(Hanii!~textual@2a00:23c4:484:d100:6166:cc08:3b6e:68d3) (Quit:
Textual IRC Client: www.textualapp.com)
L507[17:52:15] ⇦
Quits: Fye (Fye!~Fye@146-241-16-181.dyn.eolo.it) (Quit:
Bye.)
L508[17:57:49] ⇦
Quits: SquareWheel
(SquareWheel!~SquareWhe@s0106f81d0f610653.ok.shawcable.net) (Quit:
Leaving)
L509[17:57:55] ***
Vaht is now known as Tahg
L510[18:05:50] ⇦
Quits: Javaschreiber
(Javaschreiber!~Thunderbi@88-209-32-73.nga.highspeed-baumann.de)
(Quit: Javaschreiber)
L511[18:10:32]
⇨ Joins: caseif_
(caseif_!~caseif@c-73-128-6-156.hsd1.md.comcast.net)
L512[18:16:00] ***
Santa|afk is now known as SatanicSanta
L513[18:28:08] <ForgeDiscord>
<killjoy> Is there an IDEA plugin for .patch files?
L514[18:56:00]
⇨ Joins: Hanii
(Hanii!~textual@2a00:23c4:484:d100:d595:c12:e369:24ec)
L515[19:33:24] ⇦
Quits: cjm721
(cjm721!~cjm721@2601:647:4200:18fc:8564:57ea:4338:e048) (Read
error: Connection reset by peer)
L516[19:34:45] ⇦
Quits: Wastl2 (Wastl2!~Wastl2@x55b656e1.dyn.telefonica.de) (Ping
timeout: 198 seconds)
L517[19:37:30]
⇨ Joins: Wastl2
(Wastl2!~Wastl2@x4db49163.dyn.telefonica.de)
L518[20:30:27] ⇦
Quits: Lupus590
(Lupus590!~Lupus590@cpc124520-swan5-2-0-cust53.7-3.cable.virginm.net)
(Ping timeout: 194 seconds)
L519[20:59:19] ***
SatanicSanta is now known as Santa|afk
L520[21:05:26] ⇦
Quits: Twisted_Code (Twisted_Code!~macks2008@dusky.horse) (Quit:
ZNC 1.7.x (http://znc.in) quit: disconnected from
ZNC)
L521[21:09:24] <moony> How do you animate
an item's sprite?
L522[21:11:26] <ForgeDiscord>
<killjoy> by using metadata
L523[21:11:31] <ForgeDiscord>
<killjoy> *.mcmeta
L526[21:12:42] <ForgeDiscord>
<killjoy> see
assets/minecraft/textures/blocks/water.png.mcmeta
L527[21:13:09] <moony> thanks
L528[21:26:43]
⇨ Joins: Twisted_Code
(Twisted_Code!~macks2008@dusky.horse)
L529[22:14:12]
⇨ Joins: mezz (mezz!~mezz@24.6.28.151)
L530[22:14:12]
MineBot sets mode: +v on mezz
L531[22:18:47] ⇦
Quits: moony (moony!~moony@tx-76-4-56-242.dhcp.embarqhsd.net) (Ping
timeout: 194 seconds)
L532[22:21:25]
⇨ Joins: auenfx8 (auenfx8!~David@110.150.99.123)
L533[22:22:06] ⇦
Quits: auenf (auenf!~David@110.150.99.123) (Read error: Connection
reset by peer)
L534[22:37:24]
⇨ Joins: auenf (auenf!~David@110.150.99.123)
L535[22:37:25] ⇦
Quits: auenfx8 (auenfx8!~David@110.150.99.123) (Remote host closed
the connection)
L536[22:50:31] ⇦
Quits: Lathanael|Away
(Lathanael|Away!~Lathanael@p54960EED.dip0.t-ipconnect.de) (Ping
timeout: 202 seconds)
L537[22:51:48]
⇨ Joins: Lathanael|Away
(Lathanael|Away!~Lathanael@p54960FA8.dip0.t-ipconnect.de)
L538[22:57:54] ⇦
Quits: Doty1154
(Doty1154!~Doty1154@c-73-189-164-179.hsd1.ca.comcast.net) (Read
error: Connection reset by peer)
L539[22:58:30]
⇨ Joins: Doty1154
(Doty1154!~Doty1154@c-73-189-164-179.hsd1.ca.comcast.net)
L540[23:48:03] ⇦
Quits: caseif_ (caseif_!~caseif@c-73-128-6-156.hsd1.md.comcast.net)
(Ping timeout: 194 seconds)
L541[23:51:39]
⇨ Joins: quadraxis
(quadraxis!~quadraxis@cpc77295-basf12-2-0-cust599.12-3.cable.virginm.net)