Craftstar2 came up with a good idea for my map, which requires me modifying te health of units in a dropship. I did a bit of testing, and at first glance it appears that you can't directly modify unit HP inside of a dropship. Now, this dropship is also used for using items, so when you unload something, it will use an item, but it seems like you will also need to unload units to modify their HP. I spoke with nuderaider about this and he suggested a "turn off item casting" switch, but I was hoping someone might have some 1337 trix on how to get around this. So, anyone have any 1337 trix?
None.
If you place the trigger after the spell detection, it might be fast enough to get them out and back in before they're detected.
None.
I tried doing it in 1 trigger cycle, it didn't work out.
None.
An artist's depiction of an Extended Unit Death
You could have the load AI script only active if a unit is detected on the ground (modify a location "under" the dropship). That way, the unit would always be detected before reloading. You could either incorporate the load unit AI into the trigger of each unit/item, or you could have all hp modifier triggers above the load unit AI script.
How about you move the shuttle/dropship or unit somewhere else for a split second to change the hp?
Like, if you suddenly need to change the hp, move the shuttle, unload, change, reload, place back. Simple, yet 1337?
OR, better yet. Have a switch (or dc) for everyone, that if you have (0, or 1, doesn't matter) that when you drop the item it won't work, a catch of the trigger of sorts.
So, say you want to change the units hp, set the death to (0, or 1), and since that death isn't (the opposite number you just put), the item won't activate. Change, reload.
None.
I figured out my own 1337 trix for this. You cannot modify HP inside a dropship, but you can Kill or Remove units inside a dropship. So I just kill the unit, create a new one with appropriate HP, and enter it into the dropship. Problem solved.
None.
whats the point of setting hp? There's better ways of transferring a percentage to the player.to show you don't have that item, doh. Just checked the map production thread. It's hard for the player to know 35% from 65%, but very easy to know 1% to 100%.
On a sidenote, is the location you're using ground only? It shouldn't matter, but it could be a reason why it doesn't work. Transports are known for being weird, just look at the hallu->bring in transport bug where a hallucination is detected as the real thing by the bring condition.
Post has been edited 1 time(s), last time on Feb 1 2009, 11:27 am by rockz.
"Parliamentary inquiry, Mr. Chairman - do we have to call the Gentleman a gentleman if he's not one?"
The location I was using was actually ground and air, and there was a separate location enveloping all 4 player's dropships that was ground only. I got this working perfectly, but I did find some strange things, namely that if you do something like this:
Create 1 Terran medic at location X for current player
Run AI Script Enter Transport at X
Within the same trigger, the medic will not take the order to enter the dropship. If you do it the next trigger cycle it will take the order though.
Also, when using the exit transport, it takes forever for all the units to unload, it's just like using the "Unload all" command, I did not know that... Anyway, it took precisely 160 triggers but I got this working perfectly in my map. (Yay for find--> replace in notepad++)
None.
At the start of the game, you presumably won't have any items, don't put anything in the dropship.
If a player gets an item, create and load it. If a player uses that item, he'll have to unload it, so simply modify the life before putting it back into the dropship.
None.
We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch
That way the items wont always be at the same spot in the cargo hold. A red/green coding is more convenient imo.
That way the items wont always be at the same spot in the cargo hold. A red/green coding is more convenient imo.
If memory serves, for each set of units in a shuttle, SC picks some order (not sure what is it based on). So if you use the shuttle to represent items you do not have (as well as items you do have) and all its 8 cargo slots are used, then you can determine the order SC will prefer simply by testing.
I'm not entirely sure of this though. I just experienced something similar in early versions of city of the dead, which might have been just a particular case influenced by some circumstances I am not aware of.
None.
We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch
Yes, that's what I implied. What I meant was a fully loaded dropship with red/green coding has the units always in the same spot, whereas when some items are missing (yet) the display will arrange them left aligned so the positions will shift.
If you remove all units in the Dropship before reloading the unit (If this is possible?), it would be possible to maintain the same order.
None.
Yeah, you can remove units from Dropships, this could increase the rate that they reload, possibly making it work in a single trigger loop..
None.
We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch
You can maintain the order, but not their position. For example the 7th and last item in your inventory (upper right pos) is heal, and the first (upper left pos) is invulnerability. Once you use invulnerability your heal (and all others) will get shifted and heal is now the lower right position, 3rd row.
In my dropship, the units always maintain the same positions, regardless of when they are dropped out of the dropship or reenter (unless of course one is missing for the breif second its unloaded). Just to confirm what's been said.
None.