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

[John Clute]

Here are some of my comments
----- Original Message ----- 
From: "Jon Trulson" <jon at radscan.com>
To: "Almighty Tallest Cataboligne" <god.000 at gmail.com>
Cc: "Conquest" <conquest at radscan.com>
Sent: Monday, October 17, 2005 6:33 PM
Subject: Re: [conquest] invisible sun / much to visible sun, final fix (damn 
it I hope!)


> 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...
>
I agree here.

>  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! :)
>

True....

>> 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
>
>