SC2Mapster

Quote from Forge_User_20974461: Go

For the worker's digging order script I see you didn't occupy slots for each wall side so all zerglings try to dig the same spot even if they can't. I made this check using custom unit variables but when i was trying to test my trigger with a huge amount of units I found the sight check bug (too many threads) so I'm forced to fix it before giong forward with the digging.

P.S. You should join SC2Mapster IRC more often ;)

Well, I just haven't added that condition yet due to the fact I've only tested the system with 3-4 units.

Quote from Forge_User_20974461: Go

@redmarine: Go

It should be around 1000. Else how can you make a thread for each unit's AI?

I don't. I decided to ditch it. If the limit is 1000 then I might as well thread them and make the creature AI threaded as well.

Haven't had time to work on the map for a while. Been busy at school working on projects.

Anyhow, it seems like the performance of my AI has improved quite significantly. Used to be around 50-100 with only 4 back in the old days.

50 workers here. http://i236.photobucket.com/albums/ff147/ep1309i3/Screenshot.png?t=1288621820

Quote from Forge_User_20974461: Go

I feared that, i didn't want to use more units cause i already use them for wall pathing and gold resources. however it seems better then just cycling all the tiles of the map :D

Well, this isn't an issue for me due to the only blocks having dummy units are blocks that are accessible by foot. This means no dummy that are ot of reach. However, unclaimed paths have dummy units though they're limited to one block away from the claimed ones. Claimed paths don't have dummy units because I don't really have any use for it.

So no issue here on my part. It seems to work really well.

Quote from Forge_User_20974461: Go

0 I will use a slightly different method. I already store in the huge array the confinant tiles to reduce greatly the amount of calculations to just the interesting tiles. I'll use that to create the dummy unit and recreate it on near tiles when it is destroyed (if needed)

The thing is that you still need path blockers. Yeah, you can create your own path blockers but it can require even more variable memory, depending on implementation, so I simply decided to utilize the path blockers from the dummy units so it's not really an issue on my part.

Bed time.

Quote from Forge_User_20974461: Go

I don't know how is your left available memory space for variables on your map but I reached the limit with the big 128x128 tiles struct array :| Try to predict now the variables you want to use in the future if you don't want bad surprises :D

Well, my map is 64x64 blocks so I use half the memory you use. I'll make sure to keep track of my variable usage.

Quote from Forge_User_20974461: Go

For my AI I still didn't decide if looping toward all tiles to check what must be digged out is a good idea, did you save your digging tile coordinates somewhere or you just loop all tiles every 0.5 secs for each worker?

Let's take claming a path as an example. Due to cycling points coordinates being hugely resource demanding I decided simply to create hidden dummy units above these unclaimed paths, just next to claimed ones, and added all of them into a 'unclaimed' unit group variable. This way, I could simply loop through all picked units and find the closest one. What's funny is that this isn't resource demanding.

So to the practical usage of this method.

A worker figures out that unclaimed path exists, the closest unclaimed block is then sent via parameter to a custom action. The worker is then added to the unit group Worker[player][x][y]. (x,y being the location of the closest block)

Now, the custom action checks for these conditions:

• Worker[player][x][y] is empty.
• The Worker is within 1 range of the block.

If the worker suddenly disappears then the thread is broken and the block is reset. However, if the worker got to the block then wait 2 second and the path is claimed and the worker has to start again.

Hopefully you got an idea on how it works, also take a look at my AI image a couple of pages back.

Quote from Forge_User_20974461: Go

I smell MINECRAFT!!

Been thinking about it, maybe.

Quote from Forge_User_20974461: Go

If u can find the camera position you can find the correct point in the trajectory at the height of the wall. My walls have a height of 3 so I do some maths to get the point at that height in the trajectory between the cam position and the clicked point.

The green blocks are units that get created ONLY if some player has selected the tile. Then I share their vision to all players that selected the single tile. Do you mean I can use just unit actors or u were talking about units?

And how is your progress going?

Figured that was the only possible solution. I might look into it later down the road though because if I'd have to implement it I'd have to make it work from all angles.

Well, on my part I'm progressing steadily. I'll just list them here:

• Taking advantage of records (thanks for telling me about them) to organize the code a lot more.
• Better AI code and they're now able to dig, claim paths, and reenforce walls.
• Incorporated the build feature, the UI hasn't been implemented yet but trigger wise it works.
• Can sell structures
• Getting someone to make me a block model. Not entirely sure when but I'll most likely get it within 1/2 weeks.

Some stuff I haven't done yet would be my own custom sight system. This is due to an actor issue. Looking into it later.

I've probably forgot some stuff but that's essentially it.

Quote from Forge_User_20974461: Go

Today i finished the wall dig selection with perfect camera aiming

Now i'm starting with the AI ;)

Just wondering, how can you make it perfect? Sure it'll select all walls within the co-ordinance but it won't be like you can click on the actor edge of the block and select it if the camera isn't on top of it.

If so could you share your methods? Would be interesting.

EDIT: You made sure to make those green blocks are unit actors so they're hidden from other players right?

@Abion47: Go Well, I haven't played this map yet but if you truly intend to realize Devolution you can forget all about the ships. Trust me, they're simply not possible. The Air pathing system just sucks so much that it's not even funny.

A suggestion, Africa's terrain looks quite boring, you should spice it up a bit.

Quote from Colt556: Go

@Keyeszx: Go

The internet is a vast and wonderous thing where you can find anything and everything, for free no less. I hate Bnet and the way Blizzard treats one of the major components of it's fanbase. But they DID make a good editor, so may as well utilize the thing they did right, while boycotting the thing they did wrong.

Which is illegal and you should be banned for somewhat advocating piracy.

The panel was poorly handled and they didn't address a lot of trigger related issue but just art and logic. Kinda made me die a little inside and the people who asked obvious and already answered questions were retarded...

Quote from progammer: Go

@crazyfingers619: Go

There's another interview before that panel and blizzard is like saying "WTF Valve, what are you doing ? We love your games but WTF ?"

And yeah this is a direct bash at Valve when they focuses on updating dota in the long run

That was Rob Pardo one of Blizzard's oldest veterans. This will be an epic showdown.

Quote from SycoPrime: Go

@redmarine: Go

Whenever I have to do massive data editor stuff like that (many units, etc.), I tend to cheat. If I can get away with it, for example, I'll put all the units in an array and catalogfieldvalueset the units at the beginning of the map.

Nobody recommends it, but if you think it would work for you, I could whip something together for you. After all, better to cheat and get it done than not get it done at all.

Not entirely sure what you mean so could you explain it a bit better or make a small demo?

Quote from Forge_User_20974461: Go

@redmarine: Go

Yep, more or less. How did u manage the revealing thing? You pre-placed terrain, right?

Well, I didn't know of that particular bug until just now when you discussed. In all of my builds it's the minions that reveal the areas. I'll be trying to implement the above method but I'm so bad at the data editor, got to remove all line of sight, that it's almost sad so I won't be doing it anytime soon.

Yeah, the terrain I haven't messed with, except for digging the dungeon heart holes.

Quote from Wolf1322: Go

Couldn't you use a trigger along the lines of:

Unit enters any region, reveal area in region at triggering unit?

Nah. I assume he used a map generator to create and store regions across the map and then reveal the area around a specific tile using some sort of loop. That's what I've got in mind.

EDIT: Well, that's one way to trigger the code to reveal an area.

@Roguegfh: Go

Here I thought someone was planning on making a MineCraft map...

Anyhow, it's lots of fun when playing multiplayer.

Quote from Forge_User_20974461: Go

Oh ok, so you are threading units AND tiles as I said :D

Yeah. They're only threading as long as they're idle.