Hey Angelo... CSPL!

DarthVeda · May 9, 2003, 15:08

What would it take to get CSPL to run with Multiplayer Gold Edition? I'd be happy to help you work on this in whatever way I can this summer.

yaroslav · May 9, 2003, 16:43

I'm also for it --- I think that the Java classess I built for Civ2Dip could be a good fundation to do it

EDIT: Note that Java will be not suitable for doing 'low-level' things like those requiered for exactly cloning CSPL at MGE

Cyrion · May 9, 2003, 17:40

Wow guys, that sounds more than interesting!

yaroslav · May 9, 2003, 17:53

In fact, I've discuss this idea with another fellow that also was working on Java and Civ2

He has a lot of good ideas. I hope he will come to this thread and post them here

Cyrion · May 10, 2003, 07:10

BTW Yaroslav, don't forget Civdip with unit exchange!

Angelo Scotto · May 10, 2003, 08:30

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?

DarthVeda · May 10, 2003, 13:10

So why is it that CSPL only works with ToT (aside from the program checking that the user is running ToT)?

Boco · May 10, 2003, 15:57

Venturing an ill-informed useless guess, perhaps the targetted memory addresses differ. With the current state of the code, you'd have two challenges. Debugging it to get it to work smoothly, and finding and changing the addresses. I'm nowhere near your levels of expertise, but I've found that working with someone else's code is 'challenging'.

DV and Yaroslav, what sort of interface do you envision? CSPL has two associated hurdles: (1) it works only with ToT (some of us don't view that as a hurdle

), and (2) it requires a knowledge of C. If you don't get around that second hurdle, your user base will still be small even for a MGE version.

DarthVeda · May 10, 2003, 17:39

Why is everybody trying to splash cold water on this?

Boco · May 10, 2003, 21:38

Easy DV. It's a good idea. I'm asking about the interface because I'm greedy. Not proficient with C, I'm hoping for an interface or upper level macro language that I can handle. Despite its huge benefits, CSPL hasn't taken off because (IMHO) no ToT designer besides you can write subroutines with it.

Yes, you could port CSPL over to MGE with the same 8 or so example routines (debugged), but ultimately, CSPL directly ported to MGE would inherit the same disadvantage - only 10% (a guess) of MGE designers know C. So if a C-illiterate designer has an idea that falls outside of the examples, he'd be at a loss. On the other hand a more accessible interface/language could really make this a revolutionary tool. The number of users would expand hugely.

DarthVeda · May 11, 2003, 02:06

Can we do both?

Angelo Scotto · May 11, 2003, 04:07

Darth, the reason because CSPL controls your Civ version is the same described by Boco:
the main problem is that MGE is a different program, so memory offsets are different, the address where Tot place unit structure could be used by MGE to store other things or, even worse, to store binary code: the check is performed to avoid crashes, 'cause if CSPL start writing on a memory address where MGE keeps its code a crash is assured

Quote:

Originally posted by Boco
(1) it works only with ToT (some of us don't view that as a hurdle ),

Long Life to Tot !!!

Quote:

Originally posted by DarthVeda
Why is everybody trying to splash cold water on this?

Because it's a complex task! i remember at least two projects of people who contacted me saying they were going to port CSPL under MGE and both gave up soon while trying to find memory addresses under MGE.
I'm not putting cold water, i want just be sure that you understand the pandora's vase you're going to open

DarthVeda · May 11, 2003, 19:09

Is it very hard to find these memory addresses, I mean how did you go about doing it for ToT?

Angelo Scotto · May 12, 2003, 13:53

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 · May 12, 2003, 17:13

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...

yaroslav · May 12, 2003, 17:18

Quote:

Originally posted by Boco
DV and Yaroslav, what sort of interface do you envision? CSPL has two associated hurdles: (1) it works only with ToT (some of us don't view that as a hurdle

), and (2) it requires a knowledge of C. If you don't get around that second hurdle, your user base will still be small even for a MGE version.

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

yaroslav · May 12, 2003, 17:21

Quote:

Originally posted by Cyrion
BTW Yaroslav, don't forget Civdip with unit exchange!

I don't forget - I'm now busier than ever, and my few spare time is to be wasted on Civ2 scenaries and PBEMs

I'll end the next version as soon as I graduate and pass the FIRST test (Cambridge's test of english - very basic level, as you can see on my posts

)

DarthVeda · May 12, 2003, 17:26

Would it be so hard to write a text parser in the style of events.txt? Turning that into structs for C would be something I've never done before but I'm sure its possible.

For example, what if we come up with something like:

cspl.txt

and this contains a bunch of code in the style of events.txt but with some built-in CSPL events?

If the user is feeling ambitious, they could go in and manually add their own functions to CSPL like is done now.

The only thing I'm afraid of with the "dumbing down" of CSPL is that you would lose a lot of the flexibility that the C language offers.

yaroslav · May 12, 2003, 17:36

Yes, that is a idea we're thinking on - to write a parser is a common task for many programmers. I wrote one, one year ago, and I'm not a profesional programmer...

DarthVeda · May 12, 2003, 17:59

I've written many parsers but I don't think I ever had to do anything quite like generating "events," more like keeping counts...

yaroslav · May 12, 2003, 18:14

I think that it could be a hard-effort task, but not very difficult

Cyrion · May 13, 2003, 03:21

Quote:

Originally posted by yaroslav

I don't forget - I'm now busier than ever, and my few spare time is to be wasted on Civ2 scenaries and PBEMs

I'll end the next version as soon as I graduate and pass the FIRST test (Cambridge's test of english - very basic level, as you can see on my posts

)

No prob Javier!

And when you're done with CSPL, I'll gladly translate the interface into french!

BTW: in a few weeks, I might need your help for testing my first scen...

Angelo Scotto · May 13, 2003, 03:22

About the Macro Language thing:

I agree completely, when i talk about "making CSPL easier" i think exactly to a Macro Language, if you search in the archive you'll find an old thread with a lot of suggestion for a similar language, i started the development but i had to freeze it waiting for better times...
I have a draft of the language somewhere if you want to take a look at it

If you want to avoid the "dumbing down" effect you have to guarantee at least a couple of things:

The ability to declare variables.
The ability to extend it with libraries (not necessary dinamically, it simply means that the parser can be extended without changing the language syntax).

you could start coding a language-to-C converter, it may automatically compile it when pointed to the borland compiler executable and it should be easier to implement, then you can face the effort of realize a real interpreter.

Angelo Scotto · May 13, 2003, 03:26

About Civ2Dip:
It seems really interesting... may i browse the source?

yaroslav · May 14, 2003, 17:49

Quote:

Originally posted by Cyrion

No prob Javier!

And when you're done with CSPL, I'll gladly translate the interface into french!

BTW: in a few weeks, I might need your help for testing my first scen...

I'll be glad if I can help you with your scen... What is it about?

yaroslav · May 14, 2003, 17:51

Quote:

Originally posted by Angelo Scotto
About Civ2Dip:
It seems really interesting... may i browse the source?

Of course, but I don want to publish it here, so please send me an email to yaroslav25@yahoo.NOSPAM.es

without the NOSPAM, of course

Boco · May 14, 2003, 21:23

Quote:

yaroslav25@yahoo.NOSPAM.es without the NOSPAM, of course

I'll have to remember that spam deterring trick.

Cyrion · May 15, 2003, 03:04

Quote:

Originally posted by yaroslav

I'll be glad if I can help you with your scen... What is it about?

Thanks!

Look here: http://apolyton.net/forums/showthrea...threadid=48342

SCDARS · May 18, 2003, 07:58

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 · May 18, 2003, 16:24

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