[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [conquest] invisible sun / much to visible sun, final fix (damnit I hope!)
- To: Almighty Tallest Cataboligne <god.000@xxxxxxxxx>
- Subject: Re: [conquest] invisible sun / much to visible sun, final fix (damnit I hope!)
- From: Jon Trulson <jon@xxxxxxxxxxx>
- Date: Mon, 17 Oct 2005 18:33:53 -0600 (MDT)
- Cc: Conquest <conquest@xxxxxxxxxxx>
- In-reply-to: <c01fae2f0510171331x2abeb9efmbd606528352629a0@mail.gmail.com>
- References: <c01fae2f0510171331x2abeb9efmbd606528352629a0@mail.gmail.com>
- Reply-to: jon@xxxxxxxxxxx
- Sender: owner-conquest@xxxxxxxxxxx
On Mon, 17 Oct 2005, Almighty Tallest Cataboligne wrote:
Jon
Dude :-0
(complimentary reference to baskeballs)
heh
CC'd to conquest list.
I've gone back to 8.1.1 source and I cant get the damn visibility to toggle.
Dont try it out, I found it...broke the client code indeed.
Except you were doing the "breaking". (rather not fixing completely!)
I never make mistakes, only my computers do. :)
diff -b conquest-8.1.1-0/client.c conquest-8.1.1/client.c
387c387
< if (primary <= 0 || primary > NUMPLANETS)
---
if (primary < 0 || primary > NUMPLANETS)
/* in protocol 6, we 'forgot' planet realness. To avoid breaking
protocol again, and allow unpatched clients and/or servers to
work we check to see if SPPLANETINFO_FLAGS_FVALID is set. If so,
_then_ we pay attn to any other flags present. Else we ignore
them. */
Ahh... the original authors did this (well not the protocol, but):
planet/primary == 0 is invalid, but they did it anyway for Mur's case it
seems.
This is a consequence of the original developers (ab)using int to
differentiate between a ship and a planet (mainly for messaging) by
'sign'. Also, ratfor apparently did not index arrays starting at 0, they
used 1, and the code assumes that. So they must have figured a 0 primary
was impossible, and therefor irrelevant. The protocol didn't even
consider this. Those bastards. :)
So the end result is that server changes to Mur will never be
propagated to a client.
Was thinking about getting away from that anyway and going with an
'object type/id number' method of identifying objects. 'Ship 4', 'Planet
27', or 'stargate 5' rather than the current <0 == planet, >0 == ship,
etc...
Another reason to do these changes I guess.
yes, and 0 is a valid value for primary.
Yes, and no. It can be represented as a '0' in the code (now),
but the game code itself would never have been able to access it (ratfor
limitation I guess). Of course we're in C now. 0 does exist! :)
I had considered fixing this during the original ratfor -> C port,
but the assumption was so ingrained in all the code, I kept it. Time to
change it I guess. What fun that will be! :)
the client was setting murisak to visible, and it never got updated from the
server.
my new changes left it not visible for the client because...well I'm
assuming it was the dostand = TRUE, but since it seems to work ok, I'm not
going to find out.
I'll need to address this in the next major version (and what a
major version it's looking to be (common block/protocol wise):). That's
why I mentioned that the New Version (NV) would hardcode a ghost0 planet
at 0,0 on which to afix the universe. At that point, we will have to
allow planet == 0 as well (but it will be special - immutable).
--
Jon Trulson mailto:jon@xxxxxxxxxxx
ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962
PGP keys at http://radscan.com/~jon/PGPKeys.txt
#include <std/disclaimer.h>
"I am Nomad." -Nomad