Wireless bridge multiparts could be 2 pixels thick.

[ElvishJerricco]

Instead of 3. Even though modems are 3 thick, they're fine because when they intersect, they don't look like they're z-fighting because they're the same color. When modems and brides intersect, they do look like they z-fight. Also I just think these kinds of multiparts look better when they're 2 thick.

[SquidDev]

This would be trivial to implement, though I do think we should do this to all wired modems, not just multipart ones, otherwise conversion doesn't look very seamless. I do kinda like the yellow and black strips on the wireless bridge multipart, but apart from that I have no objections.

[SquidDev]

@ElvishJerricco: I'm probably going to release 0.2 now, so do you have any thoughts on this?

[SquidDev]

Still not convinced about this.

[ElvishJerricco]

This z-fight is the main reason I consider this an issue.

[SquidDev]

I know, I'm not sure I how we would fix it though. If we change it to 2px on everything, then normal modems will look different to wireless modems. But if we only change it on multiparts then there won't be a seamless transition when converting them. However if we keep it you get z fighting.

[ElvishJerricco]

We can just change the wireless bridge though. We don't have to change CC modems.

[SquidDev]

I guess we could just change the wireless bridge. That works, though it may look a bit odd with them 2px modems 3px.

[ElvishJerricco]

Eh. I don't think that's all that bad of a consequence. They're different things. They're allowed to look different.

[SquidDev]

I'll do it tonight then, trying to get some work done on Tua but making little progress. :frowning:. How is CCTransport going?

[ElvishJerricco]

Making progress! I have some awesome framework behind simple repetitive tasks like the IPartFactory and IPeripherals. I actually wrote a dev blog about the multipart aspect. Planning to write more for the remaining bits like rendering and peripheral defining.

So now I've got a part rendering with an obj model and some precalculated Transformations. The SinglePeripheralModem from CC-Tweaks was a nice convenience in making the multipart node behave as a peripheral. Now it's just the trivial matter of actually making the proper peripheral methods. I'm having trouble deciding on the API for the part I'm working on. Essentially trying to serialize/deserialize in and out of inventories, but I'd rather avoid using the slot system. Instead I'd like just the ability to "insert" and "extract" without concern for slots. But maybe I'll have to concede and just provide a slot-based peripheral.

[SquidDev]

It looks cool! I had a go at this tonight, but had some issues where textures would be reversed. I might have to write a custom renderer using tessellators. TBH I'm probably going to include multipart modems too as they use so much of the same code (PartSidedNetwork).

[ElvishJerricco]

Dev blog #2! Posting this here because it might actually be relevant to this issue. I think the technique I used could be used to make different parts have different dimensions with ease.

[SquidDev]

Ooooh, those look good. Why blender rather than Techne though? Whilst I'm not sure I want modems to have bevelled edges, those do look really nice! I think for modems, a proper renderer is the way to go, though I'm going to have to sit down and do a good job on it sometime.

[ElvishJerricco]

Well partly it's because Techne doesn't have a mac version, and I don't think the web version works. But mostly it's that blender is a vastly more powerful tool that's more applicable in the rest of the field.

[ElvishJerricco]

But yea the idea for this issue in particular is that parts like modems and bridges can easily separate their boxes by using common rotation transformations instead of common vertices for all parts in all rotations.

[SquidDev]

Closed in #80