When you get los on a unit/building and then lose los, you get this transparent shape where you saw the building.
Now I would like these shapes to be attackable, like normal units.
(atm rightclick on the transparent shape results in a move order)
To be precise it is for mineable minerals: those can not be "always visible" because then you can see where enemy players are harvesting resources just by seeing the minerals lose health/shrink smaller.
If minerals obey normal los rules, it is annoying that you first have to get los on them before telling a miner to harvest.
So I want it to be basically like in starcraft where you could see minerals everywhere and when you got los on mined-out minerals, they would disappear.
Ideas:
1) each mineral gets a fake unit (one per ally team) linked with it, lua makes it visible for the players as needed.
2) transform move-commands given at mineral-ghosts into attack-commands with screentrace mouse coordinates bla and manually setting tooltip etc.
Both seems pretty meh and I also vaguely remember something similiar was already done?
fun fact:
iirc in sc you could tell if minerals where still there by telling peons to harvest them. They would drive there in both cases but with slightly different behaviour...
attackable ghosted buildings
Moderator: Moderators
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: attackable ghosted buildings
I thought a bit more about this and I think I have a robust and complete solution. It's basically a lot of 'fake' units without a real unit.
Each mineral 'unit' is implemented as a fake unit that is only visible and interactable with a single allyTeam. These are linked by a unit that only exists implicitly as a lua data structure.
The minerals basically exist like this:MineralID is just an internal thing, can be ordered 1 2 3 4 etc.
Each mineral knows it's real health and the unitIDs of units that represent it. You also need a table of fake minerals by unitID that points the fake unit back to it's mineralID and appropriate allyTeam.
When a fake unit is damaged it should update it's mineralID's health. ie
minerals[fakeByID[attackieeID].mineralID].health = attackiee health
Fake units undergo health change iff either of these things happen:
One or more of these fuctions should provide all the visibility manipulation required to make this work. If an always visible unit messes up gadget:UnitEnteredLOS then another fake unit can be used. This unit could be visible to all allyTeams and exist solely to trigger gadget:UnitEnteredLOS.
So I think I have covered everything. It looks fairly simple to implement although some testing is required to figure out how the relevant functions work. I'm pretty sure this method has no method of gaining information outside LOS.
Each mineral 'unit' is implemented as a fake unit that is only visible and interactable with a single allyTeam. These are linked by a unit that only exists implicitly as a lua data structure.
The minerals basically exist like this:
Code: Select all
minerals = {
[mineralID] = {
units = {
[allyTeam] = unitID,
...
}
health = number
},
...
}
Each mineral knows it's real health and the unitIDs of units that represent it. You also need a table of fake minerals by unitID that points the fake unit back to it's mineralID and appropriate allyTeam.
Code: Select all
fakeByID = {
[unitID] = {
mineralID = number,
allyTeam = number
},
...
}
minerals[fakeByID[attackieeID].mineralID].health = attackiee health
Fake units undergo health change iff either of these things happen:
- They enter the LOS of their associated allyTeam (and their health is not equal to mineralID health)
- mineralID health changes and they are within the LOS of their associated allyTeam
One or more of these fuctions should provide all the visibility manipulation required to make this work. If an always visible unit messes up gadget:UnitEnteredLOS then another fake unit can be used. This unit could be visible to all allyTeams and exist solely to trigger gadget:UnitEnteredLOS.
Code: Select all
Spring.SetUnitAlwaysVisible
Spring.SetUnitLosMask
Spring.SetUnitLosState
Re: attackable ghosted buildings
I would rather make the mineral a real unit:MineralID is just an internal thing, can be ordered 1 2 3 4 etc.
It would obey normal LOS-rules and be the unit that is visible to the player by having a real model.
So the fakeunits would be there just to provide a click-target and to be visible on minimap. Rest would work as you described.
Re: attackable ghosted buildings
It all depends on how the units are going to interact with the 'minerals'. Through reclaiming? Through attacking/damage? Completely through lua? I think fake units is a bad idea, and definitely avoidable.
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: attackable ghosted buildings
This has issues:knorke wrote:I would rather make the mineral a real unit:MineralID is just an internal thing, can be ordered 1 2 3 4 etc.
It would obey normal LOS-rules and be the unit that is visible to the player by having a real model.
So the fakeunits would be there just to provide a click-target and to be visible on minimap. Rest would work as you described.
- Engine Ghost shows all model pieces, you lose your 'at a glance' minerals remaining system.
- If the minerals are actually dead the player could determine that the attack command is not on the minerals.
The gathering mechanic is already implemented and works the same way as in CT. Miners damage minerals and nothing else can be done to minerals.Niobium wrote:It all depends on how the units are going to interact with the 'minerals'. Through reclaiming? Through attacking/damage? Completely through lua? I think fake units is a bad idea, and definitely avoidable.
Re: attackable ghosted buildings
yup. (that part is done already)Through attacking/damage?
Yes, but it saves on pieceount. Just one mineralunit with 8 pieces instead of (in a 4 ffa) 4*8=32 pieces.Engine Ghost shows all model pieces, you lose your 'at a glance' minerals remaining system.
Seeing the minerals as complete and transparent outside LOS would be "ok" I think.
attack commands would always be on the fakeunits.If the minerals are actually dead the player could determine that the attack command is not on the minerals.
It is mostly a feeling that fakeunits will bring unforeseen problems because it seems a bit hackish/dirty. I will try it out in the evening anyway but wanted to look/ask for other ideas.I don't understand the thought process here as you haven't said how my design won't work
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: attackable ghosted buildings
Attached working system.
- Attachments
-
- minerals.7z
- (7.72 KiB) Downloaded 26 times