View Full Version : Programmers working on TOAW clone
larryfulkerson
05 Jul 05, 15:41
First of all I'd like to thank all you guys who want to lend a hand in the writing of this clone thingie. It's quite a challenge for one person, no matter how talented, as I'm quickly finding out. It's not a cut-and-dried, read in some data, figure out the "result" and write out the answer....the kind of program I'm used to writing. It's got a little of everything in it. User interaction, graphics, audio, multi-threads, etc.
So um.......I thought I'd start a new thread for the programmers who want to help work on the TOAW clone.....sort of a work in progress on the Specifications for the TOAW clone since nothing is set in concrete yet........to help us work on the same sheet of music.
We can cuss and discuss the things the clone needs to be able to do, what the data structures would look like, what key press does what...that kind of thing.
The first thing that comes to my mind is what the clone needs, absolutely needs to have is a large [perhaps full-screen] is a large map of the game to play on.
I was thinking that 32-bit colors is perhaps a bit much since some players don't have the latest and greatest video cards and that maybe 24-bit might be the upper limit on bitmaps we should use ( this is still open for debate however) and that instead of using a smaller map for orientation purposes the user could just zoom way out, pick a spot to center his/her attention on, and zoom back in on that spot.
Also, I noticed some wrist discomfort after an all-day session of playing and thought it might be of use for some key codes to use so that the player might be able to play using just the keyboard. Something like this:
N next unit, or if in formation mode, next formation
E end my turn or if attacks are scheduled, resolve my attacks
Z zoom in/out the big map ( a toggle perhaps )
S "show me" where a popup menu would allow selecting ports,
airbases, engineers, headquarters, etc.
A display all the Air Units in "my" force
.
.
.
etc.
And since there aren't enough bits in an integer for all the different terrain types we're going to have I was thinking of having the internal logical MovementBitMap Array be a very Large Array ( one entry for each game map hex ) of pointers to structures. And each structure whould be something like this:
struct GameMapHex {
int BaseTerrain; // clear, muddy, sandy, forest, etc.
int Infrastructure; // road, rail, urban, canal, etc.
int Occupied; // whether the hex has somebody in it
// or not, & if so, by who
int Weather; // clean, rain, snow, etc.
};
One problemo with using an array is that it isn't always possible to know what size to use since some games have larger game maps (and therefore more hexes )than others and using a too-small array isn't workable, and using a too-big array wastes memory.
And dynamically building a linked-list is possible but slower to search than a B-tree. We could start the build of a B-tree with the hex in the "middle" to make it more "balanced" and therefore more quickly searchable....neither choice is as searchable as quickly as an array would be, but then we can't just set the arraysize to a "known" value since that would force all games to use the same map size. [or would it?].
I'm open to suggestions.
I was hoping to be able to have the ability to read in a bmp file for the game map and have the terrain tiles find "their" hexes by a pixel-by-pixel compare so that the internal Movement BitMap array could be built dynamically but subsequent testing has determined that searching for matches could take overnight even on faster machines ( I have a 2.6 Gigahertz cpu ) and that matches are few and far between and the hexes that have the most matches ( so far ) are the all-black border hexes. So I'm finding that that won't work. I guess, unless somebody has a better suggestion that some other way will have to be used to build the terrain-array(s). Maybe, like the original TOAW, we'll just have to build them "by hand" (using an editor).
I was hoping also, that we could use the scenario dump file for the input information for each scenario, what forces are involved, what units in each force, what time-frame is involved, etc. But I can't get my machine to do scenario dumps ( I'm running XP Pro, Service Pack 2 ) and my operating system truncates the scenario dumps at about 50K every time. I've tried to use program compatability switches but no go. Hum...?
The source code, such as it is so far, can be found at
www.the-strategist.net/~larry in the file source_code.zip
Please feel free to peruse and/or modify it as you wish, there's no copyright or anything....I want this to be a community project that we can all be part of and proud of. One problemo is that more than one person might be working on the same source code at the same time and whoever "checks in" his work last would over-write the changes done by the first "checker-iner". So I'd like to implement SpectreX's suggestion to do some kind of CVS thing with the source code.....but I don't know how to do that. Any suggestions? I'll look on the SourceForge.net site for suggestions for now and let you know what I find.
my email is larryfulkerson2002@yahoo.com if you have questions, concerns, suggestions, etc. that can't be handled here.
Thanks again guys.
I'm not volunteering to help programming, because my programming skills are a bit rusty, but here are some tips:
struct GameMapHex { int BaseTerrain; // clear, muddy, sandy, forest, etc. int Infrastructure; // road, rail, urban, canal, etc. int Occupied; // whether the hex has somebody in it // or not, & if so, by who int Weather; // clean, rain, snow, etc. };
Dont use INT for terrain, infrastructure etc, use objects. That will make it a lot easier to later add new features and will better help organize your program.
And using an array for a map should be no problem at all, because each scenario has a tag which tells the program the size of the map, so we can easily build an optimal array for each scenario, no need to use a generic value array :)
I think it would be best if we'd know the format of a scenario file, that would enable us to simply load an existing scenario, including map and units, into the new game, maybe Norm could help if we ask him nicely ?
larryfulkerson
05 Jul 05, 16:21
I'm not volunteering to help programming, because my programming skills are a bit rusty, but here are some tips:
Dont use INT for terrain, infrastructure etc, use objects. That will make it a lot easier to later add new features and will better help organize your program.
And using an array for a map should be no problem at all, because each scenario has a tag which tells the program the size of the map, so we can easily build an optimal array for each scenario, no need to use a generic value array :)
I think it would be best if we'd know the format of a scenario file, that would enable us to simply load an existing scenario, including map and units, into the new game, maybe Norm could help if we ask him nicely ?
Um....that's a great idea, using objects. Yeah, let's do that.
As to the format of the scenario file.....I've looked at it and I've determined that it's zipped up using pkzip somehow. That would make it smaller of course, but it also makes it difficult at best to pick apart since you have to unzip the pig to get at the data. I horsed around with unzipping that pig for about two weeks before giving up. If you can unzip it somehow my hat is off to you.
but your suggestion has merit. Maybe if we ask Norman nicely, he will ignore his no-disclosure agreement and tell us how to unzip it etc. Can't hurt to ask. I did send him an email, asking just that about 6 weeks ago and have yet to receive an answer. so.....?
larryfulkerson
05 Jul 05, 16:29
I might as well admit up front that I've been using the Borland C++ Builder 6.0 compiler since it supports fast application development and has components that I can use in the clone, but I also have the student version of MS VC++ compiler and can port to that platform if that's a problemo with anyone.
At any rate most of this project is modular and if we use Ansi C++ anyone can write code for it using any complier he/she wants to.
That's my first guess anyway. Anyone have any heartburn?
larryfulkerson
05 Jul 05, 17:26
Hey you guys, I registered at Source Forge for their CVS services so we can share the source code between us easier.
Here's what I have so far:
Project Information
-------------------
1. Submitter: larryfulkerson
2. Project UNIX Name: battlefatigue
3. Project Descriptive Name: BattleFatigue
4. License: Public Domain
License other:
5. Project Description: This TOAW clone is being written in C++ for the Win32 platform to overcome the deficiencies in TOAW and is intended to be an open source community project to be a wargame written by wargamers for wargamers.
6. Registration Description: The TOAW clone is intended to be the last Strategic Wargame you will ever need. It will, hopefully, include every feature set you can possiblly need in a wargame and then some. Features can be chosen from a menu and only those you desire will be used in gameplay. This would be the game you would play if you wrote it yourself. It's a game written by serious wargamers for serious wargamers. It's intended not just as a game but as an actual simulation of real
warfare. It's intended to be modular, so that features can be added dynamically ( using DLL's ) so that any needed feature can be added at a later date. An expandable, open sourced, and
wargamer-community-input-considered game should result in a superior wargame. This is the intention.
[end]
I chose BattleFatigue 'cause I didn't want to use the "TOAW" name since that might cause heartburn by the Take2 folks for some reason. Or TalonSoft for that matter.
Also, the thought just occured to me.....maybe Norman might join us since he can work on it annonoumously ( spelling ? )....just a thought.
Anyway I'll keep you guys in the loop.
Just responding to the post in the other thread...
Anyway, to answer your question: I have been using the Borland C++ Builder 6.0 for about 5 years now and LOVE it. But I also have the student version of MS VC++, so if you guys would rather use VC++ I can switch compilers.....I'm easy to get along with.
Well either way it's best to be consistent, I don't have borland atm but I'll go ahead and get it for the Cause.
Also, if you think we need some really neato graphics, graphics that can't be done with the windows GDI, then we can go to OpenGL or DirectX either one, I've invested a lot of time lately reading up on both of them. I haven't decided which is best though, somebody with experience in that area could tell us....maybe you know which is best.
If I had my choice I'd go with DirectX, if only because it's used so commonly, by TOAW among others.
I'm using C++ but I have nothing against straight C if you guys would rather use C instead.
In fact I suppose it really doesn't matter what language is used so long as the module can link together. I'd rather develop this thing using DLL's so we can make it modular, and expandable, ( and to update something just ship a new DLL rather than a MegaByte executable ).
Does anyone prefer C over C++? The idea of a modular construction is a good one but it might be a pain to implement. Even packed with all the features we can think of, the exe shouldn't be all that large.
My main experience has been in assembly language in the mainframe world, though in the last 10 years or so I've been dabling in PC's and higher level languages so I'm not completely lost (yet).
Most of my experience is with web applications (php, perl, mysql, lotus notes), and my major C++ experience has been working on anticheat software for Half-Life. So it'll be a learning experience for us both :)
Hey you guys, I registered at Source Forge for their CVS services so we can share the source code between us easier.
Not sure if you know about this or if it's mentioned in the SF documentation, but I recommend you download WinCVS (http://www.wincvs.org/). Much easier to use than the command line ;)
Presumably Sourceforge allows you to set up CVS accounts will full commit etc. permissions?
Edit: Could you also add me to the SF project? My username is specterx.
larryfulkerson
07 Jul 05, 00:31
Not sure if you know about this or if it's mentioned in the SF documentation, but I recommend you download WinCVS (http://www.wincvs.org/). Much easier to use than the command line ;)
Presumably Sourceforge allows you to set up CVS accounts will full commit etc. permissions?
Edit: Could you also add me to the SF project? My username is specterx.
WinCVS sounds like a winner. I'll download it of course.
I ordered the Borland C++ Builder Compiler over the net from Borland.com some years ago and it was $80 but that was years ago and maybe it's come down in price since then....also you might find a copy on Amazon.com that's cheaper.
I've never used CVS and/or SourceForge.net either one but presumably yes, they will issue us logons/passwords to use with our project. And if so, I'll of course share the logon/password with all the programmers who work on this thing with us.
I have no idea how long it'll take us to do this thing, but I'm guessing about a year or so with all the bug-fixing etc. included.
I had no idea that TOAW used DirectX, but then, I don't doubt it either. I've never used DirectX but I'll learn of course.
Thanks again my friend(s).
I've never used CVS and/or SourceForge.net either one but presumably yes, they will issue us logons/passwords to use with our project. And if so, I'll of course share the logon/password with all the programmers who work on this thing with us.
I _think_ if you're listed as a developer on the project and you log in to the SF CVS system it gives you full access to that project's CVS, not sure though.
larryfulkerson
07 Jul 05, 03:57
So um....specterX Dude: I downloaded the WinCVS and PuTTY and configured them and it's working okie dokie. I don't quite know how to move the files from my hard drive to the SF CVS repository yet, but I'm sure I'll figure it out sometime soon.
Do you have what you need to do what you want? I'm at your beck and call for any questions, etc. that come up.
I added you as one of the developers on the BattleFatigue project BTW. I'm hoping that when you logon using YOUR userID and password that you'll have complete access (read/write) to the BattleFatigue project repository stuff. I looked just a few minutes ago and there are already some CVS control files there so I guess it's ready for us to start working on stuff just as soon as I figure out how to send them to the repository.
HEY, wait a minute. If you have a copy of them ( the files ) you could send them yourself and tell me how you did it, if you'd like that is. I'm not too proud to admit I'm new at this stuff.
I downloaded the CVS manual ( a huge PDF file ) and I've been looking over a lot of the verbage in it. Most of the instructions seem to cover command-line methods of doing things and I'm using WinCVS so much of it is being lost in translation I'm afraid.
Anyway..... :laugh:
CVS can indeed be a pain to use. There's a short guide here (http://www.thathost.com/wincvs-howto/) that's been really helpful to me in the past. It might refer to an old version though (says it refers to 1.0.x) so some of the menus and so on might be different. I recall that I also had some trouble with WinCVS the last time I used it that was solved by moving to a different version (unfortunately I'm in Europe till the end of the month without all my previous work or configuration, just my laptop), so if you have problems you might consider "downgrading."
One thing to keep in mind is that it's very difficult to do simple things like move a file from one directory to another or make minor structural changes, so you might want to create a basic directory structure (or not if you don't think it'll be needed/useful). I think all the important stuff is in that guide, however.
Just doing some thinking about a few things...
Units/Equipment:
Units could be stored as a linked list of objects with the various properties of each unit (force, formation, morale, proficiency, location, supply level etc.) as components of the object. Within each unit object, that unit's equipment could be a matrix of integers where each "horizontal" element is one equipment slot, the first "vertical" element is the number of authorized pieces of equipment, and then each two successive "vertical" elements are one index of the central equipment database (assuming this database is an array this wouldn't require searching or anything) and then the current number of assigned pieces of that equipment type. In this way we could allow for multiple different equipment pieces to occupy the same slot, which would allow representation of "ad-hoc" TOEs and equipment upgrades in a much more realistic and efficient fashion. The equipment database itself would be an array of objects stored in a separate database file and loaded in from a text file that can be created by a separate tool (of course a default database would be provided). Perhaps, for each scenario, the designer would load in the raw text file and when he saves the scenario an encrypted ".DBE" file would be created along with the .SCE, and whenever a new text file is loaded in a new encrypted database file would be generated based on a dynamic key (based on date/time or something) that is then encoded in the scenario file - so the only way to modify the database file associated with a given scenario would be to do so in the editor, ensuring that once a match starts the associated database file can never be changed. Each scenario would then have both an .SCE file and a ".DBE" file.
By using the above design, the available equipment slots both in a given unit and in the game as a whole would be increased to 65536, so no more problems with using all 24 slots in a unit...
One way to handle formations and multiple formation layers would be to have each "formation" object (with formation properties such as comms level etc.) only know what its parent formation is, not what its children are - so the children/subunits of a given formation could be either units or other formations. In theory, then, you could have an almost unlimited number of "layers" of formations, and each layer could have both units and other formations as subordinates. Internally all formations would be stored as one linked list, units would be another list, and the game would sort it out at runtime.
larryfulkerson
07 Jul 05, 12:37
CVS can indeed be a pain to use. There's a short guide here (http://www.thathost.com/wincvs-howto/) that's been really helpful to me in the past. It might refer to an old version though (says it refers to 1.0.x) so some of the menus and so on might be different. I recall that I also had some trouble with WinCVS the last time I used it that was solved by moving to a different version (unfortunately I'm in Europe till the end of the month without all my previous work or configuration, just my laptop), so if you have problems you might consider "downgrading."
One thing to keep in mind is that it's very difficult to do simple things like move a file from one directory to another or make minor structural changes, so you might want to create a basic directory structure (or not if you don't think it'll be needed/useful). I think all the important stuff is in that guide, however.
Thank you SO much for the link. I'm going to read it in it's entirety. And put it to good use.
larryfulkerson
07 Jul 05, 13:16
Units/Equipment:
Units could be stored as a linked list of objects with the various properties of each unit (force, formation, morale, proficiency, location, supply level etc.) as components of the object. Within each unit object, that unit's equipment could be a matrix of integers where each "horizontal" element is one equipment slot, the first "vertical" element is the number of authorized pieces of equipment, and then each two successive "vertical" elements are one index of the central equipment database (assuming this database is an array this wouldn't require searching or anything) and then the current number of assigned pieces of that equipment type.
In this way we could allow for multiple different equipment pieces to occupy the same slot, which would allow representation of "ad-hoc" TOEs and equipment upgrades in a much more realistic and efficient fashion.
you mean something like this ?:
int col, row; // col = equipment slot, row 1 = index into DBE for *that* equipment
// row 2 = # authorized pieces of *that* equipment
// row 3 = # assigned pieces of *that* equipment
class UNIT
{
private:
class FORCE;
class FORMATION;
class MORALE;
class PROFICIENTY;
class LOCATION;
class SUPPLY_LEVEL;
int EQUIPMENT[ col ] [ row ];
UNIT *next;
UNIT *prev;
public:
UNIT();
~UNIT();
};
I think that's a great idea. I've organized the stuff in the Scenario dump somewhat along these lines already in the structure called, oddly enough, Scenario found in the file: design_scenario.h
And since a structure is a class where everything is public, it shouldn't be hard at all to convert it to a class with a constructor/destructor and everything.
I think that's a grand idea.
The equipment database itself would be an array of objects stored in a separate database file and loaded in from a text file that can be created by a separate tool (of course a default database would be provided).
I've already converted the TOAW generic database into a text file called database.txt. here's the first few bytes from the first two lines in it:
ID....Title....................................... ..AT.....AP......AA......DF......ART_Ra..EXT_Ra... .SAMrange
0.....Infantry & Support Troops.........0......0.......0........0.......... ...0.........0..............0
[NOTE: I had to insert "dots" to separate the columns. How do you get this thing to keep the spaces you insert before the lines?]
Perhaps, for each scenario, the designer would load in the raw text file and when he saves the scenario an encrypted ".DBE" file would be created along with the .SCE, and whenever a new text file is loaded in a new encrypted database file would be generated based on a dynamic key (based on date/time or something) that is then encoded in the scenario file - so the only way to modify the database file associated with a given scenario would be to do so in the editor, ensuring that once a match starts the associated database file can never be changed. Each scenario would then have both an .SCE file and a ".DBE" file.
In addition to encrypting it maybe we should zip it up as well to make it smaller. Or maybe instead of encrypting it we could just zip it up. Whichever you'd rather do is fine with me.
By using the above design, the available equipment slots both in a given unit and in the game as a whole would be increased to 65536, so no more problems with using all 24 slots in a unit...
One way to handle formations and multiple formation layers would be to have each "formation" object (with formation properties such as comms level etc.) only know what its parent formation is, not what its children are - so the children/subunits of a given formation could be either units or other formations. In theory, then, you could have an almost unlimited number of "layers" of formations, and each layer could have both units and other formations as subordinates. Internally all formations would be stored as one linked list, units would be another list, and the game would sort it out at runtime.
Wonderful. I'm in full agreement with all of the above.
you mean something like this ?:
int col, row; // col = equipment slot, row 1 = index into DBE for *that* equipment
// row 2 = # authorized pieces of *that* equipment
// row 3 = # assigned pieces of *that* equipment
class UNIT
{
private:
class FORCE;
class FORMATION;
class MORALE;
class PROFICIENTY;
class LOCATION;
class SUPPLY_LEVEL;
int EQUIPMENT[ col ] [ row ];
UNIT *next;
UNIT *prev;
public:
UNIT();
~UNIT();
};
Pretty much, except morale, proficiency etc. would be ints or something. As for the equipment array, I was imagining something like this, for say an infantry division:
equipment[0][0] is 324 (324 slots for slot "zero")
equipment[0][1] is 10 (say 10 is the index for the "rifle squad" equipment)
equipment[0][2] is 204 (say the division has 205 rifle squads)
equipment[0][3] is 11 (say 11 is the index for HRS)
equipment[0][4] is 120 (120 HRS)
So the division would have 204 rifle squads and 120 heavy rifle squads in the first equipment slot, which has an authorized total of 324 pieces.
Values of -1 would indicate a blank element.
Only problem I can see is if someone assigns a huge number of different equipment types to the same slot, in which case the matrix could get quite large... but you'd have to assign like 100 pieces to the same slot for this to become a problem. I recall that we can use realloc to resize the array (not sure of the exact syntax atm).
I've already converted the TOAW generic database into a text file called database.txt. here's the first few bytes from the first two lines in it:
Makes things easier.
In addition to encrypting it maybe we should zip it up as well to make it smaller. Or maybe instead of encrypting it we could just zip it up. Whichever you'd rather do is fine with me.
The point of encrypting it would be to prevent people from altering the database in mid-scenario, or at least make it unreasonably difficult. I guess since people can already do this it's not a huge deal, but as long as improving security is a major objective of the project... compressing it also is a good idea.
larryfulkerson
07 Jul 05, 14:54
Pretty much, except morale, proficiency etc. would be ints or something. As for the equipment array, I was imagining something like this, for say an infantry division:
equipment[0][0] is 324 (324 slots for slot "zero")
equipment[0][1] is 10 (say 10 is the index for the "rifle squad" equipment)
equipment[0][2] is 204 (say the division has 205 rifle squads)
equipment[0][3] is 11 (say 11 is the index for HRS)
equipment[0][4] is 120 (120 HRS)
So the division would have 204 rifle squads and 120 heavy rifle squads in the first equipment slot, which has an authorized total of 324 pieces.
Values of -1 would indicate a blank element.
I'm confused. equipment[0][0] is 324 slots for slot "zero" ???
How about using an array of objects? With each object being
something along the lines you mentioned earlier:
[using a linked list of Pieces of Equipment]
class EQUIPMENT {
int m_Authorized;
int m_Assigned;
int m_index_into_DBE_file;
EQUIPMENT *next;
};
class UNIT {
EQUIPMENT *m_first_of_possibly_many;
POINT m_location;
int m_proficiency;
int m_supply_level;
// etc. ...etc.
};
What do ya think?
larryfulkerson
07 Jul 05, 15:04
Oh, and also, I've been trying all morning to find a way to import the files to the SouceForge repository and have run into a brick wall.
The WinCvs Document says "sorry not yet" in answer to just this problemo.
I'm finding that I don't know how to set the CVSROOT environment variable. The error message SF_CVS gives me is:
cvs add -- main.cpp (in directory G:\TOAWc\TOAWc\)
cvs add: No CVSROOT specified! Please use the `-d' option
cvs [add aborted]: or set the CVSROOT environment variable.
***** CVS exited normally with code 1 *****
and I've tried the command line way of using the -d option and it doesn't like it. Then I tried to set it in WinCVS using the CVSROOT ellipis and that doesn't work either. I'm stumped
here's the settings I'm trying to use: could you give it a scan and see if you know what I'm doing wrong?
Most of my experience is with web applications (php, perl, mysql, lotus notes), and my major C++ experience has been working on anticheat software for Half-Life. So it'll be a learning experience for us both :)
Wait a minute, you're not a UA guy are you?
Wait a minute, you're not a UA guy are you?
Used to be. I worked on HLGuard from around November 2003 to April or May of last year, my pet project was the UA Blacklist. I pretty much quit when university started (here I was thinking I'd have LESS free time) and it seemed that HL1 was pretty much a done system.
I'm confused. equipment[0][0] is 324 slots for slot "zero" ???
Slot zero is just the unit's first equipment slot (represented by the first dimension of the array). Only problem with the above is it doesn't allow for different types of equipment to share the same slot (I guess we should agree whether this is an objective or not?)
Oh, and also, I've been trying all morning to find a way to import the files to the SouceForge repository and have run into a brick wall.
The WinCvs Document says "sorry not yet" in answer to just this problemo.
I'm finding that I don't know how to set the CVSROOT environment variable. The error message SF_CVS gives me is:
cvs add -- main.cpp (in directory G:\TOAWc\TOAWc\)
cvs add: No CVSROOT specified! Please use the `-d' option
cvs [add aborted]: or set the CVSROOT environment variable.
***** CVS exited normally with code 1 *****
and I've tried the command line way of using the -d option and it doesn't like it. Then I tried to set it in WinCVS using the CVSROOT ellipis and that doesn't work either. I'm stumped
I'll get everything set up on this computer and have a look.
Ok, I got it working by doing the following:
1) Using this version of WinCVS (http://matt.dfstudios.com/WinCvs13b13-2.zip)
2) Made my private key, sent public key to Sourceforge (down on the accounts pref page there's a link to the page where you can add keys, paste the data in from puttygen right when you generate it - if you save the public key to a file and paste it later, you might have problems)
3) As per the directions on sourceforge for initializing your home directory, I opened putty.exe, entered cvs.sourceforge.net as the hostname, specified my private key file in connection->ssh->auth (left window), and then hit "open". It should open an SSH window, prompt for your user and password, and then immediately close (if you want to see the output you can run putty from cmd.exe).
4) In admin->preferences, set authentication to ssh, path to /cvsroot/battlefatigue, host address to cvs.sourceforge.net, user name to specterx, cvsroot to specterx@cvs.sourceforge.net:/cvsroot/battlefatigue (might be autogenerated)
5) In "settings" (next to where you select ssh as the authentication) I checked all the options, setting the private key to point to my ppk file, ssh client to C:\Program Files\putty\plink.exe, then in "Additional SSH Options" I entered "-l user -pw password" where user would be your username and password your password.
6) In Globals, dirty files support, prune empty directories and supply control when adding files are all checked, all others unchecked (I unchecked checkout read-only)
7) Set my home directory to C:\Program Files\putty - not sure if this matters
8) I started up pageant and loaded the key - again, not sure if this matters since it's specified elsewhere
9) At this point I imported the module, so it's in the repository as "toawclone". If you navigate to a directory on your computer in the main window, run "checkout module", and enter toawclone as the module, it should create a subdirectory called "toawclone" and download all the files. Note that it's something like 4mb and, for me at least, it seems to take a long time to run various commands, but as long as the little fish are swimming in the bottom of the wincvs window data's being transferred :D
larryfulkerson
07 Jul 05, 18:05
Thanks for taking a look at the cvs problemo.
And as for the unit's equipment array:
As I understand it your conception of the equipment array would have two rows for each possible piece of equipment in the database. If this is the case it might become a memory hog since it would probably amount to a "sparce array" with most of the rows having "-1" in them to indicate an empty slot. And there are about 1970 + possible pieces of equipment in the generic database alone.
That means that each Unit ( quite possibly approaching 2,000 per side ) in each force would have to have space set aside for them about 4000 bytes of space AT LEAST, most of which would be the integer entry "-1".
Um...... We could parse the database into a balanced-binary-tree structure or something indexed, so that a lookup would take only nanoseconds and just have the unit carry with it a linked-list of the equipment that it actually has. And the linked-list might be just the index into the database for the equipment and two integers representing authorized and assigned numbers of that equipment. MUCH less "wasted" space.
But I'm not married to any one concept. Maybe I'm still confused on how the equipment thingie is supposed to work, etc.
Thanks for taking a look at the cvs problemo.
And as for the unit's equipment array:
As I understand it your conception of the equipment array would have two rows for each possible piece of equipment in the database. If this is the case it might become a memory hog since it would probably amount to a "sparce array" with most of the rows having "-1" in them to indicate an empty slot. And there are about 1970 + possible pieces of equipment in the generic database alone.
That means that each Unit ( quite possibly approaching 2,000 per side ) in each force would have to have space set aside for them about 4000 bytes of space AT LEAST, most of which would be the integer entry "-1".
Um...... We could parse the database into a balanced-binary-tree structure or something indexed, so that a lookup would take only nanoseconds and just have the unit carry with it a linked-list of the equipment that it actually has. And the linked-list might be just the index into the database for the equipment and two integers representing authorized and assigned numbers of that equipment. MUCH less "wasted" space.
But I'm not married to any one concept. Maybe I'm still confused on how the equipment thingie is supposed to work, etc.
Yeah, that might be a problem - the wasted space would be fairly minimal if we could adjust the array size as needed, but I'm remembering how much trouble it can be to try and use dynamic arrays in C++ (realloc can cause problems as I recall). Another solution would be to have two lists, the first of "slot" objects storing the number of authorized pieces for that slot, with pointers both to the next slot and to the first "equipment" object for that slot. The equipment object would in turn point to the next equipment object, if the slot is occupied by more than one equipment type (see the RS/HRS example above). So it would look something like this:
class UNIT {
SLOT *first;
POINT location;
int proficiency;
int supply_level;
// and so on
};
class SLOT {
int authorized;
EQUIPMENT *first;
SLOT *next;
};
class EQUIPMENT {
int assigned;
int dbIndex;
EQUIPMENT *next; // Null unless the slot is "shared"
};
larryfulkerson
07 Jul 05, 19:45
Yeah, that might be a problem - the wasted space would be fairly minimal if we could adjust the array size as needed, but I'm remembering how much trouble it can be to try and use dynamic arrays in C++ (realloc can cause problems as I recall). Another solution would be to have two lists, the first of "slot" objects storing the number of authorized pieces for that slot, with pointers both to the next slot and to the first "equipment" object for that slot. The equipment object would in turn point to the next equipment object, if the slot is occupied by more than one equipment type (see the RS/HRS example above). So it would look something like this:
class UNIT {
SLOT *first;
POINT location;
int proficiency;
int supply_level;
// and so on
};
class SLOT {
int authorized;
EQUIPMENT *first;
SLOT *next;
};
class EQUIPMENT {
int assigned;
int dbIndex;
EQUIPMENT *next; // Null unless the slot is "shared"
};
OooooooH. Yeah, that'd work. Good idea. Let's go with that.
So um.......what do you want to work on? I'm puttering around with the plotting of terrain tiles and building the internal Movement BitMap right now, but I'm flexible and can work on something else if you'd rather do that instead.
What do you need from me at this point? I can post some more files or some design documents or something if you need 'em. By the way I've collected all the forumites suggestions into a file called wishlist.xls and here it is.
larryfulkerson
08 Jul 05, 04:15
Hey thanks a million man. Those instructions were just the ticket. Works like a charm now. I've moved some more directories to SF and files galore are out there now.
There are two parts to this project so far:
1) the scenario designer thingie ( to build scenarios )
2) the toaw clone program itself.
I've made a stab at starting both of them. :laugh:
Hey thanks a million man. Those instructions were just the ticket. Works like a charm now. I've moved some more directories to SF and files galore are out there now.
There are two parts to this project so far:
1) the scenario designer thingie ( to build scenarios )
2) the toaw clone program itself.
I've made a stab at starting both of them. :laugh:
Awesome. I haven't really looked at the code to any real degree because I still don't have Borland, and I have an irrational aversion to looking at code without the "correct" IDE :laugh: I'll start to go through it when I get home today, however, and everything ought to be sorted by the end of the weekend.
If you have any design documents or other documentation material (like that wishlist file) you might upload them to CVS (say in a /docs folder), so then we can access them and make revisions in the same way as the other files.
Edit: I see you've already done the above, I'll look it over. A lot of the values in the database seem to be off by the way, especially AP, strvol (volume?), weight, and armor. Also, the database is missing all of the flags, though this could be intentional to make it readable (presumably the file that's actually loaded wouldn't be designed with readability in mind).
Used to be. I worked on HLGuard from around November 2003 to April or May of last year, my pet project was the UA Blacklist. I pretty much quit when university started (here I was thinking I'd have LESS free time) and it seemed that HL1 was pretty much a done system.
I tried so hard to get them to actively prepare to move over to HL2, but no one seemed to listen. :rolleyes:
By the way, I'd love to help with this project, hopefully I'll soon get the free time to read this thread thoroughly and check out the actual code.
larryfulkerson
08 Jul 05, 18:40
By the way, I'd love to help with this project, hopefully I'll soon get the free time to read this thread thoroughly and check out the actual code.
So um.......Overseer, I'll add you as a developer to the battlefatigue project at SourceForge so you can access the files. Thanks for the offer to help.
( I'm assuming your userID at SourceForge is "Overseer" ).
larryfulkerson
08 Jul 05, 18:43
A lot of the values in the database seem to be off by the way, especially AP, strvol (volume?), weight, and armor. Also, the database is missing all of the flags, though this could be intentional to make it readable (presumably the file that's actually loaded wouldn't be designed with readability in mind).
I'll do a re-run of the building of the text database using the opart 300 CW.exe as the source of information and put the values of the flags in the output as well, so we'll have an updated version of the contents of the generic equipment database to use as input(s).
Thanks for your catch of this problemo.
larryfulkerson
08 Jul 05, 19:04
Okie dokie, I've added Overseer to our list of developers.
Here's the manpower of the battlefatigue project so far:
http://www.the-strategist.net/~larry/battlefatigue_staff.JPG
larryfulkerson
08 Jul 05, 22:02
Hey you guys, recently I went to Amazon.com and invested several hundreds of $ in the five books "Game Programming Gems" and read them all and made some notes, etc. and they are written by guys in the game programming field(s) who wrote about things they discovered and/or learned along the way. Some good code and tips/tricks can be found in there......plus all five of them came with a CDrom that have tidbits of good stuff on them. Would it be of an interest to anybody if I post the contents of the CDroms to SF? Or maybe just list a title of contents of them or something? And then you guys could pick and choose what you'd be interested in?
By the way, every programmer I've read in them ( GPG's ) says the way to go on highly interconnected programs ( like the one we're writing ) is with passing messages from module to module. That way you can keep track of EXACTLY what happened when so it aids in debugging, plus facilitates PLAYBACK support and a whole host of things become possible that were difficult at best.
So I've aleady made a stab at building a structure for the messages we can pass from module to module, etc. I timed it as well......it takes about 2 milliseconds for the message to be constructed, passed, and acted upon in the designer.exe ( the scenario designer thingie ). That's about 50 messages per second we can build and pass. Plenty enough for what we want to do. And using multi-threading we can do all of them simultaneously. ( Or seemingly so, from the users viewpoint. )
Anyway, I'm excited that we're putting a team of programmers together to do this thing. I've worked on smaller teams before and it was a blast.
So I thought I'd put a few thoughts together and keep you guys in the loop, etc.
Hey you guys, recently I went to Amazon.com and invested several hundreds of $ in the five books "Game Programming Gems" and read them all and made some notes, etc. and they are written by guys in the game programming field(s) who wrote about things they discovered and/or learned along the way. Some good code and tips/tricks can be found in there......plus all five of them came with a CDrom that have tidbits of good stuff on them. Would it be of an interest to anybody if I post the contents of the CDroms to SF? Or maybe just list a title of contents of them or something? And then you guys could pick and choose what you'd be interested in?
List of the contents maybe - you could post it on the forum in SF. Easier than uploading hundreds of megaybtes I'd say.
By the way, every programmer I've read in them ( GPG's ) says the way to go on highly interconnected programs ( like the one we're writing ) is with passing messages from module to module. That way you can keep track of EXACTLY what happened when so it aids in debugging, plus facilitates PLAYBACK support and a whole host of things become possible that were difficult at best.
So I've aleady made a stab at building a structure for the messages we can pass from module to module, etc. I timed it as well......it takes about 2 milliseconds for the message to be constructed, passed, and acted upon in the designer.exe ( the scenario designer thingie ). That's about 50 messages per second we can build and pass. Plenty enough for what we want to do. And using multi-threading we can do all of them simultaneously. ( Or seemingly so, from the users viewpoint. )
Will look at how it's structured.
I've obtained Borland, by the way. If you could go on Yahoo messenger (or one of the other four IM programs I've got) sometime I've got a few questions to ask that don't really deserve posting on the forum.
FYI, it doesn't look like I'll be able to get any work done on this of note until I get back to the United States in August, as I'm leaving Paris tomorrow and will be traveling around for the next several weeks. What's your status overseer?
larryfulkerson
12 Jul 05, 14:34
thanks for the update. No problemo.
larryfulkerson
13 Jul 05, 19:09
Hey guys, I'm embarrassed to admit this, but I made some changes to the files in cvs/battlefatigue/toawclone and now I can't update them ( I suppose it's because I didn't check them out first ). The error message I get is "the absolute path is invalid" and the path I have listed is" "cvs/battlefatigue/toawclone"
so that's obviously the wrong path. So I'm wondering what the correct path is. Do you include the name of the file(s) you're updating? or???
[QUOTE=larryfulkerson]
So I've aleady made a stab at building a structure for the messages we can pass from module to module, etc. I timed it as well......it takes about 2 milliseconds for the message to be constructed, passed, and acted upon in the designer.exe ( the scenario designer thingie ). That's about 50 messages per second we can build and pass. QUOTE]
I know zilch about programming, but if an action takes 2 milliseconds, would that not allow 500 instead of 50 actions per second (1/0,002=500) :whist: .
larryfulkerson
14 Jul 05, 13:55
[QUOTE=larryfulkerson]
So I've aleady made a stab at building a structure for the messages we can pass from module to module, etc. I timed it as well......it takes about 2 milliseconds for the message to be constructed, passed, and acted upon in the designer.exe ( the scenario designer thingie ). That's about 50 messages per second we can build and pass. QUOTE]
I know zilch about programming, but if an action takes 2 milliseconds, would that not allow 500 instead of 50 actions per second (1/0,002=500) :whist: .
Well, I believe you're right. I sit corrected. Thanks for the catch. I was so excited about the quickness of our possible message passing facility I was off by a magnitude. You sure you don't want to be a programmer?
larryfulkerson
14 Jul 05, 15:51
Hey you guys, I've been looking at the MovementBitMap and how to construct it and I've got some questions that might benefit from your input:
(1) where do we put the "degree-of-dificulty-of-traversing"
a specific terrain type?
(2) how do we determine what those values are? Given that
different games can have differing "scales" [10 km per
hex or 25 km per hex, etc.]
(3) as units cross open terrain in the rain the hex turns
into a quagmire ( muddy ) and the difficult increases
so whouldn't the d.o.d.o.t. increase as well?
(4) shouldn't aircraft be affected by the weather in travel,
combat, ferry ops. etc. I'm inclined to think so. I'm
a pilot and I can testify to the differences in clear
sunny days and days the darker shade of gray. Finding
things even on the best of days can be difficult at best
sometimes.
What do you guys think?
[QUOTE=rasmus]
Well, I believe you're right. I sit corrected. Thanks for the catch. I was so excited about the quickness of our possible message passing facility I was off by a magnitude. You sure you don't want to be a programmer?
Sorry but I cannot even program my own VCR... :cry:
I think this is better left to people with talent and skills. :D
Has anyone given any thought for the AI?
Years ago I ran into this game called Crisis, haven't been able to found it since, but it was sort of a Toaw clone. Well, turn based, hexes and units like in Toaw :)
Anyways, in the AI in the game was scenario specifig, you would simply 'code' it for each scenario. Of course you still need the basic AI, ie. "don't ignore enemy troops that are about to encircle your whole army".
With coding I mean things like "If city x and thisandthat fall then form new defensive line in 23,25-25,26-29,40...".
Crisis (http://museum.sysun.com/crisis/index.html) was indeed a promising game - however its development seems altogether stopped. Besides, at some point down the game it crashed (at least on my systems).
From memory, the cool features were the possibility to change HQ assignments, give formation orders, have leaders command the formations and, at least roughly, manage production.
Well, turn based, hexes and units like in Toaw :)
Turn-based yes, but hexes no: the game uses a square grid ;)
Turn-based yes, but hexes no: the game uses a square grid ;)
Well, it was several years ago when I last played it :)
If I recall correctly, the dos version worked quite well but the windows version was buggy as hell.
larryfulkerson
26 Jul 05, 03:38
Has anyone given any thought for the AI?
Years ago I ran into this game called Crisis, haven't been able to found it since, but it was sort of a Toaw clone. Well, turn based, hexes and units like in Toaw
Anyways, in the AI in the game was scenario specific, you would simply 'code' it for each scenario. Of course you still need the basic AI, ie. "don't ignore enemy troops that are about to encircle your whole army".
With coding I mean things like "If city x and thisandthat fall then form new defensive line in 23,25-25,26-29,40...".
Hey, that's a great idea. Let's do that in the clone.
As a matter of fact I have been doing some generic algorythm kinds of things. It uses the sortof evolution kinds of processes to "grow" better "programming". I mean you have a set of "chromosomes" that have "genes" in them and you mutate the genes "slightly" ( say 1% or less ) and then you "evaluate" the gene to see does it "do" what you want it to. You keep the best of the best, kill off the losers and do the cycle again( and again, etc. ) until you get the degree of "do-ing" you wish to use in the game.
Chromomsome: a set of, say, 1000 genes.
Gene: 52,205,64,93,102,244,212,128,53,86,97,102,24,83...
a vector of numbers, each number standing for some "operation" that the unit can perform.
The operations that are possible can be something like this:
1: defend hex
2: retreat
3: deliberate attack
4: hasty attack
5: recon hexes "forward"
6: etc.
7: etc.
And when you "evaluate" the gene you pretend that the "operations" that it has in it are "performed" by the unit in question and "see" does it do good (survive, or succeed ) or bad ( does it get killed, or wander aimlessly, etc. ) by assigning "points" to each "good" thing it "does".
Those with the highest points are the "GOOD" ones and those with the lowest points are the "Loosers".
You do this for about 1MEG cycles and after a while the good ones bubble to the top and the losers are gotten rid of.
Yet, each cycle can be performed quickly: say 10 per second, in a computer. So the process needn't take weeks or months, although depending on the "complexity of the evaluation" of the genes the process of each cycle may indeed take more time.
The point is that you can tweak the genes to have the "operations" you desire by modifying the "evaluation" process so that in the end you get them to "do" whatever you want them to do.
It's a great process and I've already tried to get a string of random letters to match a specific sentence.
I used 50 genes, each about 30 letters long and within, well, less than a second, the sentence "The lazy brown dog jumped over the farmers fence" was constructed. So I know, in principle, this method ought to give us the AI we so badly need.
'Cause you need a good AI to give you the challenge you need to play good games. I ALWAYS learn more from the games I lose than I do from the games I win.
Even analysing the moves of a good player can be informative.
But I digress.
I am not quite sure what you are saying...and besides, wouldn't it require quite much calcualting with scenarios that have a few thousand units?
larryfulkerson
26 Jul 05, 12:28
No, see, you'd do the calculating, the "teaching" of the gene(s) before you'd employ the resulting program.
The wargame wouldn't be the thing that you'd use to "evaluate" the goodness of the AI, although it could be used for that purpose. Um.......I'm explaining this very badly.
Before you'd use the AI program in the wargame you'd dedicate some time ( say a week, maybe less ) to "teach" the AI to be able to fight credibly in the clone wargame. AFTER it's learned how to fight, you could then include it in the clone, in the form of a script ( a text file or something similar ) for instance.
Or if you wanted it to behave "just like a person" you could just run it through as many training cycles as it required to teach it how to do just that.
airBiscuit
26 Jul 05, 12:37
Well, the 'genetic algorithms' you speak of could be a good approach for having the AI strategize opening-book maneuvers, but as for tactics when the battle is on, you need something more responsive. That's when you fall back to other techniques such as Bayes probabiliites and membership functions. You can write AI to learn effective counters to the opponent during play.
You have completely lost me. I'm gonna go play with legos now.
Anyways, back to these 'genes', is till don't undrestand them...would they be used for each and every unit, or for the formation as a whole?
larryfulkerson
28 Jul 05, 11:38
Anyways, back to these 'genes', is till don't undrestand them...would they be used for each and every unit, or for the formation as a whole?
That's the beautiful part of the genetic algorythm, you can train one AI gene to be the "general" and one gene to be the "arty" and one to be the "armour" and one to be the "engineer" etc. Whatever behavior you desire, if you can write the "evaluation" routine for it, you can train a gene to give you that behavior. I love it.
But would that mean that once you have the 'perfect gene' the AI will always act like that? But as I see it, the problem is that humans always use a different strategy, they never move the units in the same order or through the exact same way...
Or do yuo simply mean that the AI would learn that "in this scenario it is best to attack with armor" or "It is best to defend" etc.? I am really lost here as to what exactly this whole 'gene' thingie means.
larryfulkerson
30 Jul 05, 05:29
So um.........SpecterX, if you still have your ears on I have an open letter for you :
You and I have been corresponding about the Clone, You have downloaded the code, you have gotten The Borland C++ Builder 6.0 compiler, you're just as capable as I am to write the clone.....why don't you take over the BATTLEFATIGUE project on SourceForge and continue onward with yourself as the project manager instead of me.
It appears that I have cancer and I'm going to die. I have an appointment on August 3, 2005 at the VA hospital here in Tucson, AZ, to see how big the tumor is ( if that's what it is ) and to see, roughly, how much longer I have to live. I refused chemotherapy 'cause I don't like the idea of just postponing what's going to happen anyway.
That's the bad news. The good news is that I'm going to be around for a while yet ( I don't know how long ) so I can continue to work on it, answer questions, whatever as long as I am able.
I'll keep you guys in the loop and forward information as it come available. Cross your fingers and so forth.
Thanks again for your offer to help with the clone, by the way.
Wow.
Hope it turns out benign in the end. As you said, let's cross fingers.
Marc
So um.........SpecterX, if you still have your ears on I have an open letter for you :
You and I have been corresponding about the Clone, You have downloaded the code, you have gotten The Borland C++ Builder 6.0 compiler, you're just as capable as I am to write the clone.....why don't you take over the BATTLEFATIGUE project on SourceForge and continue onward with yourself as the project manager instead of me.
It appears that I have cancer and I'm going to die. I have an appointment on August 3, 2005 at the VA hospital here in Tucson, AZ, to see how big the tumor is ( if that's what it is ) and to see, roughly, how much longer I have to live. I refused chemotherapy 'cause I don't like the idea of just postponing what's going to happen anyway.
That's the bad news. The good news is that I'm going to be around for a while yet ( I don't know how long ) so I can continue to work on it, answer questions, whatever as long as I am able.
I'll keep you guys in the loop and forward information as it come available. Cross your fingers and so forth.
Thanks again for your offer to help with the clone, by the way.
Larry.
I know words kind of lose their importance in this situation.
First I am so sorry to hear that you are sick.
Second I do not know the type of cancer and I am not an oncologist, but cancer is not necessarily a death sentence. Many people survive after surgery and/or chemotherapy.
Third my best hopes go out to you and your family.
Take care and keep fighting.
Rasmus
Dicke Bertha
30 Jul 05, 08:29
That is terrible news Larry.
I hope for the best for you and your family.
Larry,
Lately half of the post I read are written by you. And they are always positive, happy and joyfull. It is very sad to see one where you are down.
Like the rest of the guys said, I hope it all comes out ok.
larryfulkerson
30 Jul 05, 10:14
Larry,
Lately half of the post I read are written by you. And they are always positive, happy and joyfull. It is very sad to see one where you are down.
Like the rest of the guys said, I hope it all comes out ok.
Thanks for the kind words, ALL of you guys. I'm sure the best for me will happen reguardless of whatever happens. We always worry the most about the things that we can't do anything about anyway, right? You guys are great.
Hopefully it is not what you think it is, and if it is then I hope it is something that can be cured.
Ben Turner
30 Jul 05, 16:18
Sorry to hear your news, Larry. You've dedicated yourself with such energy to this and other projects recently and I really hope things aren't as bad as you fear so you will get to see some of it come to fruition.
larryfulkerson
30 Jul 05, 22:14
Thanks Ben and all you guys.
Larry, good luck with your results on Aug. 3. If it's cancer it can be beat. Hang tough.
The TOAW clone is an amazing endeavor, I can't wait to see it done and give you another game...maybe the Cubans can get across the river next time.
larryfulkerson
01 Aug 05, 01:02
Larry, good luck with your results on Aug. 3. If it's cancer it can be beat. Hang tough.
The TOAW clone is an amazing endeavor, I can't wait to see it done and give you another game...maybe the Cubans can get across the river next time.
Thanks dude.
larryfulkerson
09 Aug 05, 03:51
Hey you guys, I heard from the Dr. finally. I had to call HIM of course. The people who read CT scans said "no intercranial abnormalities found". My doctor said that while we can't rule out the presence of cancer, we can rule out the presence of detectable cancer. That was kinda good news / bad news. Mostly good I guess.
Anyway, I just wanted to keep you guys in the loop. It appears, at least for the moment, I'm winning. Funny thing is I don't feel all that much better about knowing, for some reason. Humans are such complex beings sometimes. Sorry just talking to myself ( again ).
Hey you guys, I heard from the Dr. finally. I had to call HIM of course. The people who read CT scans said "no intercranial abnormalities found". My doctor said that while we can't rule out the presence of cancer, we can rule out the presence of detectable cancer. That was kinda good news / bad news. Mostly good I guess.
Anyway, I just wanted to keep you guys in the loop. It appears, at least for the moment, I'm winning. Funny thing is I don't feel all that much better about knowing, for some reason. Humans are such complex beings sometimes. Sorry just talking to myself ( again ).
Glad to hear it.
Secadegas
09 Aug 05, 07:15
Sorry just talking to myself ( again ).
You shouldn't be sorry... you're a very courageous person and deserve all the best
viridomaros
09 Aug 05, 12:21
good luck with that larry
I can't get the "design.exe" to work, complains about missing config.dll file...? there is such a file in the directory though.
larryfulkerson
12 Aug 05, 18:33
I can't get the "design.exe" to work, complains about missing config.dll file...? there is such a file in the directory though.
I'll take a look and see can I fix this little problemo. Stay tuned for further news.
Okay.....I took a look. The problemo seems to be that the DLL's that come in the design.zip file need to be unzipped into the same directory as the design.exe program so that when you start up design.exe he will be able to find all the dll's he needs to function. These are three of them:
toawc_config.dll
scenario.dll
aboutbox_dll.dll
Maybe you're trying to execute an older version of design.exe. Try downloading the one living on the web site now and try it again.
you can download the newest version of design.exe from here:
http://www.the-strategist.net/~larry/design.zip
I tried it and it works when the three dll's are in the same directory.
Nope, doesn't work. Perhaps a problem with pathnames? Like with the graphic files(need to manually change to the Toaw directory)?
larryfulkerson
12 Aug 05, 22:26
Nope, doesn't work. Perhaps a problem with pathnames? Like with the graphic files(need to manually change to the Toaw directory)?
So um.......Karri Dude: Can you send me a screenshot(s) of the error(s) when it(they) happen(s)? Maybe you can email 'em with attachment(s) to larryfulkerson@hotmail.com and I'll take a closer look. Plus when I have your email address I can email you with attachments of a copy that works on my machine great.
I'm running XP Pro and SP2 and have no problemos, but then I'm logged in as administrator as well. Have you admin rights or are you just an ordinary user? Or maybe you're not running XP Pro. I heard that XP for Home Use has some kinda problemo with "third party" programs writing it's files to just any directory. And the file(s) have to go into My Documents somewhere.
Anyway.....looking forward to fixing this problemo.
I have unzipped it into my desktop, and it gives the following errors:
"Couldn't load the configuration DLL"
"Access violation at adress 00406363 in module 'design.exe'. Read of adress 00000000"
"Access violation at adress 7C9012B4 in module 'ntdll.dll'. Read of adress 00000586"
"Access violation at adress 00411F45 in module 'design.exe'. Read of adress 0000024C"
And when I shut it down, it gives this:
"Access violation at adress 32658819 in module 'CC3260MT.DLL'. Read of adress 0000064E"
I have admin rights, but not running XP Pro.
larryfulkerson
13 Aug 05, 11:26
I have unzipped it into my desktop, and it gives the following errors:
"Couldn't load the configuration DLL"
"Access violation at adress 00406363 in module 'design.exe'. Read of adress 00000000"
"Access violation at adress 7C9012B4 in module 'ntdll.dll'. Read of adress 00000586"
"Access violation at adress 00411F45 in module 'design.exe'. Read of adress 0000024C"
And when I shut it down, it gives this:
"Access violation at adress 32658819 in module 'CC3260MT.DLL'. Read of adress 0000064E"
I have admin rights, but not running XP Pro.
So do I assume correctly that you're running XP Home version? In that case try unzipping all the files into a directory in the folder C:\Documents and Settings\
something like :C:\Documents and Settings\Toawc\
for example and see if the error(s) are at least different.
The reason I suggest this is that XP Home has a problemo with "third party" programs writing to folders other than the ones the user "owns". And usually users "own" only those folders that are in C:\Documents and Settings .
Just now I moved the absolute latest version of design.zip out to the web site and it's the one I've been working on this morning and I know it's working ( at least for me ). You can get it
here: http://www.the-strategist.net/~larry/design.zip
it's about 2MEG bytes big 'cause it includes mostly everything you'll need to run it and it took me about 30 seconds to download. I say it includes mostly everything you'll need because I haven't included the HUGE map I've been playing with that's about 17 MEG bytes big by itself. ( I wanted to make sure design.exe will play nice with large game maps you see. ) All you need for a game map is ANY *.bmp file. Proferably a map of a game but actually the program knows it only by the type, which is *.bmp and so ANY *.bmp file will work the same as any other ( so far ).
vBulletin® v3.7.0, Copyright ©2000-2008, Jelsoft Enterprises Ltd.