 |
|  |
 |
|  |
 |
|
Angelo Scotto
|
|
Milan, Italy
Oct 1999 time: 05:28
|
|
I don't know Darth...
I know that there is a lot of people out there interested in a similar conversion but is it really worth?
Currently i don't have enough time to work on CSPL, but even with time, my priorities would be to make CSPL easier and less unstable, not to convert current buggy version from Tot to MGE.
I can't release the source code 'cause it's a mess with a lot of italian comments (i said this before, i just can't find the time to clean it) and so i think it would be pretty useless.
Who knows, maybe this summer i'll find the time to clean the code but i can't assure it to you.
quote: Originally posted by yaroslav
I think that the Java classess I built for Civ2Dip could be a good fundation to do it. |
Tell me more, it works on save files, right?
|
|
|  |
 |
|  |
 |
|
Angelo Scotto
|
|
Milan, Italy
Oct 1999 time: 05:28
|
|
First of all you need to find a good memory dumping program, it's not necessary to have also a full debugger such as SoftIce even if a couple of times (map and attack sections) i used it.
When i made Tot version i used Memory dumper pro, but it was shareware with a time limit and so, even if i found it very good, i realized a quick prototype of a dumper (just a prototype since it had a couple of unlabelled buttons and crashed often).
Fortunately you don't have to use my dumper since it seems that Memory Dumper Pro's author lacked interest in it and made it freeware, so you can download it from http://www.ptsware.com/
Then you have to start MGE, to load a scn game and to open the SCN with an hex editor, you choose the data you want to find, and ask MDP to find that pattern in the memory, the size of the byte string you choose is important: if it's too small you'll have hundreds of matches while if it's too long you can't find it because MGE will probably split it upon SCN load.
I found that a good approach was to search "logically" joined entities: all data from a single unit is ok, all data from a single city is ok, a set of bytes of the initial session (the first block in scn) is ok also, since Civ (Tot, but i think also MGE) loads all the initial configuration data in the same place.
Then you have to check that the data you find is the data you were searching, so you have to change it at runtime and to check the game to see if it changes coherently.
Find all addresses of entities in the SCN file format and you're ready to start coding the library...
|
|
|  |
 |
|
yaroslav
|
 |
Madrid, Spain, Europe
Jun 2001 time: 06:28
|
|
quote: Originally posted by Angelo Scotto
Tell me more, it works on save files, right? |
Yes, the program is based on load the saved files and does the change in its structure... I've used the HEX-EDIT in Civ2 document a lot, and I've discover minor details about the structure of the saved games that were not in the document (I opened two or three threads about that topic, but they die.... )
Basically, whenever a player wants to do a exchange, it load the program, select the kind of exchange he/she wants. The CivDip main program then build a barter file, that can be read again in the receiver's side. If the reciever of the barter accepts it, the Civ2Dip program modifies the save file in order to reflect the changes that both players have agreed about...
|
|
|  |
 |
|  |
 |
|  |
 |
|  |
 |
|  |
 |
|  |
 |
|  |
 |
|
SCDARS
|
|
quote: Originally posted by yaroslav
I and other civ2 buddy* have thought about it, and we agree with the 'C' part: we want to do an interface easier to use. In fact, we were speaking about a events language that extends the Civ2 Original. What do you think? And you, DV?
* I'm going to send him a email so he can post here |
I admit I am the one mentioned here. As you can see, I don't post here that much (with just 0.13 posts/day within 3-4 years I can almost compare to Angelo ) since my time is limited, too. I discussed some points about a kind of extended macro language with yaroslav I wanted to quote here, but the emails were deleted during my recent HD repartitioning. 
One of the main design decisions would be the choice of the programming language, since it seems that java principles of security and platform independence could make direct access to ToT memory near to impossible. So the players could be forced to reload the save game regularily, if Angelo can't present us a better idea. (I have never used "native code", could this help?) On the other hand, jaroslav's object-model of the save game for civ2dip is already tested and running fine with MGE saves. So an events language based on it would have a solid and wide groundwork and the main task would be implementing the parser. And although I have not tested it yet, Java 1.4 seems to have introduced support for regular expressions, which could render the task of writing an advanced events parser a lot easier for those familiar with regular expressions (and there would be no need to make the events file xml-compatible as proposed in the other thread).
|
|
|  |
 |
|
yaroslav
|
 |
Madrid, Spain, Europe
Jun 2001 time: 06:28
|
|
quote: Originally posted by SCDARS
I admit I am the one mentioned here. As you can see, I don't post here that much (with just 0.13 posts/day within 3-4 years I can almost compare to Angelo ) since my time is limited, too. I discussed some points about a kind of extended macro language with yaroslav I wanted to quote here, but the emails were deleted during my recent HD repartitioning. 
One of the main design decisions would be the choice of the programming language, since it seems that java principles of security and platform independence could make direct access to ToT memory near to impossible. So the players could be forced to reload the save game regularily, if Angelo can't present us a better idea. (I have never used "native code", could this help?) On the other hand, jaroslav's object-model of the save game for civ2dip is already tested and running fine with MGE saves. So an events language based on it would have a solid and wide groundwork and the main task would be implementing the parser. And although I have not tested it yet, Java 1.4 seems to have introduced support for regular expressions, which could render the task of writing an advanced events parser a lot easier for those familiar with regular expressions (and there would be no need to make the events file xml-compatible as proposed in the other thread). |
Interesting idea: all the program could work in Java but the direct memory access part, that could be programmed in C and used as 'native code'. This way, if anyone wants support for MAC, he/she must only rewrite the C part. But, on the other hand, I have never used native code 
|
|
|  |
 |
|  |
All times are GMT. The time now is 05:28. Apolyton Time is 00:28. |
top of page
|
| archivepost |
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|