Maverick

Yes, all that is true dteviot, but let's start here - there are several mistakes in your math. Primarily, your method for rotation of the axis is not quite correct because you must account for the alien craft being in any of the 4 quadrants and even then, the basic form should be 90-arctan(). Following this definition, wouldn't: Xc(t) = t * Vcx, Yc(t) = t * Vcy to give: Dc(t) = t * sqrt(Vcx^2 + Vcy^2) That is to say nothing of keeping track of the angle of travel. If I have interpreted the meaning of your formula correctly, what you have actually described is a variation of solution 3 -- because I am interested in course corrections at each step, we try not to extrapolate future position of the craft beyond the weight function -- your model is invalid for any craft not traveling in a straight line forever. And even in the case of a craft traveling in a straight line, if the speed of the UFO is greater than the speed of the craft there will be no solution for your quadratic equation for t because the distances will never overlap. You have all the right math, but you have incorrectly defined the parameters of the problem.

Side thought that resolves an issue -- if fuel consumption is only based on the time spent in the air (assuming that we agree to instant accel/decel and because lower than max speed will not be as frequent as at max speed) we can eliminate the discrepency between low speed clock ticks and high speed clock ticks -- since the same time will eventually pass at either time setting and the distance traveled is irrelevant to fuel consumption. It does not satisfy the difference in interception effectiveness, but it does reconcile the issue of fuel consumption. -Maverick

Specifically taking position into account -- I'm not sure that the craft should "own" a position value or whether it makes more sense for the planet to "own" the position of all objects in it. The potential benefits I see of this approach are: A single controller of all objects that require positions that can name each one which can then be queried (human bases, alien bases, terror sites, crash sites, UFO's, human craft) all have unique identifiers and their positions accounted for as long as they are active on the planet. Moreover this accounts for part of the record keeping required for interception/mission launch and waypoints. I don't know if this is negative progress but it seems that it would simplify the information that each craft keeps -- that is, the craft doesn't care where it is, the planet tells it where to exist. In a mathematical sense, if the craft "owns" its position, then it is relative to itself and you must calculate its position relative to the planet. My answer is sorta out of order, but....either way -- I would suggest yes, that they are the same -- simple consider a stationary object to have a velocity vector of 0. Assigning position/velocity vectors to objects may seem to add additional complication, but even for V1 this is important -- craft will waste fuel and you will have to come up with a triggering scenario to engage an enemy craft (like when it is "close enough") because if you only make it target the current position of a craft it will never actually reach it -- this may not be an issue if the program automatically targets where the object will be or if the scale is small enough (convergence). I would recommend against acceleration being a factor -- make all accel/decel instantaneous between ticks. If these are taken into account it makes things much more complicated because you have to decide what governs these behaviors. As for altitude, even a very high altitude (200+ miles) from the earths surface is very small compared to the radius of the earth and has little effect on the motion of the object -- 3% per radian traveled in linear distance measurement. I would still advise keeping track of altitude but only having two for use -- one for flying, one for on the ground. The base should just have available slots that are filled in order as ships return -- the ship should keep track of which hanger it is in on a temporary basis for consistency. The base that holds the ship should be held constant to prevent mid-air "transfers" of planes to allow more planes than there are hangers actually available. Fuel should be consumed based on time spent in the air -- this solution just occurred to me and it solves the issue of the path traveled. I'll elaborate in the appropriate thread. As a final thought, while UFO's should still have the attribute for fuel consumption, I do not think they should actually consume fuel -- unless 1) it is intentional that the amount of x122 (hope i used that right) will vary depending on how far the UFO has traveled when it is recovered, 2) it is to be used as a "timer" that limits how long a UFO can remain on the planet, 3) the fuel is considered separate from the amount of x122 recovered for the mission (wouldn't it be terrible if you assaulted a battleship that had been flying around and got 1 elerium for your trouble?), and 4) if you plan to address the issue of what happens when you run out of fuel assuming that you neglect 2). Sorry for the lengthy post and if this discussion is too old to warrant new input. -Maverick

It should be easier to understand if you read the attached PDF but it is pretty long and it isn't great quality. Essentially, I suggest we use a weighted projection function for interception path finding (explained in the PDF). I can write it in pseudo-code (I'm familiar with Matlab, which is similar to C) and there are a few other mathematical functions that would be necessary in order to implement it. On the whole it does nothing to eliminate the problem of fuel consumption. If I have not advanced the argument to you before, (Garo is the only one I've talked to) it is something like this (simply): If we do not compute movement at the minimal clock tick even for faster game speed (that would be to compute movement in terms of 5 second intervals even when the game passes at 1 hour ticks) fuel consumption is less at the higher game speed and thus the effectiveness of the interceptor is increased for higher game speed. In other words, you have better chances of catching a ufo at 1 hour/tick vs 5 seconds/tick. Page 2 of the PDF attempts to show the general concept. The difference in fuel consumption can be very small, but depending on the path being traced it maximizes at the limit of the ratio of time frames considered -- that means that for 1 hour vs 5 seconds it would be 720 times greater fuel consumption at 5 seconds. This is an unrealistic case! However, the fact that it can be that high means that we have to think about some way to solve this problem -- after we implement it without a solution (that is, ignore the problem for now -- it is possible that it will not end up being a problem for the player, it all depends really on how the UFO's travel, so we might be able to "guide" them in such a way as to minimize this effect). If this does not work, the other alternative is to change the base time tick as far as directional correction is concerned. That is, craft only change direction every 1 minutes (so at 5 seconds it would travel in straight lines for 1 minute at a time) -- which would reduce the maximum possible consumption error from 720 to 60 -- with resulting consequences at low speeds during interceptions....let me know what you think. -Maverick path_find.pdf

Hey RK, I've been well. I'm still in school, have another year to go, but I have some time for sure at least until October -- so I'll see what I can do in that time. I will happily volunteer any math skills I may have for whatever needs them. -Maverick

For those of you who do not know me, I am Maverick, I was active in this project long ago. I have come upon some spare time these days and I was wondering a few things specifically about your interception method. It is probably imprudent of me to jump straight in to questioning, but i believe it will bear itself out in the end. To begin: 1) Do you keep velocity vector information about generated ships, and if so, how do you consider it? (by velocity vector information i refer to both speed and direction, "consider" refers to coordinate system: cartesian, spherical, etc) 2) How are you currently "path finding" for the intercepting ship? I ask these two questions in order to point out that a) velocity vector information (of sorts) was included in the hyperwave transmission dialogue of the original xcom -- suggesting that they took it into account, ( to point out that if you simply have your ship "chase" the UFO, even on a small time frame it wastes fuel which is especially noticable when you consider the speed difference between the alien ships and the basic terran ships, and © to point out that following from (a) and ( the solution is to target the projected end point of the UFO. This is a further complication however, because it requires then that regardless of player selected game speed, each "move" of each ship must be calculated along the smallest possible tick length (which technically you should be doing anyhow -- if you allow the ships to only alter direction at each tick corresponding to user defined speed, the UFO will travel in an erratic pattern in trying to find it's way to a point.) The simplest example I can give is that if a player has the time set to 1 hour (game time) per 1 second (real time) then a ship should make 720 course corrections per game "tick". -Maverick

It looks like a UFO activity graph to me....but then I've got X-com on the brain (oh wait...we all do, that's why we're here!) *mav wanders off to wonder what this graph means in regards to the alien threat....*

scaling doesn't mean a whole lot within the game, it should just be a matter of setting the scale that you want the model displayed at. However, it would be good if the model was built to our scale so that we don't increase/decrease its size to much when trying to scale it. If you can find information about real missiles and use that to determine if those are the right length (according to my calcs, the missiles are between 9 and 12 feet long...i've never seen a real one, but that sounds a little big). Its not of paramount importance, but if you aren't doing anything else, scaling it saves us time later. -Mav

RK I stand in awe. In case you want to see where I'm coming from, this is the first version of code that i found that promised functions that could transfer files through sockets (no word on whether I can use this for SSL, though we may not need to) It has two problems: 1) our version would use SendFile() to receive a file and GetFile() to send it. (that should just be a matter of how the sockets are initialized though) and 2) no program that I include these in will even so much as compile!!! GRRRR! the website i found them on (code-guru) said they are part of MFC, so i've tried creating a project that supports MFC, but then they want a DLL or a static library. Take a look at the code, if its worth using, do it, if its not, forget it -- i have at least a dozen more "examples" of net-send code. void SendFile() { #define PORT 34000 /// Select any free port you wish AfxSocketInit(NULL); CSocket sockSrvr; sockSrvr.Create(PORT); // Creates our server socket sockSrvr.Listen(); // Start listening for the client at PORT CSocket sockRecv; sockSrvr.Accept(sockRecv); // Use another CSocket to accept the connection CFile myFile; myFile.Open("C:\\ANYFILE.EXE", CFile::modeRead | CFile::typeBinary); int myFileLength = myFile.GetLength(); // Going to send the correct File Size sockRecv.Send(&myFileLength, 4); // 4 bytes long byte* data = new byte[myFileLength]; myFile.Read(data, myFileLength); sockRecv.Send(data, myFileLength); //Send the whole thing now myFile.Close(); delete data; sockRecv.Close(); } void GetFile() { #define PORT 34000 /// Select any free port you wish AfxSocketInit(NULL); CSocket sockClient; sockClient.Create(); sockClient.Connect("127.0.0.1", PORT); // "127.0.0.1" is the IP to your server, same port int dataLength; sockClient.Receive(&dataLength, 4); //Now we get the File Size first byte* data = new byte[dataLength]; sockClient.Receive(data, dataLength); //Get the whole thing CFile destFile("C:\\temp\\ANYFILE.EXE", CFile::modeCreate | CFile::modeWrite | CFile::typeBinary); destFile.Write(data, dataLength); // Write it destFile.Close(); delete data; sockClient.Close(); }

As you guessed, the functionality is not there. The sending app as of right now will not be the app eventually. I'm working on using SSL to send the file instead of FTP (with FTP i have to hard code it and can't pass it directly to a parse app, which annoys mindstorm to no end) Eventually the functionality will be there for you to add comments and I will design it so that you can add comments while it is gathering the sysinfo.txt information. (that few second wait is really annoying, and the extra click on cancel is worse, I'll fix both of those in the next version.) I'm not gonna be able to work on the bug tracker much for the next week, so if anything a more up-to-date version will be used as a patch to Alpha 4, it can't be released with it. I'm using a batch file to run both programs at once right now, which is also not a very good way to do things. When i finally get the sockets working I'll use that to make more people happy. The info contained in the send box as of right now will be replaced with space for some text which will go into a 4th file that will be send to us. so we'll get: Engine Out.txt, Engine Assertion Out.txt, Sysdat.txt (sysinfo.txt?), and Comments.txt. The user will have the ability to view the first three files with a mouse click before sending. As a test, if you had a problem running it because dxdiagn.dll could not be found, please download this file and place it in windows\system32 (if asked to overwrite PLEASE make a backup of your current file) then try running it again. If it works, we might be able to by-pass the DXversion check by giving the computer the proper DLL. Dxdiag is NOT directly connected to the rest of DX so it should NOT affect the system in any other way. If it does, please tell me, and replace this file with your old one. (also, if anyone has access to the DX8 SDK, please tell me as it is no longer available for download now that DX9 SDK has been released). Thanks for your help and suggestions guys! -Mav dxdiagn.dll

I'm writing down the suggestions, but it will be a while before i can implement them. The dxdiagn.dll error probably means that you do not have a recent enough version of direct x on your machine -- this was written with the dx9 SDK so if you are pre-9 (as in 8, which i think most people are) it may not work. So for the final version, we may need Dx 9 as a requirement. error:2 as you guessed, means the file doesn't exist. I didn't bother going through and changing the error because i was more interested in the code actually working than the error reports. In fact, this code doesn't work well enough that i would ship it with alpha 4. It will be working well enough by the next release that it should be included (that may give me enough time to make it backwards compatible and figure out how to put each file in a unique directory or give it a unique name) I like the "view file" idea, i'll try to add the button, but it may take some time. thanks for your input! -Mav

OK programmers, i want to do a limited test of the bratt software that I have as of right now. If you'd download it and tell me somespecific information: a) what did you think? what can make it better? c) did you have any problems? I'd make this general release testing, but I'd prefer for now if only programmers would go through with the test. NOTE: as of right now the FTP side of it will warn you that the file already exists, just tell it to overwrite and then close the app. KNOWN ISSUES: -The FTP client doesn't close itself after it sends the file. -The batch file is DOS based, so it looks kinda weird. -If you were to click send the micro-second that the FTP client popped up it would tell you the file didn't exist (and on a really slow computer, it might be significantly more than a micro-second) -Finally, the FTP client is using my account for now. I didn't feel like hardcoding the permanent account. If you notice anything other than that, please tell me. -Mav bratt_stuff.zip

For tonight the source will be available on the repository, it is a VC++ 6 project file, but the souce files can be viewed (and possibly compiled...though good luck with that) with just about anything. I also added a timestamp function so that we know how long between when the file is generated and when it is sent. The source is available now in the same directory as the executable -- which has also been updated to the timestamp version. -Mav

BRATT source code will be up at the repository tonight, and I'll try to have it in CVS this weekend. In case you didn't know (or didnt' care until now, which is acceptable too, BRATT isn't pivotal to any milestone) All bratt does is gather a whole bunch of information about your computer and send it back to us. the code i'll be posting is only the "gathering" part, mindstorm still has to work out the sending part. The original idea and inspiration for BRATT is our terribly low feedback rate in the form of hard data (we get all kinds of feedback along the lines of "yeah its great" or "it doesn't work on my machine" but no one sends us system specs or error logs) This just does the work for them. It grabs all their system specs, driver info, stuff like that and then sends it to a server we control (probably the repository for now) where it gets stored in a database. the usefulness for programmers will come in when we have a way for you to search that database for information on specific errors or if you want to see systems that are having lots of problems. (you could even see if it runs better on a dell or a gateway, etc) eventually we may be able to use the data to determine that specific driver versions cause the game to fail. Since it does everything for them and takes less than 2 minutes on a good connection, it should boost our feedback substantially. anyway, the executable is already available at www.xenocide-repository.net in the archives folder and the source will be available to everyone later this weekend. -Mav

From what I've read, their "unique" gamplay style mixing turn based and real time combat sounds a whole lot like the real-time option in apocalypse, but i can't play the game so i don't really know for sure. In all honesty though, their game won't even be considered competition for our game when we release a full version. The biggest reason is the time frame difference and the fact that despite their best efforts, their game is not capable of appealing to large audiences for long term because they don't have multiplayer. It's all in good fun to play through a game and enjoy it for single player, but multiplayer is what really adds replay value. (how may people played starcraft single player campaigns over and over again? what about half life in single player time and time again? now how about starcraft, being like 5 years old and STILL have 200,000+ people on B.net last sunday? does counter-strike ring a bell to anyone?) Without multiplayer they'll be long forgotten when we release a full version, some comparison will be made, but that's it. You may say that we don't have multiplayer either, but the benefit we have is open-source code and dedicated programmers. So if we, or any other group would like to make a multiplayer version(s) its not as impossible as adding it to a game like AM. And thats just the tip of the iceberg between our game and AM. I'll play AM if i can get a box that can handle it, but there is just gonna be too big of a gap between them and us for our games to be competition. -Mav