for some reason when I host the game, the 3dos are all lined up well.. but when I JOIN a game, they are all slightly slanted on their axis? HOW CAN I STOP THIS FROM HAPPENING?

Heh, I had a similar problem years ago. So did MaDa in one of his levels. I don't think we ever figured out why, but we did fix it. I wrote a COG which set the PYR to what they were supposed to be at level startup (specified in JED). I suppose you could do something similar, but that would be cumbersome with the number of 3DOs you have. Maybe just syncThingState() would work.

would you mind writing one up for me?

Fun. Another mystery. Please email me the troublesome gob or jed project files; I would like to play around with them to find out what causes this problem.

zeqmacaw jkhub.net

Thanks,

DM_Diamond did the same thing. I worked around it by merging the 3do's that were giving problems. I think it has to do with weird rounding errors when rotating or something.

well, all the 3dos are doing it, and there must be over 300 3dos already... i don't think merging will be an option.. with out horrible extensive "re-layering"

Eh, re-layering won't mean anything if you merge them.

Your best bet is to set them up as if you were going to merge them. You'll have to do extensive relayering, sorry, that's the price we pay for editing JK. Then export the whole damn thing as one 3do. It'll be a lot of hard work now, but trust me, it'll save you loads of time down the road.

My best advice before you get started is to consolidate the single section 3do to as few layers as possible. If you need someone to do this pain staking task, you can send it to me and I'll be more then happy to do it for you. I've got a lot of free time at work. I highly recomend doing as much consolidating in surfaces & vertices AND THEN consolidate as many layers as possible in each section. Then, texture the single sections before sending it to me to create the final 3do.

Merging the 3DO also has performance implications, since JK's 3DO visibility calculations aren't very intelligent. There's a better way to fix this. Don't merge.

umm.. ok... what's the better way to fix it?

Not to merge. There's no way you could and it still render anyhow due to the surface count. You'd end up recleaving anyhow.

If you want, send me the individual sections. I will optimize it by merging and recleaving the surfaces to reduce surface and vertex counts and reducing the number of layers per model. Then I'll send it back to you for texturing. When you complete the texturing, send it back to me and I'll recreate the entire colosseum out of the sections and export it as one 3do and send it back to you.

I guess what you could do is create a class cog for the 3dos (a cog attached to the template) and have the class cog send a "sendmessage" to the master cog in your level with data about the 3do (id and such) and have the master cog set the position of the 3do.

i dont know how to cog, somebody would have to send me one.. (I don't want to have the 3dos edited by someone else if I can avoid it..)

lucky i'm not dead yet eh?

i'm thinking i can devise a nice math formular for the thing placement then simply have the cog run through the level and apply it. it will take some rather large alterations to the level, but should work

Er, what? All he needs to do is properly sync the positions of the 3DOs. A simple syncThingState() might even work. If not, a class COG as SavageX described will work.

I think I understand why it happens. When you host a game, the thing pyr values are loaded from the JKL. This may or may not happen in joining. But in joining, it's been seen that all the things currently in the level are synced, using information sent from the host. When they are being synced, the information being sent is likely less accurate than the information being stored in the .jkl, leading to minor errors. How to fix, yeah... well, HR's method is probably the best actually, not easy, but would probably work the best in general.

will someone PLEASE GIVE ME A COG!

well my networks down at the moment so i cant test if syncing it would work. and i seriously doubt it would, if there is a rounding error when things are synced at joining, i dont see any reason why they wont have the same rounding errors when syncing later.

But considering all of his level's 3do's are obviously placed in a perfect cricle, i dont see any reason why i cant simply use the circle formular and basic trig to align all the 3do's at once...

as for spiral, unless anyone else get's their first, work on the lab or something while i fix this up...

and they said cogging was easy.. meh, clients arn't lol!

The only way it would be less accurate is if data was lossed during transmition, and that would mean the devs used UDP to sync critical information, which is something dumber than I think even the JK devs would have done. It would also mean different errors each time. I think this highly unlikely, especially considering the rest of us have been playing hundreds of levels for the past 8 years without a hitch. It seems to be something with particular 3DOs.

Agreed, the pyr offset is too consistant between 3do's for it to be "chopped" data errors.

You know, it is possible that, while making minor tweaks after aligning the 3do's, Spiral inadvertantly adjusted the roll value of the 3do and re-exported it without realizing he had done so. And, since the JED 3D preview isn't all that great at updating resources...

Spiral, I'm assuming you've completely shut down JED AND your computer since this problem first occured? If not, you should do so and see if that either resolves your problem or updates the JED Preview revealing the same error.

But he said that it was oriented properly on the hosts computer...
It has to be some sort of client issue. I could take a look at this sometime if you can upload either it, or a testing level with the same problem.

Indeed, it works fine on the host computer. I encountered this problem with the first Space Noxx and I fixed it by brute force. Just had a COG that set the position and PYR of a thing to what I wanted, defined in JED. But that doesn't look too feasible for Spiral. Certainly tedious. MaDaVenter had the same problem in that tropical island saber level he made. I helped him fix it with the same method.

I'm not even sure why Spiral's level is all 3DOs and not a mix of 3DOs and architecture. It's far more efficient.

They arn't... they are in an elpisis shape

Wasuuuuuuuup Spiral.

I won't get your hopes up, I have never fixed this problem before, but I am familuar with it (Asylum of Mortality also has this glitch). I'll just share what I know. Confirm some things, hopefully bring a couple of new facts out, and maybe lead to somebody solving this crap.

* This error is only visible to clients.
* Degree of rotation is too consistant to be random rounding error.

I haven't done enough testing to say for certian, but I am GUESSING that there has to be a large number of 3do's for this error to happen (somebody test this!).

I don't know WHY the error happens at all, but I have a gut feeling it has to do with the translation of PYR to LVecs.

Btw, setting the LVec of all the 3do's to straightin them SHOULD work fine, and if the only component of the PYR your models use is the YAW, you should be able to flatten their LVec very easily with no other reference object. If I can't figure out a better way to fix this with Zeq and them, I'll write up a quick cog that guy could add to his cog that would flatten out the pitch/roll of your 3do's on startup.

Nope. Despite being made of all 3DOs, Space Noxx and MaDa's tropical island level had very few things.

I *KNOW* setting the values with COG, via JED, works. It would just be very tedious for Spiral's level.

just finished the down load this morning, yeah not a circle.. i've written a nice cog that should sync it manuley (did this for AI once) testing it with solid_snake now.

well i tested the cog... it was client server and ran off the things templated.. eg created message, send thing P Y R via a trigger to a master client cog, set the thing PYR etc...
and it's worked, but it only reduced the tilt slightly. not fixed it.. this ones really odd.. but that proves it's not a rounding error.