Red Front for ToT

[McMonkey]

Thanks Aggie

[Colwyn]

TOT events for Redfront

With redfront for TOT in beta which really is just a process of deciding what unit stats, units and other changes need to be made before releasing it as redfront 1.45 perhaps! lol

In any case it would be good that in the meantime that some people work on events code for tot that 'could' be used in tot for redfront.

Many of these i've already introduced in my Red front versions for Civ3 and Civ 4

For example I have in mind to start with :

When key cities in the west are taken ie Kiev/Minsk it triggers the move soviet industry to the urals, this would be done by a terrain replacement effecting factories much like how it works with the allied bombardement affecting germany in RF late in the war.
Say 15 factories disapear from the west and appear in the urals!

I would like to know if anyone else would like to work with the group on these that has knowledge of RF and events in TOT?

[Colwyn]

Worth considering

Originally posted by Boco
If you end up with extra slots, why not use them as unique triggers for events? I'm sure he-who-has-a-game-named-after-him could make a few suggestions in this regard.

Additional events i think are critical for using TOT to better RF and the limitations we faced at the time.

For example how about we keep one unit slot free for a hitler unit in berlin that when killed disbands all the volkstrum units for eg.

Q. Has anyone compiled a detailed list of the new codes and features that TOT brings?

[Boco]

Aide-ToT @ Eyn's World contains MacroToT.txt, which looks like an efile of the manual.

I'm a little tight on time and forgetful of RF events to be of much help. Perhaps if you have a very specific problem, I could lend a hand.

Agricola frequently mentioned it'd be nice to have events specific to Stalingrad and other mini-campaigns (Leningrad?). Would trigger units help here as well as Berlin?

[Colwyn]

Perfect

Thanks boco its just what I was looking for, ive had a look and seen a few new possibilities compared to civ2 mge, won't be hard to create the events we need at all.

I esp like the delay possibilities that create a bit of randomness in scenario's, adds to replay value a lot and continuous as well (;

but for tot it states

There is approximately 100 Kb of "heap" memory dedicated to events

what was it for Civ2 MGE ?? i hope it was far less!

[Boco]

IIRC, it's about a 1/3 of ToT's amount. Check Catfish's Cave - Versions of Civ2. There's a minor gotcha about delay modifiers. I'll post when I find it.

[Boco]

Another Catfish reference

From Catfish Cave

About Delay and DelayPerFlag modifiers: From my experience with these, my advice would be to use them sparingly and with caution. Each time a Delay or DelayPerFlag event is called, it is loaded into the memory space shared by all other events. Each delayed event takes up 276 bytes in the .sav file and requires 284 bytes in memory. Repeating Delay/DelayPerFlag events can very quickly eat up your remaining events memory as each stacks up an additional 284 bytes. To avoid problems with these modifiers in your scenario you'll need to calculate the maximum possible number of concurrent Delay/DelayPerFlag events and multiply this figure by 284. The resulting value must not exceed the remaining heap space, as calculated by the events debugger, otherwise there exists the potential for some delayed events to simply not load - although I guess if none of them are game critical, it may not matter.

Not having read the entire Macro.txt document for a few years, I discovered this the hard way (which includes plenty of obscene language). Shortly after figuring this out I stumbled on these lines at the end of the document:

"In addition, delayed actions (those using the DELAY modifier) create countdown timers that also take up memory space. If your delays pile up and you run out of memory because of it, the scenario won't crash, but any delayed actions that don't fit in memory will not ever take place."

Sigh...

Addendum (6/08/2004): Man, it certainly pays to read all of the text files, doesn't it? This time from the 1.1 patch readme:

"For events files, the Debug file (report.txt) now includes the amount of stack space left for your use. Please note, however, that this total does NOT include the stack space needed by DELAYed events. Each DELAY adds 284 bytes to the space used. Overlapping DELAYs (those whose counters could be running at the same time) add up, but those that do not overlap do not-- i.e. they can re-use the same 284 bytes."

This would have saved me a lot of grief. If there's any consolation, at least I know I was right on the money.

[Colwyn]

Progress comrades

How we going with attaching the new graphics to the scenario comrades?

Once thats done we need only complete the normal unit/events text files and were done I believe for the initial release.

I've done draft new events for TOT for us to consider to make the scenario even better which include:

- Relocation of industries to the urals.
- hitler script which disbands some units
- Destruction of the Dnieper dam
- Use of random and delay to slightly change when a event occurs and in what square it does to add to reply value and keep the player on their toes.
- adjusted events to make the german attack on stalingrad and 'citidel' real.
- use of inf troops on both sides more pronouced, rather than tank flood.

[curtsibling]

I'll press on and get the 1.4 GFX upgrades done this weekend!

[MacGalleo]

@Curt
I look forward to this GFX update.

@Colwyn
If some people work on different files at the same time, it would be more prudent to have someone who coordinates all, as MacMonkey had suggested. For example, I has already changed Events files... If someone else makes changes without coordination, this will cause problems ...

[Colwyn]

No worries there, the events I have in mind guys are ones that "could" be added in at a later stage of development once our normal release is out as they will require a bit of playtesting before we consider adding them to a possible 2nd release of RF for TOT

curt, are they going to be *.spr gfx files?

[MacGalleo]

If Agricola agrees, after the first release (gfx update) I suggest he coordinates the project for the redux release(He would be the ultimate playtester too).
At first, I think all his reflexion about this project is an excellent base to begin this project.


@Colwyn
You know well redfront in the different versions. Your ideas are more than welcome.
Perhaps Agricola could send to you the files he sent to me.
And what do you think of a release of your version (1.5) in tot before the redux version. It would be interresting to have the 3 versions.

[AGRICOLA]

@ MacGalleo

1. Colwyn already has the OPSUM. He's had it since he released RF 1.5 so he knows about what works well and what doesn't, as well as the ways some of his house rules can be circumvented without actually breaking any of them.

2. I'm not a designer and have absolutely no experience in fitting together the many intricately interlocking pieces that make up a scen. Thanks, but I'm definitely the wrong person to coordinate this project. How about you doing it, seeing as you are the moving force behind the revival of this long dormant project?

3. I would be happy to thoroughly playtest whenever and whatever needs testing.

[curtsibling]

[SIZE=1]curt, are they going to be *.spr gfx files?

Fairline is handling the units GFX (very pretty too!) and my new terrain will be static bitmaps...

I have not the time to create dozens of frames of sprite animations, both summer and winter!

Perhaps if I had a team of animators and a spare year!

[Colwyn]

@Colwyn
You know well redfront in the different versions. Your ideas are more than welcome.
Perhaps Agricola could send to you the files he sent to me.
And what do you think of a release of your version (1.5) in tot before the redux version. It would be interresting to have the 3 versions.

- i'd be happy to do that, that way ppl can asess it and see what they think as well.