ETW Runtime Memory Stucture Documention

[T.C.]

Attrition System, proper Supply Lines and something else you can think of^^

Attrition is all that's guaranteed so far. And it's going to take a long time to design, any concept I've came up with so far would add a massive loading overhead. But I'll work on efficiency later As for supply lines, we've met a stumbling block. Things like ammo, unit defence values, reloading skill (i.e. static data that doesn't really change based on play) are stored in one common location for all units of the same type. So any change to, say, French line infantry would effect every single unit of French line infantry in the game. We're considering re-routing the memory to our own custom addresses, in order to assign these stats on a unit-by-unit basis. But there's a lot of issues with that, not least of all game stability. Hopefully we'll come up with something

[Dynamo11]

Either way it shows even more promise that the modding community is continuing to unlock the Warscape engine. Nice work Mitch and T.C!

[risorgimento]

I'm certainly no expert of campaign systems, but imho all these kind of changes shouldn't really be programmed in Lua. Lua was embedded in TW games for scripting purposes, not for storing or "fetching" at runtime megabytes of texture data, per-unit. That's beyond its skills and I guess you'll quickly reach a dead-end street in terms of performances. There's the serious risk to waste a lot of time...
I repeat (and I'm sorry for annoying) it's quite "sad" to see many brillant modders and their ideas constrained to Lua's implementations. Unfortunately Craig didn't replied yet about my proposal for a ETW/NTW code injection "permission". Anyway I think it remains the only practicable way to improve noticeably these games and keep them alive nowadays. We should definitely put some pressure on CA to obtain one statement on the subject at least... in whatever direction.

[.Mitch.]

I'm certainly no expert of campaign systems, but imho all these kind of changes shouldn't really be programmed in Lua. Lua was embedded in TW games for scripting purposes, not for storing or "fetching" at runtime megabytes of texture data, per-unit. That's beyond its skills and I guess you'll quickly reach a dead-end street in terms of performances. There's the serious risk to waste a lot of time...
I repeat (and I'm sorry for annoying) it's quite "sad" to see many brillant modders and their ideas constrained to Lua's implementations. Unfortunately Craig didn't replied yet about my proposal for a ETW/NTW code injection "permission". Anyway I think it remains the only practicable way to improve noticeably these games and keep them alive nowadays. We should definitely put some pressure on CA to obtain one statement on the subject at least... in whatever direction.

Yeh you've missed the entire thing we are trying to do here I think, lua doesn't even have the capability to access memory.
We also don't need CA's permission to edit runtime memory.

extract the borders of the ETW map, on a texture file with the size of the etw map (so the coordinates are 1:1) and then simply paint over some colours, which mitch tool can read (eg. red = high attrition etc)?

Nail on head!

[Flikitos]

Hi guys!

Because of the 4 seasons ability, NTW is played by most of TW fans who can not come back to a 2 season per year. That is why I make you the proposal of the 4 seasons per year for ETW.

So first of all we have not yet the ability to put the NTW effects like pollen or leaves which cross the screen during a battle, we have however the possibility to add NTW environment (what I did for the summer and winter seasons for IS 2.2).

What I discovered about the two "new" seasons from NTW:

Spring: is not really a season, I mean that it is a real season but there are no difference between Summer and Spring, it is just the climate which change (more rain probability) in NTW. It is an interesting thing we would probably take care. Autumn: it is a real season really near to winter because of the tree's textures changes during those seasons. Also Autumn has its own skybox and environment.

Some db_tables really interesting for 4 seasons

battle_terrain_sets: One of the most important db_tables, it allow to the game to know which skybox, (and so environment), trees textures, for each specific battles. battle_sky_types: it assign a specific sky for each season. battle_climate_weather_descriptions: A description of the interaction between climate and season about the weather probability seasons: The indispensable table which allow us to create a new season. Something creepy is that I do not know what is the utility of the numbers in the last table (Summer=1; winter=2; Spring=0 and Autumn=0 ==> So the number do not show us the fact that which season happens after an other ) warscape_trees: Interesting table which show the tree's model which can be used for a specific season. That is all for now.

Some interesting links

Isabelxxx work on 4 season mod: http://www.twcenter.net/forums/showt...=328722&page=2 x2 x4 x8 for Elections: http://www.twcenter.net/forums/showthread.php?t=342605

Some interesting things

Climate map per seasons (we need to use on of those so as to have one for the two new seasons): Summer: Winter:

What do you think? If you made some interesting finding please tell me.

[PietroMicca]

No Flikitos. There aren't climate maps for season. It is an old mistake.

Land Climates Map

Spoiler Alert, click show to read: 

Sea Climates Map

Spoiler Alert, click show to read: 

I corrected that mistake after 4 hours

http://www.twcenter.net/forums/showt...0#post10786570

[.Mitch.]

I actually plan on using a coloured coded map within our Season-Location based attrition system.

PietroMicca, do you have an current and correct climate maps in a high detail that also preferably relate to ingame coordinates? haha

[PietroMicca]

I actually plan on using a coloured coded map within our Season-Location based attrition system.

PietroMicca, do you have an current and correct climate maps in a high detail that also preferably relate to ingame coordinates? haha

what do you mean with ingame coordinates?

each colors is a climate
and boundaries in those maps are from regions.esf

[.Mitch.]

Well the plan is that we'll compare a units ingame coordinates on the campaign map to a colour map of the land to see where they are. That's how we'll be able to set what areas are areas of attrition, etc. If you see what I mean.

[PietroMicca]

Well the plan is that we'll compare a units ingame coordinates on the campaign map to a colour map of the land to see where they are. That's how we'll be able to set what areas are areas of attrition, etc. If you see what I mean.

do you mean coordinates in runtime memory?

in esf file is already possible

[.Mitch.]

Basically in my program, while it's running it will know the coordinates of any given unit. Now when I have these coordinates I need something to relate them to that can hold the information about what areas of the map are "areas of attrition".

For example: Currently there is nothing to say that deep into Russia is an area of attrition.

Hence the system we plan to use to implement attrition will be to use a map (an image file) that we can relate the coordinates to, to be able to tell the program where areas of attrition are and thus compare them to a units position and apply the attrition if the unit is in the areas.

Thus I need a map that accurately has plotted climates etc, and more importantly can be related to ingame coordinates. I could use any old random world map from google, but if I plot a units coordinates onto that obviously it won't mean anything or be at all accurate.

[PietroMicca]

Basically in my program, while it's running it will know the coordinates of any given unit. Now when I have these coordinates I need something to relate them to that can hold the information about what areas of the map are "areas of attrition".

For example: Currently there is nothing to say that deep into Russia is an area of attrition.

Hence the system we plan to use to implement attrition will be to use a map (an image file) that we can relate the coordinates to, to be able to tell the program where areas of attrition are and thus compare them to a units position and apply the attrition if the unit is in the areas.

Thus I need a map that accurately has plotted climates etc, and more importantly can be related to ingame coordinates. I could use any old random world map from google, but if I plot a units coordinates onto that obviously it won't mean anything or be at all accurate.

We can do the contrary. Give me coordinates of these units. I will plot for you on the climates map.

[.Mitch.]

It won't work like that, I don't think you're understanding what this is, all of this needs to happen while the game is running; the process is like this:

My program starts and runs alongside the campaign while the game is running -> End turn -> Every units coordinates are sent to my program -> Program compares units coordinates to a map with climates -> All of the units inside areas of attrition are effected by attrition by the program

[PietroMicca]

It won't work like that, I don't think you're understanding what this is, all of this needs to happen while the game is running; the process is like this:

My program starts and runs alongside the campaign while the game is running -> End turn -> Every units coordinates are sent to my program -> Program compares units coordinates to a map with climates -> All of the units inside areas of attrition are effected by attrition by the program

I do not understand what connection there is between climates and attrition? Attrition largely depends on groundtypes.

[.Mitch.]

Well the climate in Russia will be one of harsh colds in Winter, the climate of another place will be different etc.

I don't know what a groundtype is or why what type of ground a unit was on would effect it's attrition.

I was just wondering if you had a map that could relate where areas of attrition might be to a map is all.

[PietroMicca]

Well the climate in Russia will be one of harsh colds in Winter, the climate of another place will be different etc.

I don't know what a groundtype is or why what type of ground a unit was on would effect it's attrition.

I was just wondering if you had a map that could relate where areas of attrition might be to a map is all.

But to have this kind of map I have to highlight groundtypes areas subject to attrition. I have never done a map like this. I can do it easily, but it will take some time. I have done time ago climates maps from Napoleon. What should be the format of this map? You need a particular size?

[.Mitch.]

High detail, preferably something like a .bmp. Pixel colours for areas would need to be all the same that's the really important part. So if there is a groundtype that represented an area of attrition in Russia for example, it would need to be a patch of a certain colour, and that colour would need the same RGB throughout the patch.

As for sizing, and I think this is the really hard part. If a unit was stood on the farthest left coast of france on the map and his ingame coordinate was say -157, with 0 being the center of the map, 157 pixels to the left of the center of the .bmp would need to also be the coast of France.

If you can't do it, it's really not a big problem, I was just wondering if you had an image like this. I'm sure map making isn't your specialty.

[PietroMicca]

High detail, preferably something like a .bmp. Pixel colours for areas would need to be all the same that's the really important part. So if there is a groundtype that represented an area of attrition in Russia for example, it would need to be a patch of a certain colour, and that colour would need the same RGB throughout the patch.

As for sizing, and I think this is the really hard part. If a unit was stood on the farthest left coast of france on the map and his ingame coordinate was say -157, with 0 being the center of the map, 157 pixels to the left of the center of the .bmp would need to also be the coast of France.

If you can't do it, it's really not a big problem, I was just wondering if you had an image like this. I'm sure map making isn't your specialty.

Europe map from Napoleon is inserted in this coordinates system: -410, 340 for x and -190, 195 for y.

So do you want a map 750x385 pixels? or pixel with coordinates 0,0 should be necessarily the center of this image? I can do even proportionally larger. png is not a good format?

This is for instance Europe map from Napoleon

Spoiler Alert, click show to read: 

point 0,0 is highlighted in red at the intersection of the axes according to regions.esf

Now, you want me to make an image where this red point is in the center? Then you want me to remove all black boundaries and highlight attrition areas for instance in green?

[.Mitch.]

So do you want a map 750x385 pixels? or pixel with coordinates 0,0 should be necessarily the center of this image? I can do even proportionally larger.

I take it that the warscape coordinate system uses 0,0 as the center of the map? If so then an image with 0,0 as the center as you showed for the NTW map, any size image is fine, larger means we can have more detail.

png is not a good format?

Png is good, any high quality image format is fine.

Then you want me to remove all black boundaries and highlight attrition areas for instance in green?

Yes if you can, remove black boundaries and plot where the areas of attrition would be, based on the most realistic data you have, such as groundtype.

[PietroMicca]

there's only one problem .Mitch.
there are 3 different groundtypes for 3 types of attrition

you want me to highlight each type with a different color or it's not important to distinguish type of attrition?