[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Here are some of my comments
----- Original Message ----- From: "Jon Trulson" <jon@xxxxxxxxxxx>
To: "Almighty Tallest Cataboligne" <god.000@xxxxxxxxx>
Cc: "Conquest" <conquest@xxxxxxxxxxx>
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@xxxxxxxxxxx ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962 PGP keys at http://radscan.com/~jon/PGPKeys.txt #include <std/disclaimer.h> "I am Nomad." -Nomad