[amkoc]

Is there any way to give kill credit for func_tankmortar?

[Chessnut]

yourEntity:SetOwner(yourPlayer)

[amkoc]

Chessnut posted:

yourEntity:SetOwner(yourPlayer)

I know that's usually the case but it says killed by #mortarshell

[SB2DevTeam]

Your entity fires a mortarshell right? Did you also do setOwner on that entity in your launcher?

[amkoc]

Don't see any way to get that entity?

[zzaacckk]

How does the player access/utilize the launcher?

[SeveredSkull]

amkoc posted:

I know that's usually the case but it says killed by #mortarshell

myEnt = ents.Create("func_tankMortar");

Your shell is now "myEnt"
that's how.

[cis.joshb]

What hook is that done in?

[SeveredSkull]

cis.joshb posted:

What hook is that done in?

you can do this ANYWHERE serverside.

[cis.joshb]

SeveredSkull posted:

you can do this ANYWHERE serverside.

Derp. I know. But when is it being done in your code?

[SeveredSkull]

cis.joshb posted:

Derp. I know. But when is it being done in your code?

What code? Code where? I didnt write any code. I anwsered a question:

amkoc posted:

Don't see any way to get that entity?

[cis.joshb]

Thought you were OP, sorry.
Anyways, you didn't answer his question, he asked how to get the entity that the thing fired, and you just showed him how to create another tank shell.

[SeveredSkull]

cis.joshb posted:

Thought you were OP, sorry.
Anyways, you didn't answer his question, he asked how to get the entity that the thing fired, and you just showed him how to create another tank shell.

Yes. I kind of did. When you assign something to a VARIABLE, it gives you a reference to it, mate. the reference to the entity that was created was the variable called myEnt.

Would you care to tell me where I did not answer his question?

[cis.joshb]

Because the answer to his question is: Show us your code, OP.
Plus generally the variable it is assigned to is local, and if it was global it would conflict with other player's tankmortars

[SeveredSkull]

cis.joshb posted:

Because the answer to his question is: Show us your code, OP.
Plus generally the variable it is assigned to is local, and if it was global it would conflict with other player's tankmortars

You clearly arent getting the point. Do you understand Lua, mate?

He wants to set the mortar shell's owner to something.
When he creates the shell, assign it to a variable, I called it myEnt. He now has a reference to his shell. That was his question. Now he can set the owner to what he wants by saying myEnt:SetOwner( <SOME PLAYER > )

It doesnt matter if it is local or global, because all you are doing is setting an owner of the entity before it is being created. You do not need a constant reference to the entity, nor do you need any sort of globalization for any further information or calls.

You don't need to see any code. And if you do, clearly you lack the proper solving techniques to be helping others in this forum.

Now, please don't bother posting any further.

Edited:

cis.joshb posted:

Because the answer to his question is: Show us your code, OP.
Plus generally the variable it is assigned to is local, and if it was global it would conflict with other player's tankmortars

WRONG... It would be a reference to the last mortar created, so it would only affect the last mortar spawned, which, in a sense could affect at most, 1 shell belonging to 1 player, not every single mortar in existence.

[cis.joshb]

And it's impossible for two mortars to be in the air at once. Also, what you said was right, but we need the hook it's being created in. (Presumably ENT.Use, so we can use the player argument to assign the owner to).

[SeveredSkull]

cis.joshb posted:

And it's impossible for two mortars to be in the air at once. Also, what you said was right, but we need the hook it's being created in. (Presumably ENT.Use, so we can use the player argument to assign the owner to).

Oh really? You know how his code works without seeing it? How do you know this?
Player 1 fires mortar from ent1 at 2:22
Player 2 fires mortar from ent2 at 2:22
Congrats! There are 2 mortars in the air at the EXACT SAME TIME.

cis.joshb posted:

And it's impossible for two mortars to be in the air at once. Also, what you said was right, but we need the hook it's being created in. (Presumably ENT.Use, so we can use the player argument to assign the owner to).

That's up to him to figure out. You don't need hook information. Didn't I already explain this to you before? It can go anywhere, and ent think, weapon primary fire, hell it could be called by a gamemode timer that just spawns random ones around the map. It doesnt matter.

There are LOADS of ways to get a player:
SQL
player.GetByID
Networked Entity
another function
etc.


Just leave while you are ahead.

Edit:
Love the boxes. Keep em coming.

[cis.joshb]

SeveredSkull posted:

Oh really? You know how his code works without seeing it? How do you know this?
Player 1 fires mortar from ent1 at 2:22
Player 2 fires mortar from ent2 at 2:22
Congrats! There are 2 mortars in the air at the EXACT SAME TIME.

That was sarcasm.

SeveredSkull posted:

WRONG... It would be a reference to the last mortar created, so it would only affect the last mortar spawned, which, in a sense could affect at most, 1 shell belonging to 1 player, not every single mortar in existence.

If a person fires a mortar, then the global is set to him. Then another person fires a mortar and the global is set to that person. If the person who fired first gets a kill, then it will be accredited to the other person, because the global is set to him.

Edited:

SeveredSkull posted:

That's up to him to figure out. You don't need hook information. Didn't I already explain this to you before? It can go anywhere, and ent think, weapon primary fire, hell it could be called by a gamemode timer that just spawns random ones around the map. It doesnt matter.

There are LOADS of ways to get a player:
SQL
player.GetByID
Networked Entity
another function
etc.

Except you need to get the person who fired it, which means you need to assign something to that person when you fire it, so no, it cannot go anywhere.

Edited:

SeveredSkull posted:

Love the boxes. Keep em coming.

Gladly, as long as you continue to post dumb things.
You have rated me dumb more times than I have you. I rated you dumb there because it was a dumb post.
And you are being quite belligerent. I generally rate disagree when someone is civil with their wrong post, but for posts like that I save my boxes.

[SeveredSkull]

cis.joshb posted:

That was sarcasm.


If a person fires a mortar, then the global is set to him. Then another person fires a mortar and the global is set to that person. If the person who fired first gets a kill, then it will be accredited to the other person, because the global is set to him.

Once again, Wrong. The only thing that is global would be entity variable, which as I had already stated should NOT be global. Don't see what you are still trying to prove.

If it was infact global, it would lose reference to the old entity and become the new entity. Then setOwner would be called on the new entity. This does NOT affect the old entity since the old reference link was lost upon creation of the new entity. You lose yet again.


Edited:



Except you need to get the person who fired it, which means you need to assign something to that person when you fire it, so no, it cannot go anywhere.

Ill just leave you alone on this. You clearly have the IQ of a pea, as you STILL do not get my point when I say the hook doesn't fucking matter. A player doesnt have to fire it. It could be called by a gamemode call such as GM:GODHAMMER where some god player becomes the owner via a networked entity. Con-fucking-grats. No entity hooks were used, and no player input was required.

Now I will say this one last time and it is the end of the discussion. This code. Can. Go. Anywhere.

Edited:


Gladly, as long as you continue to post dumb things.
You have rated me dumb more times than I have you. I rated you dumb there because it was a dumb post.
And you are being quite belligerent. I generally rate disagree when someone is civil with their wrong post, but for posts like that I save my boxes.

I rate dumb posts for people who tend to state that a logical approach is illogical and that the correct awnser is "POST THE CODE OP. DERP." so yes. you deserved them.

[cis.joshb]

Ill just leave you alone on this. You clearly have the IQ of a pea, as you STILL do not get my point when I say the hook doesn't fucking matter. A player doesnt have to fire it. It could be called by a gamemode call such as GM:GODHAMMER where some god player becomes the owner via a networked entity. Con-fucking-grats. No entity hooks were used, and no player input was required.

Now I will say this one last time and it is the end of the discussion. This code. Can. Go. Anywhere.

That's exactly my point. . .In order to tell him how to get the player, we need to know how it is used.

Edited:

I rate dumb posts for people who tend to state that a logical approach is illogical and that the correct awnser is "POST THE CODE OP. DERP." so yes. you deserved them.

I never accused you of giving me wrongful boxes.

Edited:

Actually:

WRONG... It would be a reference to the last mortar created, so it would only affect the last mortar spawned, which, in a sense could affect at most, 1 shell belonging to 1 player, not every single mortar in existence.

Is false, which was why I was arguing.

Edited:

Once again, Wrong. The only thing that is global would be entity variable, which as I had already stated should NOT be global. Don't see what you are still trying to prove.

If it was infact global, it would lose reference to the old entity and become the new entity. Then setOwner would be called on the new entity. This does NOT affect the old entity since the old reference link was lost upon creation of the new entity. You lose yet again.

Isn't what I was arguing about.
Your code never had SetOwner in it.

Edited:

Although I see now that the next logical step would be to do myEnt:SetOwner(whatever the player is)

[amkoc]

... I come back to this old thread and there's a pissing contest?

Anyway, I ended up just recreating everything in lua so I can OCD all over it: