Re: netchan - type mismatch
The Vec3 object is actually one of our own types and it just has 3
float64's in it.
type Vec3 struct {
X, Y, Z float64
}
I've pretty much laid out all of the different types in those two
Trace__ structs and it doesn't appear that any of them have interfaces
in them. Any other ideas?
On Jun 1, 1:41 am, Daniel Smith <dan...@...> wrote:
> Embedded *structs* wouldn't be a problem. An interface {} typed field
> somewhere (I'm guessing in Vec3, if it's based on the container/vector
> package) could do it.
>
>
>
>
>
> On Tue, Jun 1, 2010 at 2:18 AM, Skandocious <skandoci...@...> wrote:
> > Whoops you're right-- I meant to show the declarations for the
> > structs.
>
> > type TraceJob struct {
> > octree Octree
>
> > x1 int
> > y1 int
> > x2 int
> > y2 int
>
> > diffuseEnabled bool
> > MAXDEPTH int
> > lightI Point
> > camI Point
>
> > delta DeltaStruct
> > camera Point
> > ntl Point
> > t Texture
> > }
>
> > type TraceResult struct {
> > x int
> > y int
> > rgb Vec3
> > }
>
> > If I'm understanding you correctly-- you're saying that there is not
> > support for encoding/decoding a struct that contains other structs
> > inside of it? These two structs were made specifically to accomodate
> > our new model that uses net channels. The TraceJob struct is basically
> > just a collection of all context necessary for the client to trace the
> > chunk that is given to it. As you can see, it contains several structs
> > within it. A Point object has 3 float64's (x,y, and z coordinates), a
> > DeltaStruct has 6 float64's, a Texture has an int and a byte[].
>
> > So do I just need to decompose those struct objects into basic types
> > and have a buttload of items in that struct? lol
>
> > On Jun 1, 12:03 am, "Rob 'Commander' Pike" <r...@...> wrote:
> > > You left out the most important piece of context, but there's enough here
> > to diagnose it.
>
> > > You don't show the types you're putting in the channels, TraceJob and
> > TraceResult. I presume they're both structs. One of them, probably
> > TraceJob, looks like it has a field of type interface, which the gob encoder
> > can't handle. It needs to send a statically typed value; it can't handle a
> > dynamically changing type inside the structure.
>
> > > It's arguable that the gob encoder should ignore the field rather than
> > complain about it, but as a workaround, copy the data to a variant struct
> > without the interface field for transmission.
>
> > > -rob
>
> --
> Daniel Smithhttp://www.schaumburggoclub.org/