Why is saving not a reality for CTI/RTS?

[Rune 0]

Here is what I know about it so far, mostly from posts on this forum by Crashdome from Sinews Of War and some from my own experiments... I have learned surprisingly little searching the forums, which I admit could be me not finding rather than posts not existing...

Everybody is always complaining about not having 'join in progress', especially for CTI and RTS. I've also heard many people complain that there is no campaign play in multiplayer. And then there is the problem of long co-op missions where you cant go back to the lobby to pick up people because it means starting all over... All of which might actually be possible.

Saving information from one multiplayer game to the next IS possible no matter what is said officially.

I'll take the optimistic point of view by assuming that all the problems can be fixed eventually - If anyone knows why any of this will not work please say so and why...That'll save us all some time.

I know that this will never be 'perfect' to the degree of saving snapped trees, bullet holes and dead bodies lying at the same place, position and with same equipment present. But how important is that really? Could we reach something acceptable between that and restarting a CTI after 2 hours?

These are the answers I have:

The way it works is by exploiting the fact that some scripting commands that according to BIS do not work in multiplayer, actually do work - the useful one is saveStatus. saveStatus saves various pieces of information about a unit...Normally this is how the singleplayer campaigns remember stuff from one mission to the next, but it will not work the same way in multiplayer because only a few bits of it still work there. Damage can be saved, so can skill, but since super AI sets ALL skill to 100% that erases the data you are trying to save - leaving only damage really useable. Damage is stored as a real-number value ranging from 0-1 - which can easily be made to hold a positive integer up to 999999. SOW uses logic units to store data, but it should be possible for any unit.

Check out Sinews Of War which as far as I know is the only thing out there that has any of this implemented.

I'm looking for answers to questions like these:

-Most importantly! Why has this not been done - Is it impossible?

-Do logic units slow the game when used for this?

-Is there a limit to the amount of data that can be stored?

-What is the best way to load and save?(most efficient)

-How would you encode vehicle types?

-Encoding someone being mounted in something?

-Encoding text(not that I know why it would be needed)?

-What other things might we need to save?

Anyone who has any facts on this please post them here to make them availabe in one place.

...Anything else?

[korax 4]

This is impossible, Savevar and Savestatus go into the objects.sav file of the campaign. This cannot be used in multiplayer because the missions are treated as seperate campaigns - all data is lost while going from one mission to the next.

In OFP there is no way to save a variable to an external file not to mention loading the variable. (In VBS there is though.)

I'm curious as I could be wrong... Why do you say it is possible to load a variable from one mission to the next? Have you or anyone else actually done it?

[RN Malboeuf 12]

canna be done admiral

[Rune 0]

Korax:

Yes I have done it. I say what I say because that is all I know so far  

Don't take my word for it, see it for yourself. I made these example missions(save/load stores and retrieves position and facing of jeep, and nothing else), you can save in either of the two test missions and then load in the other and you can turn off your computer and load again later( ):

Example mission

It works like this(jeep x-coord only to keep it simple):

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">SETUP:

Logic unit named 'R_memory1' exists.

Jeep - named 'R_jeep' exists.

SAVE:

var1 = (getPos R_jeep) select 0;

R_memory1 setDammage (var1/1000000)

R_memory1 saveStatus "R_mem1";

LOAD:

R_memory1 loadStatus "R_mem1";

var1 = (getDammage R_memory1)*1000000;

R_jeep setPos [var1, y-coord, 0];

The above is a variation of code suggested by Crashdome.

[MrZig 0]

Wow!

I initialised it, saved the jeep's position, exited OFP, re-launched OFP, went into the other savetest mission, (all multiplayer), and it went to the same spot that I saved it at!

Edit: And to go further, you could savestatus a logic at say a certain dammage in one mission, and that was according to how many.. LAWs you have.

On the next mission, you could loadstatus the dammage and calculate how many LAWs you should have!

[korax 4]

Cool, I guess this would be possible in some coops, however an RTS or CTI scale mission would require such heavy coding and so many logics I really wonder how it would affect game performance.

You would need enough logics to cover all the major aspects of every vehicle, so that would mean damage, position X, position Y, position Z, ammo, direction, maybe even velocity.. and in a mission with up to 200 units.

But... This could possibly be done serverside by having one master logic only placed in the game, and having the server camcreate additional logics for every unit. On the mission load the master logic is queried for how many sub-logics there are and they are created with the same names as always, and then the proper amount of variables are loaded and set in play around the map.

I'll stop blabbering now, if you want more of my opinion on it you can PM me or something  

[cain2001 0]

Well what is possible is to script a code string.

Say west side have 5500$ and 2 m1a1s and 3 jeeps, and towns number 4,6,8,3

the code would then be 5500,2000,30,4,6,8,3 = 55002000304583.

When you start a new CTI, you type in this Code string in the field and it will auto add tanks,jeeps,money, towns to that side. Sure everything wont be perfecly exact but most things!. This line could also be monitored by Spectators.

Would be cool when some guys get good at it and can decide everything from this code line "36344574568749563240346425759867305468724598672309467236089476246845634096"

What is even more intressting is that its possible in CTI to track on a PHP scriped stats site for each player, and count how many times he blown up MHQ, Lightfactory heavy ect ect. This could be really cool to compare skills.

[AgentFox2 0]

Hey, guys. I'm glad to see that there is still some interest in Sinews of War!

Although SoW is really CrashDome's baby, I'll see if I can help out with some of the questions until I can point him to this thread. I'm just a small part of the team, and I definitely don't have the technical skills that Crash does, so whether or not I can be of help might be debatable.

Quote[/b] ]I'm looking for answers to questions like these:

-Most importantly! Why has this not been done - Is it impossible?

It's possible, and it's been done. We were originally planning a large multiplayer coop campaign, and I still may release a few SoW-capable missions. But Crash went and pooped himself out coding it all! So, at the moment, the future of the project is unknown. However, if you head on over to the OFP Script XChange you can find the latest source files to create your own SoW-capable missions.

Quote[/b] ]-Do logic units slow the game when used for this?

There is some slight slow-down during saving/loading, but that's about it, I believe. You're standing still when it happens, anyway, so no one's missing much. Crash will correct me if I'm wrong, but I think most of the lag we encountered was mainly due to the large number of units on the map.

Quote[/b] ]-Is there a limit to the amount of data that can be stored?

I'll have to defer that to CrashDome, he's the technical genius. But as far as I know, there is no limit other than what you can do before your head explodes!

Quote[/b] ]-What is the best way to load and save?(most efficient)

Again, I'll have to defer to Crash's technical know-how.

Quote[/b] ]-How would you encode vehicle types?

Crash, where are yah, buddy?

Quote[/b] ]-Encoding someone being mounted in something?

Now, as far as I know, that can't be done. We had some problems with the weapons/vehicle saving if one of the players/AI were inside. For one, you couldn't purchase weapons and assign them to the unit if he were mounted. I think that this is a limitation pertaining to the way in which OFP handles vehicles within the client-server process.

Quote[/b] ]-Encoding text(not that I know why it would be needed)?

I'll probably have to give Crash this one, as well, but I do remember that we had some issues with saving strings. Whether or not Crash ever found a way around it, I don't seem to recall.

Quote[/b] ]-What other things might we need to save?

Almost anything you like! We had a lot of ideas bouncing around, from location ownership to local arms dealers inventory to the amount of space available for a supply drop. Most of it is possible, the hard part is sitting there and coding it all out.

I hope I've been of some help. I think Crash will be a lot more helpful, though.

[crashdome 3]

This is impossible, Savevar and Savestatus go into the objects.sav file of the campaign. This cannot be used in multiplayer because the missions are treated as seperate campaigns - all data is lost while going from one mission to the next.

In OFP there is no way to save a variable to an external file not to mention loading the variable. (In VBS there is though.)

I'm curious as I could be wrong... Why do you say it is possible to load a variable from one mission to the next? Have you or anyone else actually done it?

Hasn't anyone learned anything about OFP yet? Anythings possible!! ;)

Anyway, saving data in MP has been done. AgentFox there and several of my buddies have played SOW and saved information from game to game having one of the best experiences of OFP has to offer (or 'unofficially offer'). It is not impossible but does require alot of work. We've also been doing this for several years.

SOW was basically an interface between a custom data table and the object.sav file through the use of saveStatus. (and a very poor one I'll admit - I've learned so much since the beginning that I admittedly could have made it better)

I will attempt to outline, however, what I've discovered and what can and cannot be done about it. Note: I only used saveStatus because that seems to be the most usable.

A. saveStatus will save both damage and skill as Rune pointed out.

1. values range from 0-1 with truncation on loading to six decimal places (meaning 0.1234567 will load as 0.123456)

2. values are placed in an object.sav file located in the players OFP temp directory.

a. this file is used for all MP games and therefore can be accesed by any mission

b. drawback is there is only one file (per player name)

3. values can only be read by the same name as they were saved and there is currently no way to read all the names in the file during run-time (so saving as "MyVar" will only affect missions that are coded to load a value from "MyVar")

B. Loading is best done before breifing.

1. It causes a delay during the mission loading screen (Black "Receiving..." screen) but for it's benefits - it is like Heinz Ketchup - worth the wait

2. Otherwise lag will be introduced in-game due to increased disk access from loading (It can and will stall a dedicated server for several seconds if done in-game)

C. Best practice to prevent cheating (modifying data in object.sav) is to save and load campaign information directly to server

1. This requires a stable way to transfer values over the network such as "CoC Network Services"

2. Dedicated servers are best choice for this.

3. Players cannot jump from server to server with data unless data is mirrored to client machine's object.sav file

D. Any type of data can be saved.

1. Integers can range from 0 to 999999 or as signed integer from -499999 to 50000 (or even -999999 to 0)

2. Real numbers as 0 to 1 keeping the idea that values are truncated during load times to six decimal places

3. Boolean (0 or 1)

4. Strings can be saved using CoC_NS and utilizing there functions but this would be highly cpu intensive so strings are not ideal.

E. Game Logics are ideal for this.

1. I created a single game logic dynamically and as I Iterated my variables, I changed the Name of the logic to the variable name and changed the damage and skill level to the appropriate value and saved it. Same for loading...

2. Game Logics never die whereas other units do so changing damage to 0 might cause them to become a null reference.

F. Binview was the program that helpe me discover what can and cannot be saved. CoC has produced an even more enhanced version of binview and might provide an excellent management tool for the object.sav file.

There is other data that may be saved but the loadStatus command will not load it. You can verify data using the binview program I mentioned from The Chain of Command.

I hope this helps everyone. I spent 2 years on SOW and it really never took off because of all the new features in each patch had me rewriting the code for either better reliability or better functionality. I suggest anyone interested not to pass up the amount of work I put into this concept and download the source from www.crashdome.net/ofpsx . I also have a demo mission to show the effects of loading and saving.

The last status of SOW was beta and was about 99% complete. I disabled some saving features to test other functions and simply requires someone to go in and alter some code to get it to work fully. Keep in mind that this was before the "superAI" bug was discovered so do not use superAI when playing with it. I have almost abandoned my work because I could not keep up with the advancement of all the other wonderful discoveries others had made. For example CoC_NS is on version 2 and is by far much better than the 1.2 version I used in SOW. Also, there was very little interest at the time because Add-Ons were the thing of the season and script enhancements weren't given a second glance if it required alot of work to get a mission together.

In conclusion, I am always available to help out in this area with the knowledge I have gained and I'll even offer SOW to anyone (or any team) who wants to take it over. I have a website already and I'll keep paying for it if anyone wants to manage the project. I, unfortunately, cannot put the 100% of blood and sweat into it like I did in the past. The source itself is completely open as outlined on the OFP source exchange and anyone can use it as long as they give me a brief blurb of credit for the idea.

I don't come around here much anymore, so email is best way to get ahold of me. www.sinewsofwar.com has an email address there.

CrashDome

Sinews of War

*putting MP save criticizm in it's place* ;)

[nubbin77 0]

As someone who used the SOW tools for a while, simply put, the work Crashdome did was astonishing. I cannot fathom why more people did not jump on this or try to add to it. Also, for all its complexities, it was surprisingly easy to work with and modify.

I could go on about it but my wife is bitching about something...

[Rune 0]

I have looked into this and have learned many things about it recently, so let me just sum up my knowledge on the topic so far...please add to it if I am missing anything.

Facts:

- Performance.

Using logic units that are created and then deleted again after use - no logic units are required to be present during play. Performance will suffer only while saving and loading - NOT while playing!

- Maximum amount of data that can be saved.

There seems to be no direct limit other than the time you are willing to wait...On my PC(AMD2400+/266DDR) ~3000 real numbers would take ~5min, on a powerful server - obviously a lot less. And that would be enough to save position, facing, speed, altitude, ammo, damage and fuel for ~375 units in the straight forward way of one number in each logic unit saved...but then you wouldn't even need speed, altitude or fuel for a soldier unit. The only big problem is that the filesize determines how long loading and saving takes, so two different saves of 3000 real numbers each would about double the time...that makes cleanup a must or at least the use of some standard names to save to so CTI/RTS games overwrite each other rather than increase the filesize.

- It cannot be done perfectly.

There are some things that cannot be done as far as I know, especially with weapons and ammo there will be problems. One problem is lack of a way to learn what weapons and ammo are inside an ammo crate or a vehicle cargo. Or the ammo left in an AH64, rockets will probaby be switched for hellfires and that sort of thing because only a total ammo count is saved.

Other potential uses(bit fantastic, but just maybe...):

- It might be possible to track players, keeping data clientside(possibly some checksum or somesuch on server to verify/anti-cheat measure). Data such as scores, ratings or number of times 'voted TK-master of the game' - whatever you want could be kept and displayed during intros and such. Maybe a scripting mod like ECP could use it to have that work for all missions...stats of player comes up when spectating

- Completely new forms of CTI/RTS could be developed, ones lasting longer with more long term strategy involved...you could make it so you only win after winning a combination of games across several islands, bringing resourses along to the next one every time.

- Custom loadouts(a fairly simple one to make I suspect), how about having those stay for more than one game at a time.

- 'Codestrings' - It would not make sense saving directly as codestrings(like those suggested by cain2001), it would only slow it down. But they might help in some form of data compression scheme to either help speed up loading or allow more data to be saved.

- Compression

The slowness of loading with many entries in the objects.sav file can be helped somewhat if less where used for the same amount of data. I mean there is really no need to use 6 digits for saving damage is there?

How to learn about it:

Best way to learn how to do this in practice is to pick up Crashdome's SOW beta-demo, take it apart and play with it. It can be found at Sinews of War.

Remaining questions:

- Does anyone know of a way to find out what is inside an ammo crate or vehicle cargo by using scripting commands?

- Can the exact number of remaining eg. hellfires on an AH64 be determined by scripting commands?

- And sending data over the network to many clients, like with CoC's Network Services how much time would it take to transmit ~3000 values on a full CTI-server? - how big a problem would it be compaired to the mission file download?

[Rune 0]

I heard someone say that you can start a dedicated server without a Users directory and that this means it could not work on dedicated servers...Now I knew it works on dedicated servers already, but I didn't know if it still would after removing the Users dir - so I tried it and it does work, the server just creates the directory as it starts up.

That got me thinking about another thing, does savestatus saving and loading work the same on Linux servers?

[Pathy 0]

Wow this is really good work man!

Keep it up!

[gandalf the white 0]

from the unknown a new OFP limit is about to me broken .

since i'm in a coop clan this means very good news for me ( untill AKM realises it doesn't hurts to show up ON TIME! )

[General Barron 0]

I read about the work SOW did on saving with MP a while ago, and while it is very interesting and exciting, it seems odd to me the stuff you guys want to save with it... But let me explain.

It seems overly complicated and intense to expect to save, for example, the status of every vehicle, object, etc on the map of a CTI or other large game. I guess it sounds like crashdome has already done it, but personally, I can only imagine how much of a PITA that would be to code... That also might be the reason this isn't used, even though it is possible. Like many things, I think it would be best for someone to start small with this idea.

For example, a mission could be made where a dynamic series of battles is fought, one in each mission. The next battle would depend on who wins the battle, and what key locations they seize. You wouldn't need to save the status of units, just who won, what locations they captured, what strategic buildings they destroyed, how many tanks are left for each side, etc. Then, in the next battle, the number of units each side would get would depend on those cumulative results from all the previous battles. However, the location and status of each unit would be "fresh".

I'll bet if a mission or two that just made a simple use of the save feature were made, then there would be an explosion of interest in the technique.

[crashdome 3]

General Barron, you just described exactly what SOW does in the latter half of your post. SOW hasn't ever, nor will ever, save the status of every object (let alone ANY actual object) on the map. I thought I stressed that monumentally on my first website and in several posts!

I'll admit I stressed you could save the status of certain AI units, but it is a much simpler version than what you are thinking.

Please read a simple synopsis on the new home page:

http://www.sinewsofwar.com/home.php

Here's a simple run-down of what is *possible* to save in SOW (I say possible because you can pick and choose)

* Inventory for each side of weapons, ammo, and vehicles (Number of em only, not status of each and every one!)

* AI Units (This was my own personal option) It allows you to save units skill and damage levels as if you had a personal squad of soldiers under your command. Each would have a unique name and not randomly generated every mission. EDIT: To clarify, imagine having Jim, Bob, and Erik as your AI squad mates.... On the first mission, Bob got wounded and never healed so he's at 0.2 damage. They all were standard Res soldiers. Well, next mission, you go to the barracks and ask for Jim and Bob, but leave Erik behind this mission to train and get another 0.1 added to his skill. This mission is Covert Urban, so you have Jim and Bob join in with civilian outfits instead of their normal Res uniforms. Oh, and Bob is still bleeding....

* Locations and who owns them (Also used to 'pull' or 'store' vehicles)

* Money (if desired)

There are numerous other features available but most of em are UIs and work-arounds to OFP bugs that pop up.

Now, I will admit my first demo of SOW 2 was a rotten potato of a mission, but Rune has done much needed improvements to SOW and the demo mission. I play tested his first 'alpha' release last night and I had much fun. I don't want to pressure him and try and estimate the amount of time before official release of the demo, but I can say it will be soon. The source code is pretty well rounded out and I think would take about 10 minutes to convert a standard mission into an SOW mission unless grave amounts of add-ons are used. Then it might be a bit longer

Can I count on you (Gen Barron) to at least give it a go when it comes out?

[crashdome 3]

After having written the above post, I thought I should also clarify some things about SOW and it's relation to CTI/RTS missions... since this is the topic.

SOW was built around co-op play because that is my forte, BUT I fully designed it to be a possibility for team vs. team type missions including CTI mostly. It does not currently simulate RTS style play in that you cannot 'build' structures. You can purchase items/vehicles and even have a pool of AI to choose from. However, dead AI units will remain dead until the game is 'reset'. So if you have only a pool of 50 units, well... be conservative if it is a long game. Additionally, units/items/vehicles not accounted for at time of save will not be saved. What this means if I put 50 RPGs in a 5-ton truck cargo area and throw it into inventory, they are lost. I must (as a player) first extract those RPGs into inventory THEN add the 5-ton truck. This is due to OFP limitations - not SOW limitations. Also, if I have a unit flying a helicopter 50 miles away and 'save' the game.. it will not be accounted for. This is due to the fact that SOW requires vehicles to be parked on a valid location. As you expressed, saving all units all over the map would be an extreme PITA and thus, SOW does not currently do that.

You can use SOW effectively in a CTI or RTS type map, but serious rules regarding when it is appropriate to 'save' must be taken. Most likely, all players must pick a point in which the mission is declared "over" and return to owned locations to park their vehicles and goodies. Then a save can be performed effectively.  There are other possibilities you can use via additional scripts and such to work around trying to get players to stop the mission and might become standard as SOW progresses. One idea might be the use of a script that enforces a 'teleport' of all units to nearest location for a debreif of sorts and doesn't allow them to leave. I never fully addressed these issues because they were never a priority for me, but if demand and interest are high enough, it can and will be addressed.

[General Barron 0]

Quote[/b] ]General Barron, you just described exactly what SOW does in the latter half of your post.

Lol... sorry. Obviously I was a little... unclear on what exactly SOW was all about. Honestly, from what I saw on your old website (last time I checked), I thought that it was basically a CTI-esque scripting mod. Then from all the discussion here and on another thread about saving CTI, and saving the postion and direction of jeeps, ammo counts, etc, I kinda got the wrong impression.

Now, from what you have written, and what I've seen on the homepage of your new site, I think I understand better what SOW is all about. Actually, now I'm also wondering why there don't seem to be any MP "campaigns" using this system... maybe everyone was just as confused as me about the whole thing. Was SOW always about this MP saving, or was that just a recent development?

Quote[/b] ]Can I count on you (Gen Barron) to at least give it a go when it comes out?

Definately... I can think of lots of good uses for it. Only problem is, ATM I know almost nothing about MP editing :P. So I have to get that figured out before anything else. In the mean time, I'll be sure to paruse your site and see what you're up to.

[Rune 0]

I think the confusion is my fault, at least when it comes to saving the jeep position and that, the problem I guess is that I now have a SOW avatar, I did not have that when I started the thread...I had never even talked to Crashdome at that time ;)

This thread really exists because I had decided to work to make a dynamic cooperative campaign, but felt that I might as well keep the information I was gathering easily available to someone wanting to work on CTI saving, something I would also like to see but which I realized I would never find the time to even begin working on.

You are more than welcome to post in the SOW forums, as are any mission makers who wants to give SOW-mission making a go. Tell us your ideas on the forum and we'll guide you through the process of learning to edit SOW missions, we can also help with most other multiplayer editing issues, if you are not familiar with that.

[crashdome 3]

I really think SOW never took off because by the time I got it polished and ready to be used as a script mod, there was hardly anyone making missions. In fact, about the time I gave up, the Mission editing comp wasn't even an idea yet. Otherwise, I may have even submitted a mission using SOW. Let's hope this surge in mission making provides a few individuals willing to tackle this idea.

Anyway, for the non-mission makers, SOW will have some basic missions designed by the SOW team that can be played. (Maybe even a campaign?)

[nubbin77 0]

I made several missions using the first version of SOW that was released. It was fairly easy to manipulate once you got the hang of it. Although I would get some oddball errors every now and then, but I don't know if they were the result of using other scripts that conflicted or if I had just typed somthing incorrectly in one of the scripts. Never a show stopper though.. I'm excited about the new release especially w/ CoC NS 2 and the (possible) dialogues in missions.

[Rune 0]

Benu was just nice enough to let me know that saving and loading also works on linux-servers...Which I was still unsure of...so thanks Benu

[Rune 0]

Interesting development, Hermano has made a beta CTI save upgrade...this is from the MFCTI forum.

Quote[/b] ]Hi, as already stated in the other thread I found the time to script saving and loading.

Now following data is saved/loaded:

- Game options

- Scores

- Cash, also buildingvalues (commander), vehiclevalues and infantryvalue per team

- Workers

- Starting positions (not by coordinates, but by index of cti-startingpositions, so after loading a different map you will be on valid positions, not somwhere in the ocean)

- Cityownership (by index also, so you will also get cities if you load on a different map), Resistance will not spawn in owned cities after loading

- It is checked if valid data exists before loading

This makes up a complete first saving function, which should be useful already. It tested it with some games and everything worked fine. I ported it to Malden, had a short look and it worked fine, too.

The next step would be the saving of buildings instead of just the values. I should have a look if loading them will interfere with the ai-scripts. then infantry and vehicles could be saved, too, instead of the values. I don't really know when I'll find the time to do this, I'm sorry.

I would really appreciate it if somebody would test it and told me if it worked fine on their system, too. You can email me to lhc(at)weedmail.com.

I also added a short tutorial how these scripts could be added to other cti versions.

To run cti44beta you'll need:

http://www.informatik.uni-bremen.de/~cordes....ate.rar

and also, unless you already have it:

invasion44

ftp://www.gamezone.cz/ofpd/invasion44/DemoV1-2Full.exe

cti44beta addons

ftp://www.gamezone.cz:8021/ofpd/_hosted/cti44/%40cti44.zip  

mfcti1.1B

http://prdownloads.sourceforge.net/mfcti/MFCTI1.1BCoopEveron.zip )  

That's it,

hermano

EDIT(21/2-05):

Also from the MFCTI forums, post by In1t:

Quote[/b] ]I have finished the scripts for saving and loading structures (here is a test cti44 mission http://cti44.fifthelement.net/files....den.zip ). All structures, from barracks to sandbags, are saved and loaded except for ammo/weapon crates. The structures positions and directions are saved. Dammaged buildings are not saved. In the testing I did walls and sandbags were aligned correctly after loading. Like with the units there is a delay before the loading begins. Structures are ready for immediate use after loading (no "build time" required).  

There are still a few minor issues that need to be worked out (ammo depot crates are not positioned correctly). I did some tests on a dedicated server (linux) and the load/saves seemed to work correctly. More testing still needs to be done.

CTI44 is slightly different than MFCTI, but it should not take much effort to change the load/save scripts to work with vanilla MFCTI. There were some minor alteration to the build scripts in MFCTI. 95% of the changes were to BuildStructureServer.sqs (most changes related to bypassing additional position/direction calculations done by the script)

[thy_raven 0]

i know this is a really old thread, but is there any more news on the ability to save CTI games? all the links don't work anymore.

[vipermaul 246]

Yes. This information is invaluable.

Any more research would be appreciated.