.Map :: MoHAA Mapping

Posted: **Sun May 09, 2004 4:48 pm**

There's any way to get the targetname of an entity that's inside a trigger? I've been digging the g_allcasses, didn't find anything...

Posted: **Sun May 09, 2004 6:17 pm**

parm.other.targetname

Posted: **Tue May 11, 2004 4:09 am**

Cool...Very cool...

I think I found a way to get bots thru script..Remember that summo's thread?

The bots are obeying like lambs

! But, like lambs, there's always some rebel one so...tell me:

local.bot refers ONLY to the bot that are dealing w/ the thread? As long as the thread ends, the definition of "local" can be applied to another bot?

Hope the answer is yes

Posted: **Tue May 11, 2004 8:03 am**

Well I'll try not to confuse by trying to explain how the scripting language works exactly.

A game of mohaa consists of several objects which all belong to a certain class. One of these classes is the 'ScriptThread', and you can 'spawn' a new ScriptThread by doing:

thread mythread

You'll get a new ScriptThread object which will execute the code starting at mythread:. From this point on, 'local' refers to this particular ScriptThread. Now if you destroy the thread by using the 'end' command (or, if you prefer, you could use delete, remove or immediateremove instead) the object is removed and the 'local' listener no longer exists.

Well hope that explains it in some way... don't have much time right now

Posted: **Tue May 11, 2004 9:49 am**

Not that I dought anything that jv_map says, but there are "other" listener classes. If you use "parm.other" on the bot, it would keep the local.bot name until it gets another parm.other, I think. However, the bots can all be named local.bot and still not be the same listener because of the ScriptThread object thing.

Maybe, I'm wrong. How does the local.bot, or local.player, become the listener without parm.other? Are they assigned index numbers if more than one bot or player is using the thread?

Can you define "classname", or just "listener class"?

I'm like you Krane, I know how to use the stuff, but don't really understand what the stuff is!

Wait, a light just went on! The local.players, or bot, are not using the same thread. They are using different identical threads (ScriptThread objects) that were created by the command "thread"..... Rats, the light went out again, grrr!

Posted: **Tue May 11, 2004 3:12 pm**

Ok, here's the situation:

As you guys already figured out, I'm trying to get individual bots by script to make them do things. I went into this thread and the method described here didn't work

(I'm getting ALL bots instead of just one).

So I realize that the bots actualy have a targetname (ai: 1, ai: 2, etc...). Well, I'm trying to make them go into a truck ride w/ me. This is waht I'm using:

main:

level waittill spawn

$allies_trigger setthread routine1

waitthread global/jv_bots/jv_mp_ai.scr::enable 0 0 0 0

end

routine1:

wait .3
if(level.botbusy == 1 && isalive self)
self waitthread bot_waiting

if(level.botbusy == 0 && level.truckbusy == 0 && isalive self)
level.botwait++
self waitthread bot_truckride

end

bot_waiting:

while (level.botbusy == 1 || level.truckbusy == 1)
{
wait 2
}
end

bot_truckride:

local.node = $("faketruck_playerspot_" + level.truckspot)

if(level.truckbusy == 0)
{

if(level.botbusy == 0 && level.truckbusy == 0 && isalive self)
{
level.botbusy = 1
self runto $crouch_position
self waittill movedone
self holster
level.botbusy = 0
level.truckspot--
self exec global/moveto.scr anim/crouch_run.scr local.node // THIS LINE..GR
//self waittill movedone
wait 3
wait .5
self glue local.node
}
}

if(level.truckbusy == 1 || level.botbusy == 1)
self waitthread bot_waiting
end

The script is kinda messy coz I messed up yesterday, will clean it up today!

I'm feeling the bot_truckride thread is too long, making the local.bot carries the local for too long...Do I need to "sub-divide" this thread into smaller, faster threads?

As you can see, I'm using the local.bot = parm.other.targetname only in the 1st thread (routine1). From there, I'm using self, once the bots activates the others threads in a different time.

Is this ok? It's not that isn't working, but sometimes bot2 stops when bot1 stop...I'm feeling it's a matter of "timing",i.e., bot2 is going too fast to where bot1 is...

I'm trying to avoid making one trigger to each bot and one script for each...

Besides the line "self exec global/moveto.scr anim/crouch_run.scr local.node" is a big problem. The crouch_run.scr looks like it never stops

...When I have a problem, the bots continue to exec this scr...

Anyway, am I in the right path? Do the "local" applies only to routine1? Or the bots carries the local to the other thread, as I'm using self?

Hey, trude's light came to me!..Should I use:

local.bot = parm.other.targetname again in the coming threads, so I set the local again and again?

Sorry for the complicated explanation

Posted: **Tue May 11, 2004 4:25 pm**

Well it's probably my bad but I can't find any local.bot's at all

Wait, a light just went on! The local.players, or bot, are not using the same thread. They are using different identical threads (ScriptThread objects) that were created by the command "thread".....

Yup, that's the concept... now just remember to keep that light on

Apart from 'thread' there's more ways to spawn ScriptThreads, for example you could simply do local.mynewthread = spawn ScriptThread, except I don't think you can really get it to execute any code. Although, I bet you can still do

local.mynewthread println "test"

or, launch a new thread from this 'fake' thread

Code: Select all

local.mynewestthread = local.mynewthread waitthread launchnewthread

// (...)

end

launchnewthread:
  thread testthread
end parm.previousthread

testthread:
  while(1)
  {
    println "wheee the testthread is running! self is " self.classname
    // should say ScriptThread
  }
end

amazing innit

Posted: **Tue May 11, 2004 4:46 pm**

Is there any way you could get a bot's ID number and change that into a targetname?

Posted: **Tue May 11, 2004 10:40 pm**

Well, I don't know if this will help you krane, but I did a test of pram.other to see what it is. It is all the "parameters" of the entity that walks into the trigger, I think. Anyway, I set up a trigger with setthread test_thread and a wait 5.

Code: Select all

test_thread:

	iprintln "Your targetname is: " (parm.other.targetname)
	local.sucker = parm.other
	iprintln "local.sucker's targetname is : " (local.sucker.targetname)
	wait 5
	thread test_thread2
end

test_thread2:

	wait 1	
	iprintln "local.sucker's targetname is : " (local.sucker.targetname)

end

When I walk into the trigger it says my targetname is "player". But, local.sucker's targetname is also "player", even though I did not use parm.other.targetname for it. The test_thread2 thread prints that local.sucker is NIL. This is because the first thread ended and local.sucker is no more. So, I tried this next.

Code: Select all

test_thread:

	iprintln "Your targetname is: " (parm.other.targetname)
	local.sucker = parm.other
	iprintln "local.sucker's targetname is : " (local.sucker.targetname)
	wait 5
	local.sucker thread test_thread2

end

test_thread2:

	wait 1
	iprintln "local.sucker's targetname is now : " (local.sucker.targetname)

end

And, local.sucker was still NIL in the second thread. So, I tried it this way.

Code: Select all

test_thread:

	iprintln "Your targetname is: " (parm.other.targetname)
	local.sucker = parm.other
	iprintln "local.sucker's targetname is : " (local.sucker.targetname)
	wait 5
	thread test_thread2 local.sucker

end

test_thread2 local.sucker:

	wait 1
	iprintln "local.sucker's targetname is now : " (local.sucker.targetname)

end

And, it passed the "player" targetname along to the second thread. Actually, it is creating a new local.sucker variable using the parameters of the old local.sucker variable, before the first thread ended. It is not updating the parameters--It is only using the parameters assigned in the first thread.

I did not have to use the "local.sucker" name for the second thread. Even if I used "local.newsucker", it would still end up with the "player" targetname.

Hope that helps, it did for me.

Jv_map - Is there a way to print out all the parameters of an entity--without listing them one at a time? I know "parm.other.health", "parm.other.dmteam" and angles, and origin. But after those, I am lost. I tried "parm.other.team" but it prints "american" no mater what team I join in multiplayer. Also, didn't you once tell me that bots can not trigger a trigger_multiple?

Posted: **Wed May 12, 2004 3:14 am**

Thanks trude

! Actualy the bots are triggering the trigger...

In your 1st example, if you put a bot there, it will return NIL as you said, but using loca.dude = parm.other.targetname BEFORE the command "iprintln", it will return the bot targetname (ai: 1)

!

cool, so during this thread "ai: 1" is the local.dude...If I tell him:

local.dude thread dance_a_polka

and then:

end

Is this the end? I mean, he will dance the polka but what about the next bot that will enter the trigger? Will he consider the next local.dude?

I must confess there's so many bots that I'm a bit confused...Once 1 is doing something, the other is already coming, and then another...AAHAHH!!! IT's working w/ 2 bots, they go to the truck like lambs...

I think I should build a test map just for this purpose

!

Posted: **Wed May 12, 2004 7:34 am**

there is another way to pass information from one thead to another

Code: Select all

mythread:

local.sucker = waithread test_thread
 iprintln "local.sucker's targetname is : " (local.sucker.targetname)

end

test_thread:

   iprintln "Your targetname is: " (parm.other.targetname)
   local.sucker = parm.other
   iprintln "local.sucker's targetname is : " (local.sucker.targetname)
  
end local.sucker

also I think if you don't use parm.other it is the player until you set off a trigger or something I found that out by accident .

Posted: **Wed May 12, 2004 1:52 pm**

Yeah, but the idea here's the oposite: Is to make sure that, when the thread ends, nothing will pass from one thread to another...So the first thread is "free" to accept another bot...

I finished my turret "problem", now I'll stay in this thread 'til I make'em go into the truck

!

Posted: **Wed May 12, 2004 4:25 pm**

I'd like to add a few general notes to hopefully improve your (and maybe even mine

) understanding, or it may just confuse you (or me)

.

Anyway, I will use tltrude's threads as an example

Code: Select all

test_thread:

   iprintln "Your targetname is: " (parm.other.targetname)
   local.sucker = parm.other
   iprintln "local.sucker's targetname is : " (local.sucker.targetname)
   wait 5
   thread test_thread2 local.sucker

end

test_thread2 local.sucker:

   wait 1
   iprintln "local.sucker's targetname is now : " (local.sucker.targetname)

end

local.sucker and parm.other are no more than references to a game object, in this case a player or a bot. Since local.sucker and parm.other refer to the same object (local.sucker = parm.other), they are identical. Hence, where ever you wrote 'local.sucker' you could have written 'parm.other' instead. For example, the game 'reads' them both as being '$player[1]'.

The parm.other variable, however, will be changed by the game whenever some entity enters some trigger. Thus, after the 'wait 5' parm.other and local.sucker may no longer be the same. This is why you should always (unless you only need it this frame) stash the reference to the parm.other object in some other variable, for example local.sucker.

Then if we look at the thread call in detail:

thread test_thread2 local.sucker

Then we see a reference (local.sucker) to the game object is sent as a parameter to the test_thread2 thread:

test_thread2 local.sucker:

Here, a new variable 'local.sucker' is made and is immediately set identical to the local.sucker from the previousthread. That's why the targetname is the same, too.

I hope that explains some more

btw tltrude I don't know any way to retrieve all variables belonging to a certain listener.

Posted: **Wed May 12, 2004 5:22 pm**

So,making a long story short...

If I put:

thread1:

local.sucker = parm.other.targename

local.sucker exec global/crouch.scr

wait 3

local.sucker thread thread2

end

thread2:

local.sucker = parm.other.targename

local.sucker exec global/wrenching.scr

wait 3

end

The bot1 spawns in the trigger and activates the thread1. He crouhes for 3 secs and go to thread2. When he leaves, he's not this local.sucker anymore, right? He goes to thread2. he enters the trigger, activates it, and become a "new" local.sucker?

Meanwhile, bot2 is going to thread1, so we have bot1 executing thread2 and bot2 executing thread1. Bot2 will be the "first" local.sucker"? And bot1, the "new" local.sucker?

I think you guys are gonna say "yes"

!

Posted: **Wed May 12, 2004 5:33 pm**

Sorry but I gotta say 'no' on all accounts

First of all make sure to get this fixed

local.sucker = parm.other.targename

should be

local.sucker = parm.other

Also, make sure to understand the concept of 'setthread' right. Remember a trigger will launch its setthread every frame it is triggered and parm.other will be updated accordingly.

Let's try to illustrate this with the code you posted:

frame 1
---------

bot1 spawns in trigger -> thread 1 starts, parm.other = bot1, bot1 crouches

bot2 might also be in the trigger but cannot trigger it as it has already been fired this frame.

frame 2
---------

bot1 is still in trigger -> another thread 1 starts, parm.other = bot1, bot 1 tries to crouch again

bot2 might also be in the trigger but cannot trigger it as it has already been fired this frame.

frame 3
---------

bot1 is still in trigger -> another thread 1 starts, parm.other = bot1, bot 1 tries to crouch again

bot2 might also be in the trigger but cannot trigger it as it has already been fired this frame.

etc...

about 3 seconds later:

frame 61
----------

bot1 launches thread2, parm.other may be bot1 or may be bot2, so from now on the behaviour of the bot gets unpredictable.

frame 62
----------

because several thread1's were running, every frame a new thread2 is started. parm.other is not necessarily bot1 so weird things may happen....

In short be aware that a thread is not something unique and it's not bound to anything (hence the thread can still continue to run even if the bot is already dead or if the trigger is removed), and you can have hundreds of instances of one particular thread running simulateously.

.Map :: MoHAA Mapping

Get Targetname

Get Targetname

hmmm

test