Author Topic: Outpost 2 Coding 202: Part 1 (Read 30566 times)

evecolonycamander · « **Reply #50 on:** April 21, 2011, 07:08:05 PM »

Quote

Don't expect to get a rectangular spot for your base. Expect other shapes. Don't do exact calculations. They're too time consuming. Count the number of passable tiles and expect that they have a shape that supports a base (not taking into account terrain formations for defense). I might add a function for this or part of it to the pathfinding class that I am writing.

well i expect that, but i want the bare minim, cause i know that all playable maps have a possibility of expansion. i assume that a functioning base(one that can survive without further reaserch) is a CC, SF, CS, 2 agris, nursery, university, VF, 2 tokimacks, 1 mine, 1 cargo truck, and 1 convec.
now in order to find a spot for the base of that minimal size the AI has to recognize the size of each individual building and not over lap any more then a single square. the CC and agris both take up an aria of 4x5(includes bulldozed spots) so we must calculate a separate aria for each without overlapping anything other then bulldozed spots. same for the other buildings.

sorry for the way this is posted. kinda tired.

jcj94 · « **Reply #51 on:** April 21, 2011, 09:03:30 PM »

Its the smallest shape I could fit everything into.
I'm sorry for it being a rectangle then... but it WAS the smallest configuration, with minimal space left out. It actually had some small areas and this way we can use area formula tofigure out an approximate mean for bases.

The area is 564 tiles, give or take a few.
Use that.

TH300 · « **Reply #52 on:** April 29, 2011, 05:13:59 PM »

I am making progress. Right now the code that I wrote will find the closest mining beacon to a given location. It will be no big deal to extend it to find more than one beacon or other simple things (like magma vents and fumaroles). I can also extend it to find all reachable terrain (if we really need that functionality).

So far the little status update. It may take a while before I continue work on this (probably till June or longer).

The question that needs to be answered now is, where do I upload my source code?

Edit: another question that I almost forgot: does someone have a list of movement speeds on different celltypes? Or know where to find those values in the exe or sheets or maps? I did measurements for some, but its too boring.

evecolonycamander · « **Reply #53 on:** April 29, 2011, 09:27:21 PM »

Quote

Edit: another question that I almost forgot: does someone have a list of movement speeds on different celltypes? Or know where to find those values in the exe or sheets or maps? I did measurements for some, but its too boring.

numbers, no.... but i can probably(mind you, i've got more important tasks at hand) get you some rough estimates based upon a couple of my modded maps and teks.

Hooman · « **Reply #54 on:** April 30, 2011, 03:10:18 AM »

Quote

does someone have a list of movement speeds on different celltypes? Or know where to find those values in the exe or sheets or maps?

004DEBA8

Or check "Data CellTypes.txt" in the internal info package. Each terrain type has a list of values for various track types. Something along the lines of movement delay for tracked, wheeled, geo cons/robo miners, legged, and blight movement. I'm not sure of the exact meaning or order. There are 8 values associated with each terrain type. The first 5 are almost certainly for vehicle track types, while the second last entry I believe is for blight growth.

jcj94 · « **Reply #55 on:** July 04, 2011, 07:39:47 PM »

Okay, after having been gone for most of june (FML!!) I realize this hasn't gotten very far.

Anyone have any progress to report?

I've been tinkering with the maps (the default ones at anyrate) and looking at the expansion rates and such with a simple freeplay mission code that I just change the map filename.

Some maps (Piechart being one) are a little... difficult to expand in, where as others are Nowhere near so.

TH300 · « **Reply #56 on:** July 07, 2011, 05:01:58 PM »

I did some more work on the pathfinding algorithm (which does a uniform cost search). It is currently capable of finding mining beacons. It is supposed to exactly simulate what op2 does.

Here is an image of a graph produced by the algorithm:
(sorry, I was too lazy to add the mining beacon to the image. Its not in that excerpt, anyway)

Hooman · « **Reply #57 on:** July 07, 2011, 10:55:35 PM »

Nice representation. The paths look smooth too. No zigzagging. Did you add path weight to account for the turn delay of vehicles?

TH300 · « **Reply #58 on:** July 08, 2011, 05:54:35 AM »

The costs used in the algorithm match the number of ticks that it actually takes a unit to move along the calculated paths. That means, vehicle turns are included in the calculations.

Still missing:
- considering day/night for calculations
- doing everything for not a single vehicle, but for a group of (probably different) vehicles
- considering damage (this will clearly only change the outcome if more than one vehicle is moving)

Not sure if I'll ever find it necessary to add all of those.

jcj94 · « **Reply #59 on:** July 13, 2011, 07:17:56 PM »

Quote

The costs used in the algorithm match the number of ticks that it actually takes a unit to move along the calculated paths. That means, vehicle turns are included in the calculations.

Still missing:
- considering day/night for calculations
- doing everything for not a single vehicle, but for a group of (probably different) vehicles
- considering damage (this will clearly only change the outcome if more than one vehicle is moving)

Not sure if I'll ever find it necessary to add all of those.

Second one, not so much, but DEFINATELY day night... I'd hate to have something think that because this is CLOSER to a mining beacon, its faster, but I don't have a light beacon near or around one of the specific paths, making it actually slower to use for attacking/ mining/

Hooman · « **Reply #60 on:** July 14, 2011, 02:10:40 AM »

I'm not actually sure a light tower would have any effect on movement speed. I know vehicle headlights have an effect, but I've also noticed vehicles still move at half speed with their headlights off during full daylight. Thus, I doubt light from a light tower will affect their movement speed.

jcj94 · « **Reply #61 on:** July 14, 2011, 05:32:15 PM »

Really? I thought they did :?

Hmm... Well if they don't that doesn't seem logical at all. I don't understand how a vehicles headlights should be the only light values taken into account.. it seems a simple enough thing to do, checking weather the tile has a specific light value..

:/ Well, I guess those wouldn't really be needed?

Flashy · « **Reply #62 on:** July 15, 2011, 07:37:22 AM »

I was surprised, too. I'm not an expert, but I think you can't check for light on a specific tile, as there isn't a variable for saving light in the op2-internal map tile structs:(From HFL)

Code: [Select]

// Extended map tile used in GetTileEx / SetTileEx
struct MapTile
{
	unsigned int cellType  :5;  // Cell type of this tile
	unsigned int tileIndex  :11;	// Mapping index (tile graphics to use)
	unsigned int unitIndex  :11;	// Index of unit on this tile
	unsigned int lava  	:1;  // true if lava is on the tile
	unsigned int lavaPossible	:1;  // true if lava can flow on the tile
	unsigned int expand  	:1;  // true if microbe is expanding to this tile
	unsigned int microbe  :1;  // true if microbe is on the tile
	unsigned int wallOrBuilding	:1;  // true if a wall or building is on the tile
};

Light is probably purely visual. Checking for (pseudo code) if(unit.HasLightOn()) or if(DayTime(Unit.Location())) is faster than searching all nearby tiles for a light tower. Don't rely on this, I don't know the mechanics of op2.

TH300 · « **Reply #63 on:** July 15, 2011, 09:12:16 AM »

By taking a quick look at the comments that I wrote months ago, I found that light will only influence movement if neither vehicle lights are on nor the daylighteverywhere bool is set for the map.

If light is considered, only daylight position is considered. Daylight position is used to retrieve a light-value for a cell (from a table) and movement costs are than multiplied by that value and divided by 32.

Hence, its a rather simple calculation that I'd have to add.

Hooman · « **Reply #64 on:** July 16, 2011, 07:12:57 PM »

From what I remember, there was some kind of light lookup table that had one entry per tile column. It was only a 1D array, so not suitable for full 2D light calculations.

When drawing the screen, I believe the visible portion had some 2D array. It was probably initialized using the 1D array, and then updated based on the light radius of units. I believe this 2D array was only really valid for the visible portion, and hence not suitable for calculations affecting game engine results. You wouldn't want to game to go out of sync because two players were looking at different areas of the map, or to have the game respond differently because you looked somewhere else.

Edit: Also, I remember something about blight growth always being affected by day/night, even if it's not enabled. That was a little strange.

jcj94 · « **Reply #65 on:** July 17, 2011, 02:51:48 PM »

Quote

Edit: Also, I remember something about blight growth always being affected by day/night, even if it's not enabled. That was a little strange.

Yes... I remember this to..

I'm wondering if Op2 treats the blight as a vehichle in that respect?

But TH300, if you DO decide on using light values, that WOULD be a nice addition to the game!

I'm actually going to try and make a random map gen that WORKS somewhat, but that requires mild knowledge of different 'noise' functions.. and some more C

If I can get it to work, maybe we can make some good missions and test the AI on them?

News:

Author Topic: Outpost 2 Coding 202: Part 1 (Read 30566 times)