Uncontrollable units damge doesnt count

[SamualACarver]

I had read a post here the other day (I cant find it again) that was talking about how an uncontrollable units damage it gives doesnt count for the player. Does it matter if the units started under player control? Or is it anytime the unit is uncontrolled its damage given doesnt count?

Does anyone know how to get around this. I have some ideas that might work, but if someone has already figured it out that would save me a lot of trial and error.

One Idea I had involved keeping track of kills a unit makes. (only 1 unit from each team on this map would need to be checked). I know the engine tallys each kill a unit makes for Vets. Is there anyway to do anything with that info in scripting? For instance having a Test Unit that I guess you would say "tests positive everytime a unit makes a kill". Or some way maybe to script something whenever a unit made a kill? Or maybe I could use the Test Unit "Experience Greater than" but be able to have the Value inserted by the script, so that it wasnt a set number.

Over all what I want is for the uncontrollable Units kills to give credit for the kill to the player and also to know which team recieved the kill. If I could have a Unit Test that checked for whenever a Unit made a kill. Whenever it tested positive it would then start another test to see which player just lost a unit. I could then tie that info together for other scripted actions.


Edit: I have been reading over Loathing I had thought I saw something to look for a change in Mana, but it was Vitality. That is the only thing I saw that checked for a change in a unit. Is there others?

Also I was looking for a way to have a Units Mana increase with the amount of damage it did. If that was possible and then there was a Unit Test "Change in Mana Greater Than". You could do a lot with that.

Anyone know how to do this or have any ideas or be able to tell me which I my ideas cant work?

Thanks
Sam

[SamualACarver]

Is there any scripted command that can return a tested number? Something that can test for how many vets or how much Mana a unit has and then be able to use that number? Only thing I see are Greater than or Less than. I dont see anything that will give an exact count on anything. Like if you could do a Unit Test and see how many Vets a unit has then use that number for something else. Like maybe the number of kills a units has determines how many of a certain items the unit receives. The engine must be able to count or it would not be able to be correct on "Exp Greater than" type commands. I have gone through the Loathing Docs over and over and I have been trying different things with the Mathematics, but I am not seeing anything. Is there anything to do this?

Thanks
Sam

[Pyro]

If you want information on how to use the Math action read this thread.

You could use a different gametype for scoring, like Assassin. You can create blind units meaning they have "None" for visibility. Then place it in a corner of the map where no player has nearby units. Make it so the unit does not automatically auto-target enemies so it doesn't go attacking anything. If you plan on having many dogs per team, then make a blind scoring unit per team and as many blind assassin units as there are dogs per team.

Let us say you have team 0 and team 1 against each other. If the dog from team 1 dies, using scripting tell this blind scoring unit from team 0 to attack a blind assassin unit from team 1. Then you get a point. Just make sure the attack kills the target in one hit so it doesn't take too long.

[Pyro]

I forgot to mention, set the blind units' class to Ambient Life and check the flag Invisible on the overhead map. The assassin units will still show up as yellow dots on the overhead map but at least the other non-assassin units won't show up unless you have a unit near them.

[Pyro]

I mixed up something. I meant to say Hunting instead of Assassin. Hunting targets show up as yellow dots. Assassin targets show up as normal units would.

[SamualACarver]

Thanks Pyro,

I am not sure if it will work for me since I have 8 teams. If it were 2 teams I see what you are saying and that would work good. But with 8 teams even though I can know with the script who lost a unit I dont know who killed it. I thought before I could test and see when a units experience (vet) went up. Then test for which team just lost a unit. The I would know which team made the kill. But I havent found a way to do that. As far as I know there is no way to have an exact count on something return, such as the exact number of vets a unit has. I dont know how hard that would be to add to future updates, but I think it would open a lot of possibilities. You could give a unit a number of items based on the number vets a unit has for example. Or be able to know that a unit made a kill.

Sam

[A-Red]

Is there any reason you can't make them Ignore User Control instead of being Uncontrollable? On the surface, that seems like it would solve all your problems very simply.

[Pyro]

The next update already has a way to get an exact value for experience, however there is still a way to do it now using a combination of actions. Something like the following. Have a TUNI (Test Unit) see if a unit has experience greater than 0, if it suceeds have it activate whatever you want as well as a MATH action. This Math action is going to alter that value using the following parameters.

Left Action Identifier (the TUNI)
Left Field Name (exp>)
Right Integer (1)
Add
Destination Action Identifier (the TUNI)
Destination Field Name (exp>)
Activates on Execution (the TUNI)

That Math action will add 1 to the TUNI's experience greater than value each time the TUNI succeeds.

[SamualACarver]

Is there any reason you can't make them Ignore User Control instead of being Uncontrollable? On the surface, that seems like it would solve all your problems very simply.

Thanks A-Red for the idea. I tried it, it doesnt work, you have to have both "Ignores user command" and Recieve user comtrol" both set or else the script fails.


Awesome Pyro, I was thinking about that exact thing today, but I didnt know if it was possible to do. I was planning to ask if I could insert a value into the Tuni Exp > value with a Math action or if I have to put a number in? To make sure I am thinking about this right. I make the Tuni and when the Tuni suceeds it starts the Math which pulls the 0 from the Tuni then adds 1to it. Then puts that number (1) into the Tuni. When the Tuni suceeds again (now asking if Exp is > 1). It starts the Math, and it repeats. At any time I can have the Math give the current value?
Also, can I insert values to other commands as well? Like anything that ask for a number value I can have the number inserted in with another command?

Thanks Sam

[Pyro]

To make sure I am thinking about this right. I make the Tuni and when the Tuni suceeds it starts the Math which pulls the 0 from the Tuni then adds 1to it. Then puts that number (1) into the Tuni. When the Tuni suceeds again (now asking if Exp is > 1). It starts the Math, and it repeats.

Yes, that is exactly what I suggested will do. Of course alter what I suggested to meet your needs. So you can have the TUNI do something when it fails and when it succeeds it just triggers the Math action.

At any time I can have the Math give the current value?

Give the current value? As I implied earlier there is no way to find out a specific value currently (but there is already a way for next update). However, if you want to just replace a specific value you can either use a more simplified Math action that only has a left value and destination or use a Munger action.

Also, can I insert values to other commands as well? Like anything that ask for a number value I can have the number inserted in with another command?

Did you not notice the link I gave you earlier?

If you want information on how to use the Math action read this thread.

[SamualACarver]

Cool Thanks

Yea I read the link I actually did the script you had. And it worked.

I didnt know that I could put a value in a place like the "Exp >" spot in the Tuni where it ask for a number. I thought I had to put a number in manually at the time I scripted it, not have another command insert it later. Which is very cool that I can do that. That gives me more options.

What I meant about the current value is that the Math will be making a running count of sorts. I could use the number from the Math as it increased. Like maybe at a certain time I could have the number from the Math go to another command to use that number.

My plan to know which teams "Dog" killed which other teams "Dog" is to have the running count going with the Tuni and the Math. Then after the "Training period" ( which is when the Dogs are killing chickens and pigs and Vetting up) the AI for the Dogs takes over and the Dogs fight (chickens and pigs are gone). So after that point if a Dog makes a kill it will have to be another Players Dog. I will have another Tuni start at the end of the "Training" and have the Math insert the Exp number it has at that point into the new Tuni. So at that point if the "Exp >" Succeeds it will then start another Tuni to see which Player just lost their Dog. The script should then know the Players Dog that made the kill and the Players Dog that got killed. I may have issues if 2 Dogs die at the same time, but I am hoping that the chances of that are low enough not to matter much, or maybe I can figure out a way around that.

That should work right?

Edit: What does Munger do? There is not much info in the Loathing Docs.
Thanks Sam

[Pyro]

When you add a parameter in Loathing notice how it has something like "(exp>, integer)"? That is the field name of the parameter and the parameter type. That is where I got the "exp>". So for other values it will be some other 4 characters.

Mungers are advanced type of actions that allow you to modify other actions. Like replace parameters with different values or to delete actions.

As for your dog script. You could make each dog unique so they each have a different attack. The attacks would all be exactly the same but would be a different projectile tag with a different tagID. Then make the attacks create a sort of marker projectile that does nothing but land on the ground and stay still. Using scripting you can locate this projectile. Have the dogs each drop their own different marker on death. So you can test if the marker of dog 1 near the body of dog 2 and so on. You would have a GEOM looking for the marker of each dead dog, then find which attack marker is near that body marker. This way you don't need to test for their experience values at all. Just a TUNI per dog, then a GEOM per dog to find their body marker, and then a GEOM per dog to find which attack marker is near the earlier body marker.

[A-Red]

Thanks A-Red for the idea. I tried it, it doesnt work, you have to have both "Ignores user command" and Recieve user comtrol" both set or else the script fails.

Yes, that's true. One of them has to be set to true, and the other has to be set to false. If you want there to be units associated with the player's team that are controlled by script rather than by the player, that's all you need to do to set it up. Maybe I'm confused about what you're trying to do, but it seems like you and Pyro have figured it out.

[SamualACarver]

Thanks A-Red. Yea I want the units to be associated with the team, but I also want the Assassin kill and BC kills to count. They wont with both of those parameters set. Yea Pyro has been helping me a lot to figure this stuff out. That part I have.

Another problem I have. Its with the Geom. I have the Dogs set to pick up Artifacts when under AI control. That works. I am trying now (which I thought would be easier) is to have a Geom start a Ctrl. I could add another step like Pick Up then have the Pick Up start the Ctrl, but not from Geom to Ctrl. With the Geom to Pick up I have in it these 2 extra Parameters TIFN and a RAI that isnt in the Ctrl.

Here is what I have for the Geom to the Ctrl

T2 Dog Dead? [Geometry Filter]
deactivates_on_successful_execution
0.00, 0.00
{
Circle Centerpoint (Monster)
10656 (wolf special T0)
Circle Radius
3.001
Object Type
wabw (this is the field name for the Proj)
Activates on Success
Kill T 2 Jman
Minimum Number of Items
1
}

Kill T 2 Jman [Unit Control]
deactivates_on_successful_execution
0.00, 0.00
{
Monsters
10641 (journeyman DOG FIGHTS Player)
Kill Monsters
0
}


Thanks
Sam

[Pyro]

To make a GEOM work correctly you need to have a "Results Action Identifier" even if it is empty as well as a "Tested Items Inside Field Name" or one of the others with such a similar name. The ones with "Inside" in it will look for results that are within the area you are searching. The ones with "Outside" will include anything that is not inside. If you want to find the location of a unit or projectile then use the one with "Location" in the name.

As for what value a "Tested Items Inside Field Name" should have, it depends on what you are trying to find. The most common is finding a unit, in which case you use "subj". It depends on which parameter in a different action you want these results. You will notice a lot of actions have a "(subj, monster_identifier)" parameter. That is where the "subj" comes from. Some less common ones are obje, enem, cemo, and targ.

For finding projectiles (which the script might refer as objects), the most common is "proj". For finding locations, one of the common ones is "wayp". If you just want the GEOM to work and don't care about the actual results, then it won't matter which one of these you use.

I noticed you have your CTRL expire on successful execution. For certain types of actions the expiration mode is important. Others like CTRL will always assume they succeeded even if they don't work. For CTRL, you can leave it at the default expires on trigger. For GEOMs, if will mean that they will keep trying to work until it succeeds. The only delay is the 0.00 you have it set to. So if you wanted the GEOM to wait 5 seconds between each test you would give it a 5.0 to 5.0 trigger time.