[conquest] invisible sun / much to visible sun, final fix (damn it I hope!)

[Jon Trulson]

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 at radscan.com
ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962
PGP keys at http://radscan.com/~jon/PGPKeys.txt
#include <std/disclaimer.h>
"I am Nomad." -Nomad