Here is something I noticed in H2GuerillaTST. The first picture is of a older .scenario file I have not (nor ever) added any scripts to. The second picture is of a newer .scenario that has the three scripts we were talking about previously (regarding the cinematic cameras and text).
Notice how the first picture has this script:
(script static unit player0 (unit (list_get (players) 0)))
and while you cannot see all of them from a picture that script no longer exists in the newer .scenario. Could this cause problems? And what exactly does that script accomplish? I could add it back in but I wanted to understand it first. TY
Its just a way for other scripts to refer to the newest joined player. It doesn't change anything (you'll notice in some of my other scripts, I have that same thing in it, except the script name is p0 instead. Or, one that has the word 'number' instead of the 0, and is player instead of player0. player0 is there for SP maps, because thats how they like referring to players in SP) Since scripts don't even execute on everyones computer in multiplayer, its safe to assume they still don't use that script in H2, and it was just left there as remnants from their SP auto setups.
Static scripts are just shortcuts, the type is unit, the name is player0, and the command is (unit (list_get (players) 0)). it basically means that any script below it where they type (player0) it will act as (unit (list_get (players) 0))
Also, when are you ever in the teamspeak server? I gave up on that after 2 days of sitting in there all day lol, haven't checked back there since.
Hey, this is something I possed at Monstermoose too, it might help you with some things. (I hope)
It is quite big, but, maybe it is something that hasn't been saw that way before, I don't know.
Tiny letters shoudln't be read
Scripts like the explosive crate creator and destroyer on Colossus require Death Trigger zones that are labeled.
To add objects names and to get more options within a .scenario file use H2GuerillaTST.exe from the Unlocked H2EK. Otherwise you will never see those fields.
Unfortunately, H2GuerillaTST.exe cannot open .scenarios that have Death Trigger zones.
But, I'm quite sure that I have opened it once. I don't know how exactly, but I had all of these fields that I've had never seen before, like "Child Scenario", first I thought it was because I did something magically to the scenario, so I saved it with a different name, later when I tried to open it again it didn't worked, or (with a different guerilla) the fields weren't there.
Maybe I can repeat what I did...
Wait, you mean the Guerilla can't open up scenarios with kill_trigger_volumes into them?
Can't you work around this by deleting the kill trigger volumes you have, but saving the values for it (on paper or something) and then make them in the Guerilla?
Nvm, that doesn't work either. The values don't get saved =/
But, I've just found a way around it, maybe:
Before you add kill_trigger_volumes in your map, you premake (so, you think of what ones you might require) the Object names. And then add the kill trigger volumes, look, this is in sapien:
Now, I don't know what you all have been trying and if this has been tried before, but, maybe this works?
E: You can't open it up with that Guerilla after it anymore... (because of the kill_trigger_volume)
E: After opening it up with Sapien again, the object name "Aname" was still there
E: After opening it with the normal (locked) Guerilla, and an unlocked version (non TST), and then opening it up in Sapien again the Object Name was still there, ready to be used.
This might be the way, right?
Weee, huge post incoming :P
I've seen this command between all the other commands:
Now, I don't know what it does, but Sapien asked me once for enabling it, so, I did.
And then this new folder called: "test", then another new folder called (inside "Test") "Data Mining" and inside there a .DMD file. Now, this is what I found on a website what they do:
"DMD files contain information that instructs the computer to take certain actions or display data, depending on the program."
And, when opening up the file with Notepad (<3 notepad, it opens up everything ), I saw some lines like these:
Maybe this synchronises scripts somehow?
Maybe someone can put this to the test with one of those wizard scripts, and then make a new script with the following in it:
I have no idea what it does, I just thought it might be something. I hope it helps somehow!
E: I've found something else out, apperently they also contain model data (O.o?)
In teory an ".DMD" file is a".MD2" whit LOD graphical support, but i can't found a free program to open it for import/export/editing this file type. Anyone can hep me?
Now, below at the page there is this file that cam change it to a md2, and that file type can be opened up in Blender.
I don't know how to do with command lines in Windows, so I can't test this. Maybe someone else can try it?
Apperently someone else found this already.
Next time I should read the entire post, I guess
Last edited by Garanas; July 5th, 2011 at 02:29 PM. Reason: someone else was first...
The kill triggers information came from this very thread, I was the one that announced that guerillaTST wasnt capatible with scenarios with kill triggers. But with the new object distance command, I really dont care about volume triggers. anything item can do that job now.
I know ive ran that command in sapien, and I think I might of done it ingame when I did a test with every button doing a different kind of data dump (incase one causes exceptions, then I can be in control and figure out what I can dump) where did it dump this information to?
If anyones interested, ive written a script that actually crashes sapien and tool on compile rather than just giving error messages lol. idk whats wrong with it, but im gonna blame that region command, as its new for H2, so ive never used it. Never bothered testing that fact though lol.
Code:(global short hog1repair 0) (script continuous repairhogs (if (or (< (objects_distance_to_object repair1 warthog1) 3) (< (objects_distance_to_object repair2 warthog1) 3) (< (objects_distance_to_object repair3 warthog1) 3) ) (begin (object_cannot_die warthog1 1) (set hog1repair (+ hog1repair 1)) (unit_set_current_vitality warthog1 (+ (* (unit_get_health warthog1) 250) 1) 0) (if (> hog1repair 50) (begin (object_set_region_state warthog1 "" base) (set hog1repair 0) )) ) (begin (object_cannot_die warthog1 0) (if (> hog1repair 0) (set hog1repair (- hog1repair 1))) ) ) )
I am having a problem using the sevral versions of guerilla, one of them shows scripts in 2 different places, and in both places the scripts are different.
Edit: Also cameras, I was able to leave my body camera but everytime I set up a camera it just looked wrong, could not see any of the bsp and I could only see the sky.... I will try to find the script...
So, you mean where you attach the .scenario_hs_source, and where you can read the script directly in the scenario? sapien updates the scenario with the contents of the hs_sources when you open it, but tool will always compile the hs_source into the final map since you may of changed it, etc. This is one thing I like about H2, I dont have to use sapien to add scripts, tool will do it for me.. now if only hs_source would be edited in notepad while still being considered valid.. (you can open it, and see the script, but there is a area to handle the checksum or something)
Sounds similar to my experiance where the camera stayed at 0,0,0. Any clue about the origins in your BSP? Anyways, the camera will only show up on the host computer, is this cutscene a big thing for your map? cause it might be best to leave it out as only the host can see it anyways even if you perfect it.
So, ran the script ingame, and it doesn't make any files anywhere (checked the halo 2 folder in documents, my games folder, h2 game folder, etc)
Looking through what sapien made when I have run it in the past (aparently ive run it twice, I have _0 and _1) it doesn't looks like it has any worth in sapien, only ingame, where it doesnt run.
And I doubt debug_scripting runs ingame either (run it in sapien) I really dislike testing things without devmode.. its so much easier with it lol.
Also, that script that crashes tool, it is the region commands fault. compiled it into the same map as this test after commenting out that line, and it worked.
There are currently 1 users browsing this thread. (0 members and 1 guests)