DK used squared tiles and now I think they are better then cliffs. I waited months to start this project because I wanted to do it with cliff heights but now I changed mind. Terrain cliffs looks good in game only because they have a tons of variations, doing a single model wouldn't give a good result. And using more models would require too much space :|
The grab UI is not like DK because it would require the mouse movement/position check that comes with the 1.2.
Then I assume it can be used to make a unit follow the mouse pointer at a certain height, giving the visibility only to the owner. Unfortunately I think the result will be kinda laggy because the trigger need to be periodic.
I think I'll make some kind of units queue UI instead, to show what units you grabbed.
Just came to say that I will no longer be working on this project. Currently busy working on a new Risk Engine that, hopefully, will power Risk Revulsion in the nearest future.
Looks good so far and good luck Bibendus.
You may continue to use this thread as long as you like.
I completed the basic UI with the different panels and the keeper hand (pick, drop, slap).
Here is a couple of screenshoots, I'll prepare a video when the order abort command will be completed.
It's not a common strategic game.
Actually you can dig your dungeon to create special rooms. Each room has his purpose and additionally attracts creatures from a portal.
You can't directly control your creatures but they have a personal AI, you can just drop them on enemies or use a possession spell that allows you to control one of them at a time.
Haem yuka, did you ever play a Dungeon Keeper game???
It's not a tech-tree game or something that makes you create units from buildings... it's just... different!
Today I completed the wall reinforcement AI so now all dig/conquer/dig triggers work,
Now I'll work on the task aborting and then will start with the UI so I can start making room buildings and some basic spells like summon imp.
Yep but I mean another thing.
We are making a thread for each unit to search for the nearest tile right? That doesnt mean that each tile gets the nearest unit!
Sometimes then could happen that a really far unit is assigned to a tile instead of the nearest one. However the unit is going correctly to its nearest digging tile.
Today I completed the new custom made sight check. It works good but it's a bit heavy with 50-100 units forcing my computer to make small freezes every 0.5 seconds.
With less units it works great so I will keep it as it is for now.
Now I'm focusing on the wall digging with face occupation check. It usually works but sometimes I get all workers trying to dig the same spot, checking what's wrong ;)
Edit:
Whoa I did it :D
However we are making a mistake working with imps threads because each imp searches for the nearest dig tile, however a dig tile doesn't receive the attention of the nearest imp.
I suppose i must switch the thread to the dig tile instead of the imp.
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.
I'm not creating threads... its the engine that uses threads for while and for loops :|
And I must use them shitz :|
Edit:
Found the problem!!!!
My sight check script creates a unit in each, tests if the unit is visible and then remove it.
It seems that unit creation and delete in a for loop makes the engine angry!
I suppose I'll need to rescript manually the sight checking as I was going to do in the future.
The task abort system works like a charm, today I should be able to make the video ;)
Edit:
And it's finally out :)
http://forums.sc2mapster.com/resources/project-workplace/15581-hive-keeper-dungeon-keeper-mod/
@ZealNaga: Go
DK used squared tiles and now I think they are better then cliffs. I waited months to start this project because I wanted to do it with cliff heights but now I changed mind. Terrain cliffs looks good in game only because they have a tons of variations, doing a single model wouldn't give a good result. And using more models would require too much space :|
The grab UI is not like DK because it would require the mouse movement/position check that comes with the 1.2.
Then I assume it can be used to make a unit follow the mouse pointer at a certain height, giving the visibility only to the owner. Unfortunately I think the result will be kinda laggy because the trigger need to be periodic.
I think I'll make some kind of units queue UI instead, to show what units you grabbed.
Why did u stop? Risk < DK :(
I almost completed the task abort system so this week-end I should be able to release the vid
I completed the basic UI with the different panels and the keeper hand (pick, drop, slap).
Here is a couple of screenshoots, I'll prepare a video when the order abort command will be completed.
Random units places
Grabbed and dropped some units (stun effect)
Slapped the poor hydralisk
Changed tool and selected terrain to dig
Changed UI panel to show the upcoming build menu
@yukaboy: Go
It's not a common strategic game.
Actually you can dig your dungeon to create special rooms. Each room has his purpose and additionally attracts creatures from a portal.
You can't directly control your creatures but they have a personal AI, you can just drop them on enemies or use a possession spell that allows you to control one of them at a time.
It's... different :D
For mor infos:
http://en.wikipedia.org/wiki/Dungeon_Keeper_2
@yukaboy: Go
Why should we use tons of imps versions? That's not the kind of game, really :|
I'm asking again, did you play DK before?
@yukaboy: Go
Haem yuka, did you ever play a Dungeon Keeper game???
It's not a tech-tree game or something that makes you create units from buildings... it's just... different!
Today I completed the wall reinforcement AI so now all dig/conquer/dig triggers work,
Now I'll work on the task aborting and then will start with the UI so I can start making room buildings and some basic spells like summon imp.
Yep but I mean another thing.
We are making a thread for each unit to search for the nearest tile right? That doesnt mean that each tile gets the nearest unit!
Sometimes then could happen that a really far unit is assigned to a tile instead of the nearest one. However the unit is going correctly to its nearest digging tile.
P.S.
I'm still on IRC ;)
So how does your trigger behave? Each wall gets the nearest imp or each imp gets the nearest wall?
Today I completed the new custom made sight check. It works good but it's a bit heavy with 50-100 units forcing my computer to make small freezes every 0.5 seconds.
With less units it works great so I will keep it as it is for now.
Now I'm focusing on the wall digging with face occupation check. It usually works but sometimes I get all workers trying to dig the same spot, checking what's wrong ;)
Edit:
Whoa I did it :D
However we are making a mistake working with imps threads because each imp searches for the nearest dig tile, however a dig tile doesn't receive the attention of the nearest imp.
I suppose i must switch the thread to the dig tile instead of the imp.
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 ;)
@redmarine: Go
It should be around 1000.
Else how can you make a thread for each unit's AI?
I'm not creating threads... its the engine that uses threads for while and for loops :|
And I must use them shitz :|
Edit:
Found the problem!!!!
My sight check script creates a unit in each, tests if the unit is visible and then remove it.
It seems that unit creation and delete in a for loop makes the engine angry!
I suppose I'll need to rescript manually the sight checking as I was going to do in the future.