From god.000 at gmail.com Sun Oct 2 19:55:30 2005 From: god.000 at gmail.com (Almighty Tallest Cataboligne) Date: Mon, 3 Oct 2005 01:55:30 +0000 Subject: [conquest] Conquest 8.1.1 (stable) is now available In-Reply-To: References: Message-ID: > Version 8.1.1 (stable) ah, to have the time. help, help, my times been stolen... (no, no wait, thats being repressed.) - can see the negative energy barrier now in the GL client. isnt part of the fun having to figure it out without seeing it? (hope you sampled TOS footage for this...) anyone up for a game of lords of conquest, or maybe archon 2? currently experimenting with atari800win - only emu I could find that has network support. welcome any offers to help playtest. Cataboligne "When keeping it real goes wrong" - see season 2 Chappelle show. 3 4 | 2 \|/ 5--*----> 1 Thing is facing this direction /|\ 6 | 8 7 -------------- next part -------------- An HTML attachment was scrubbed... URL: From god.000 at gmail.com Wed Oct 5 21:13:17 2005 From: god.000 at gmail.com (Almighty Tallest Cataboligne) Date: Thu, 6 Oct 2005 03:13:17 +0000 Subject: [conquest] Conquest 8.1.1 (stable) is now available In-Reply-To: References: Message-ID: > Version 8.1.1 (stable) > > - can see the negative energy barrier now in the GL client. > > well I did a make install and Initialized everything, but I get no barrier graphics. any kind of flag control that? Cat. ---------------------------------------------- 3 4 | 2 \|/ 5--*----> 1 Thing is facing this direction /|\ 6 | 8 7 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at radscan.com Wed Oct 5 22:14:00 2005 From: jon at radscan.com (Jon Trulson) Date: Wed, 5 Oct 2005 22:14:00 -0600 (MDT) Subject: [conquest] Conquest 8.1.1 (stable) is now available In-Reply-To: References: Message-ID: On Mon, 3 Oct 2005, Almighty Tallest Cataboligne wrote: >> Version 8.1.1 (stable) > > > ah, to have the time. > help, help, my times been stolen... > (no, no wait, thats being repressed.) > :) I feel you pain. I miss the phaser. Yes. The mighty phaser. > - can see the negative energy barrier now in the GL client. > > > isnt part of the fun having to figure it out without seeing it? > (hope you sampled TOS footage for this...) Well in the curses client there was no choice. You couldn't see enemy phasers in the curses client either... It's 2005. Enemy phasers and negative energy barriers are 'in' now. It's the new black. > > anyone up for a game of lords of conquest, or maybe archon 2? > currently experimenting with atari800win - only emu I could find that > has network support. welcome any offers to help playtest. > Hmm. Don't know any of those... hehe > Cataboligne > > "When keeping it real goes wrong" - see season 2 Chappelle show. > > 3 > 4 | 2 > \|/ > 5--*----> 1 Thing is facing this direction > /|\ > 6 | 8 > 7 > -- Jon Trulson mailto:jon at radscan.com ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962 PGP keys at http://radscan.com/~jon/PGPKeys.txt #include "I am Nomad." -Nomad From jon at radscan.com Wed Oct 5 22:15:12 2005 From: jon at radscan.com (Jon Trulson) Date: Wed, 5 Oct 2005 22:15:12 -0600 (MDT) Subject: [conquest] Conquest 8.1.1 (stable) is now available In-Reply-To: References: Message-ID: On Thu, 6 Oct 2005, Almighty Tallest Cataboligne wrote: >> Version 8.1.1 (stable) >> >> - can see the negative energy barrier now in the GL client. >> >> > > well I did a make install and Initialized everything, but I get no barrier > graphics. > any kind of flag control that? > Well you'll only see if if you have viewerbg enabled... This is usually the default, unless you had previously installed an earlier version and disabled it... > Cat. > > ---------------------------------------------- > 3 > 4 | 2 > \|/ > 5--*----> 1 Thing is facing this direction > /|\ > 6 | 8 > 7 > -- Jon Trulson mailto:jon at radscan.com ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962 PGP keys at http://radscan.com/~jon/PGPKeys.txt #include "I am Nomad." -Nomad From god.000 at gmail.com Fri Oct 14 22:15:52 2005 From: god.000 at gmail.com (Almighty Tallest Cataboligne) Date: Sat, 15 Oct 2005 04:15:52 +0000 Subject: [conquest] other game tie ins. Message-ID: Well, its probing day and Cataboligne (thats me!) is here with another pummeling...er no wait, just a bit of info. I dont know about anyone else, but some games just went together for me. While conquest was on the university VAX, pinbot was in the student union. (along with high speed, miami heat, and a couple others that changed - fire! and taxi for a bit.) Those days are gone, but many of the games live on thanks to mame. So do the pinball games...sort of. Look here: http://www.vpforums.com/vptables/tables.php everything you need to play reasonable simulations! (at a minimum, you need vpinmame, visual pinball, the latest fonts, vbs scripts, plus the virtual table(s) and rom(s) for your game of choice.) There was nothing quite like wasting a few hours stealing a conquer from the orions and then hitting the student union to swipe thru a couple solar systems with pinbot. Why not see if your old favoite is there? ---------------------------------------------- 3 4 | 2 \|/ 5--*----> 1 Thing is facing this direction /|\ 6 | 8 7 -------------- next part -------------- An HTML attachment was scrubbed... URL: From god.000 at gmail.com Mon Oct 17 00:20:10 2005 From: god.000 at gmail.com (Almighty Tallest Cataboligne) Date: Mon, 17 Oct 2005 06:20:10 +0000 Subject: [conquest] what?! an invisible sun that kills? Message-ID: urk...I changed the subject and to fields on this...sometimes gmail seems to go astray. On 10/17/05, Almighty Tallest Cataboligne wrote: > > Jon > > LOL - just logged in to your 1701 server and saw the conquer msg "No beach > > to walk on" > > > > I think this server has some serious issues...unless you have sneakily > changed some code? > > Information on: mur > I don't understand. > > You were killed by Murisak's solar radiation. > > So, how are you killed by something that isnt there? > I wasnt aware of any invisible sun bug...hmm, I never have tested for > that. > ---------------------------------------------- 3 4 | 2 \|/ 5--*----> 1 Thing is facing this direction /|\ 6 | 8 7 -------------- next part -------------- An HTML attachment was scrubbed... URL: From god.000 at gmail.com Mon Oct 17 01:08:10 2005 From: god.000 at gmail.com (Almighty Tallest Cataboligne) Date: Mon, 17 Oct 2005 07:08:10 +0000 Subject: [conquest] invisible sun bug discovered! Message-ID: > So, how are you killed by something that isnt there? > > I wasnt aware of any invisible sun bug...hmm, I never have tested for > > that. > > > There is in fact some issue here. It seems you can go in conqoper and make any planet object invisible and then visible again...except Murisak! You do that to murisak and it never reappears. In either client. Nor can you get info on it anymore - but its rad. can kill you! This is wacked out. Further research - I mucked around with murisaks orbit pointer. If you point it at something orbiting it, the whole universe takes off. must be something to do with self references. I set it to orbit sol, which doesnt move. After I restored it to orbit itself, and returned its x,y to 0,0 its visible switch works normally. A planet init doesnt change the status of the situation in any way shape or form...I'd bet init everything would though. This is for sure some odd ball code. Also checked a sun having 0 army count - it can do damage sometimes. but it seems your shields can regen. faster sometimes too. More research - it is definitely tied into to the orbit pointer. If you init the planets murisak never reappears after you make it invisible, but its rad will function. But if you set its orbit pointer (to itself, as it defaults) then the (in)visible switch works normally. ---------------------------------------------- 3 4 | 2 \|/ 5--*----> 1 Thing is facing this direction /|\ 6 | 8 7 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at radscan.com Mon Oct 17 12:08:28 2005 From: jon at radscan.com (Jon Trulson) Date: Mon, 17 Oct 2005 12:08:28 -0600 (MDT) Subject: [conquest] invisible sun bug discovered! In-Reply-To: References: Message-ID: On Mon, 17 Oct 2005, Almighty Tallest Cataboligne wrote: >> So, how are you killed by something that isnt there? >>> I wasnt aware of any invisible sun bug...hmm, I never have tested for >>> that. >>> >> > There is in fact some issue here. > > It seems you can go in conqoper and make any planet object invisible and > then visible again...except Murisak! > Interesting. Murisak is special in that is it really 'the center' of the universe. In the upcoming CB changes we've been discussing offline, I will probably use a ghost planet to be the center. Murisak will then just orbit ghost 0 at a 0 radius and 0.0 orbital velocity. Ghost 0 will be hardcoded to be at 0,0 with 0 vel, 0 radius, and invisible. I am curious about your statement that Murisak is invisible on my 1701 and 1702 servers... This is not true. Have you tried using a client (virgin 8.1.1) rather than the client you modified for the irken planets? I suspect you may have introduced a bug somewhere with your changes. > You do that to murisak and it never reappears. In either client. Nor can you > get info on it anymore - but its rad. can kill you! This is wacked out. > It is possible that an invisible Sun with a non-0 army count could kill you. I've never tried it, but should be easy to fix. Suns are different from planets in that it's army count determines the damage one causes without regard to your team. There may be a logic hole in there somewhere. > Further research - I mucked around with murisaks orbit pointer. If you point > it at something orbiting it, the whole universe takes off. must be something > to do with self references. I set it to orbit sol, which doesnt move. After > I restored it to orbit itself, and returned its x,y to 0,0 its visible > switch works normally. Well as Mur is basically the center of the universe, all of the other star systems are specified relative to it, but usually with a 0.0 orb vel. (ie the team systems 'orbit' mur at a specified orbital radius, but with no velocity - hence they stand still). On the 1702 server, I set all of the star systems actually orbiting mur, so as to provide continually changing team system locations :) I have never tried having a body orbit itself with a non-0 vel/radius. I can see how this would cause some strange orbits. :) > > A planet init doesnt change the status of the situation in any way shape or > form...I'd bet init everything would though. > > This is for sure some odd ball code. > :) > Also checked a sun having 0 army count - it can do damage sometimes. but it > seems your shields can regen. faster sometimes too. > If you orbit a 0 army sun, your sh and temp should regen faster - as if you were orbiting an empty planet. I would not think you could get any damage though as the army count determines that (or at least it is supposed to). > > More research - it is definitely tied into to the orbit pointer. If you init I am not sure what you mean by 'orbit pointer'... perhaps you mean the 'primary'? A planet always has a primary - the body it orbits. > the planets murisak never reappears after you make it invisible, but its rad > will function. But if you set its orbit pointer (to itself, as it defaults) > then the (in)visible switch works normally. > It is possible invisible suns could still cause damage - never tried it, but I cannot recall anything in the code checking for this condition. The visibility of the object should not have anything to do with a body's primary. Mur 'orbits itself', but with a 0 orbit radius and 0 orbit velocity - which means it just stands there. I have never tried a body that orbits itself with a non-0 orbit velocity or radius. Wish I were home, would like to try that now :) -- Jon Trulson mailto:jon at radscan.com ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962 PGP keys at http://radscan.com/~jon/PGPKeys.txt #include "I am Nomad." -Nomad From jon at radscan.com Mon Oct 17 12:12:16 2005 From: jon at radscan.com (Jon Trulson) Date: Mon, 17 Oct 2005 12:12:16 -0600 (MDT) Subject: [conquest] what?! an invisible sun that kills? In-Reply-To: References: Message-ID: On Mon, 17 Oct 2005, Almighty Tallest Cataboligne wrote: > urk...I changed the subject and to fields on this...sometimes gmail seems to > go astray. > > On 10/17/05, Almighty Tallest Cataboligne wrote: >> >> Jon >> >> LOL - just logged in to your 1701 server and saw the conquer msg "No beach >>> to walk on" >>> HEhe... I doubt many people will get that these days. >> >> I think this server has some serious issues...unless you have sneakily >> changed some code? >> I never sneakily change code - I don't like surprising my customers :) >> Information on: mur >> I don't understand. >> This is done locally - client side. >> You were killed by Murisak's solar radiation. >> >> So, how are you killed by something that isnt there? This is done/enforced server-side. >> I wasnt aware of any invisible sun bug...hmm, I never have tested for >> that. You got this on my server(s)? I think you broke your client with those changes you made. Try a virgin 8.1.1 client (or the telnet interface if you must go retro). -- Jon Trulson mailto:jon at radscan.com ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962 PGP keys at http://radscan.com/~jon/PGPKeys.txt #include "I am Nomad." -Nomad From god.000 at gmail.com Mon Oct 17 12:44:49 2005 From: god.000 at gmail.com (Almighty Tallest Cataboligne) Date: Mon, 17 Oct 2005 18:44:49 +0000 Subject: [conquest] what?! an invisible sun that kills? In-Reply-To: References: Message-ID: > > You got this on my server(s)? I tested it locally on my server (the custom code) - same thing. I think you broke your client with > those changes you made. Try a virgin 8.1.1 client (or the telnet > interface if you must go retro). didnt think of this...looks to be the case. the only place it could happen is in the clbinitplanets. but it must be a client only issue, as things look fine from the conqoper viewer. twiddling data in conqoper prob. issues some kind of update. darn, and I thought this was some cool as yet undiscovered feature. And the 0 army issue is with any sun, prob. on any version server. You slowly take damage. it takes awhile to drain the shield. I didnt try repair mode, you could prob. prevent any damage that way. ---------------------------------------------- 3 4 | 2 \|/ 5--*----> 1 Thing is facing this direction /|\ 6 | 8 7 -------------- next part -------------- An HTML attachment was scrubbed... URL: From god.000 at gmail.com Mon Oct 17 13:07:56 2005 From: god.000 at gmail.com (Almighty Tallest Cataboligne) Date: Mon, 17 Oct 2005 19:07:56 +0000 Subject: [conquest] what?! an invisible sun that kills? In-Reply-To: References: Message-ID: > I think you broke your client with > > those changes you made. > > Well I found the root of the problem. Issues with the dostand var. In the original scheme it could be set the NUM_BASEPLANETS or NUMPLANETS. Depending on the init you wanted. When you requested the standard planets be untouched on an init I changed the default from FALSE to TRUE...it really needed to be NUM_BASEPLANETS. But...now murisak doesnt disappear when set to inv.. no damage when its not visible, but the client still shows it. either client, GL or curses. every other planet list item is normal. And the 0 army issue is with any sun, prob. on any version server. You > slowly take damage. it takes awhile to drain the shield. I didnt try repair > mode, you could prob. prevent any damage that way. repair mode doesnt do it...damage is mimimal tho. ---------------------------------------------- 3 4 | 2 \|/ 5--*----> 1 Thing is facing this direction /|\ 6 | 8 7 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at radscan.com Mon Oct 17 18:33:53 2005 From: jon at radscan.com (Jon Trulson) Date: Mon, 17 Oct 2005 18:33:53 -0600 (MDT) Subject: [conquest] invisible sun / much to visible sun, final fix (damn it I hope!) In-Reply-To: References: Message-ID: 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 "I am Nomad." -Nomad From johnclute at imagi.net Mon Oct 17 23:35:12 2005 From: johnclute at imagi.net (John Clute) Date: Mon, 17 Oct 2005 23:35:12 -0600 Subject: [conquest] invisible sun / much to visible sun, final fix (damn it I hope!) References: Message-ID: <000f01c5d3a5$b67431e0$0401a8c0@tweenky> Here are some of my comments ----- Original Message ----- From: "Jon Trulson" To: "Almighty Tallest Cataboligne" Cc: "Conquest" 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 > "I am Nomad." -Nomad > >