Mount point limit.

#1 It's not so easy to change that number :) ShapeBase reserves 1 bit for every mounted image in the ghost update mask. That mask is U32, and already filled to max. If you are going to increase the number of mountpoints, you'll have to change the way the ShapeBase tracks it's ghost update mask for mounted images. The masks are declared in ShapeBase.h, the ShapeBaseMask enum. ImageMaskN is the start of the image range.

#2 Doh, I'm confused now.

Whenever I program, I make things as dynamic as possible. I'll go out of my way, and take the extra time to make things easily changable.

The terrain size, for instance, I would've made a variable, so it could be changed in three seconds, instead of three days.

I assumed the mountpoints were like that, but I guess not.

Anyway, I'm having problems. Getting an access violation whenever I execute a player datablock. So, I'm going to shove the engine to the side and wait for the update before I continue, then I'll merge my changes and try the mountpoint thing again.


Dark

BTW, I'm a vb programmer. I'm still learning C++.

#3 I thought terrain size was a single variable? (except for the water, not sure why that's hard-coded). Flexibility in general is good :) but the networking layer only has a single 32 bit ghost update mask, the mounted images had to fit in there along with everything else. Having a 32 bit mask was a network bandwith issue, makeing that flexible just encourages people to send more data then they should ;)

#4 Is it a single variable? I may have opened my big mouth too soon :) I looked at it, but not long enough I guess. By terain size I meant number of tiles, not tile size. I'll check it out again later.

That made me even more confused :)

I have a bunch of questions now.

1.) How would I change it from 32 bits to something else? What file(s) would I edit.

2.) Does it have to be a power of two? Can I change it to whatever I want, or does it have to be 64?

3.) Does everything in there have it's own special index, or is it all just queued dynamically?

4.) If some bits are unused, do they stil take up bandwidth, or are they just not sent?


I don't know how much sense these questions make, I don't know all the correct terms yet. I may have misunderstood you in some places.


Dark

#5 Oh, also...

I might have assumed the terrain was hard coded, because the water was. I was checking the water out when I changed the terrain tile size and the water got all those holes in it. I did a quick hack on that, instead of taking the time to go through and do it right.


Dark

#6 @ Chris

How exactlu did you do a quick hack regarding the holes in the water.
I got those too I would really like to get rid of them untill a real fix is made.

// Clocks out.

#7 The water was written later, and the terrain size of all the missions was 8, so I guess whoever wrote it just hardcode that value (very lame). There is only a single repeating tile though, both on the terrain and the water. That's not so easy to change.

Changing the net ghost mask to other than it's current 32 bits would be quite a bit of work. A simpler solution would be to change the way the ShapeBase object tracks image state changes, maybe a single bit for all images, or a single bit for every eight. Something along those lines as opposed to the current single bit for each image.

Every object grabs bits out of the ghost mask, these are defined at compile time. Each bit represents a state that the object wants to transfer to it's ghosts on the clients.

#8 In waterBlock.cc, under WaterBlock::prepRenderImage() comment out the if statement right after the line "// Attempt to get the terrain."

What it appears to do is check for collision with the terrain, since the water block is using tile size 8 no matter what the terrain is using, it thinks the terrain is smaller than it really is. So, it doesn't render the tiles that it thinks are colliding. This just bypasses that and makes the whole waterBlock solid.

It's kind of cool though, with this I don't think it'd be very hard to make an underwater base with air in it. You just have to position the waterblocks right.


Dark

#9 I still have a lot to learn, Tim :) I don't know enough C++ yet to change what needs to be changed. I can do some semi-complex things with the gui's, but networking, and other atvanced protocall are beyond me. Hopefully not for too long though.

I learn more and more every day. I should be able to figure it out within a few weeks - hopefully :)


Thanks for your help.


Dark

#10 Yup that worked fine for now.
But I still want a real fix for this as this quick hack might create unneeded extra polys.

Thx.

// Clocks out

#11 Yeah, it does.

Once I figure out how to update the v12, I'll merge my game's changes, then I'll make a better fix for this. I'll make it use the terrain tile size variable, instead of the hardcoded 8.


Dark