This is great stuff, thanks a bunch. I am wondering if I have a fundamental problem here. I am using the simple template, then I put three ships on the map, three different teams set on the map. In the script I set up the three teams in def and initialization. I put the relations in there too, and I get two angry ships when one should be an ally. I am not reading an error in compilation, and I get freshly modified dsl/drl files, but it is ignoring my SetRelation commands. I can change a handle's team to team 1, but I can't make a friendly team. Is there something I need to set up for that to work?
I think I am getting somewhere now. I am just trying to figure out how to play with teams, but it looks like 'for' can be used to create loops that can control teams.
The TEAM_ENEMY lines are not required because all Teams are Enemy by default. The only time you would need to use TEAM_ENEMY assigments is if during the mission you for some reason made them TEAM_ALLY and then want them to become the enemy.
To Make Team 3 Allied to Team 1 you must do Both Ways. MARKYNCC did show you that but for clarity it is a 1 way street. Also there are no Variables in the two lines below, they must be exactly as entered.
SetRelation( 1,3, TEAM_ALLY ); SetRelation( 3,1, TEAM_ALLY );
If those are the only 2 setreleations you enter then Team 2, 4, 5, 6, 7, and 8 are all Enemies of Team 1 and Team 3, as well as each other because no Allies were defined for any of those teams.
If you only do the first line that means to you they will appear Friendly but from their perspective they are your enemy and will attack you. You won't be able to attack them back. If you do just the second line that means you can attack them but they won't attack you because they think your their Ally even if you attack them.
Quote: "I set up the three teams in def and initialization"
I'm not sure what you mean by that exactly. I'm guessing you mean you tried to do what I'm listing below?
You can define variables though and use in the SetRelation() lines.. Say you define integers "int" of "PlayerTeam", "PlayerAlly".
You would define the integers in the DEFINITIONS section: DEFINITIONS int PlayerTeam int PlayerAlly BUT for that to work you MUST Initialize them "Properly"...
In the INITIALIZATION section you must enter these: INITIALIZATION PlayerTeam=1; PlayerAlly=3; Then you can enter it this way in a starting action: SetRelation( PlayerTeam, PlayerAlly, TEAM_ALLY ); SetRelation( PlayerAlly, PlayerTeam, TEAM_ALLY );When done like that what the game reads it as this: SetRelation( 1, 3, TEAM_ALLY ); SetRelation( 3, 1, TEAM_ALLY );But if you don't properly intitialize the integers it will see this: SetRelation( 0, 0, TEAM_ALLY ); SetRelation( 0, 0, TEAM_ALLY );---
Personally I just use the far simplier method of starting out with the plain old non variable usage I posted at the beginning: SetRelation( 0, 0, TEAM_ALLY ); SetRelation( 0, 0, TEAM_ALLY );That's what the game sees in the end with all the variables anyways.
The advantage of setting up "PlayerTeam" and "AllyTeam" integers and using them is that you can easily change them without going through the code or without having to remember the whole way through the script anytime you need the PlayerTeam you can use the variable instead and the same for the AllyTeam. It's more flexible, but it's also more lines of code and easier to mess up to start with, but once it's inplace it works great.
opps.. I meant for really simple assignments like your doing I would use: SetRelation( 1, 3, TEAM_ALLY ); SetRelation( 3, 1, TEAM_ALLY );
I do use "for" loops and temporary int variables when doing more complex assignments to save many lines of code.
Now there is a second possibility as to why it's not working for you.
You must place the SetRelation() entries into an Action in the .scp that is called by the Rule .rul file when the mission starts.
If you placed the SetRelation entries in an Action that's not being called then it won't be active.
Also I'm not sure placing SetRelation into the INTIALIZATION section would work, but it might. I consider attempting such a thing a poor coding practice though. That's not what that section is generally used for and I know placing certain things in there will certainly cause you weird results.
The third possibility is :
Is did you install Microsoft Visual C++ 2008 Express? Downloads
If you didn't your missions won't compile.
Also, in the third window of script compilation (after the two unimportant ones), I get " C:\Program Files (x86)\Bethesda Softworks\Legacy Alliance\missions\STL14>cl.exe STL14s.cpp /O2 /Ob1 /I "..\..\Include" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_WINDLL" /D "_CRT_SECURE_NO_WARNINGS" /GF /FD /EHsc /MT /Gy /W3 /nologo /c /errorReport:prompt STL14s.cpp" Is this an error or is this normal? It happens for all missions (stock too), so I am just trying to make sure everything is working right first.
That is "part" of the third output window. That is just the commandline and not any part of the "response". Since it's only partial and only the commandline I can't tell you that it compiled or didn't compile. I would need the full output window text to know that.
If anywhere on that screen you see the word "Error" then you have a problem and it didn't compile.
The only exception to that is that this part of the command lines contains the word "error" /errorReport:prompt Also to verify that the script compiled right you can goto the "\Star Trek Legacy\Missions" Folder ("Legacy Alliance\missions" in your case) and look for the STL14r.drl and STL14s.dsl files and check the modified date on them. It updates the modified date each time the file is compiled just like any other file when it's changed.
I was trying to setrelation in initialization... Muldrf. Thanks abunch. For learning it took me a while to appreciate the rule file, but it put the script files into perspective. I had big ambitions, but when I couldnt make that little thing work I was really getting steamed...:)
If you stick to making missions it won't be the last time you get steamed;)
btw some "variable names" do NOT work. They also don't cause compile error notices. They just fail to operate OR they cause something very very weird to happen.
I can't give any examples of ones that don't work. I haven't come across that problem in a long time, but I always keep it in mind if my code looks right and it is compiling but not working.
I also suggest working on small things at a time and test that they are working ingame rather than just trusting the fact it compiled, that way you don't code an entire mission then try to debug it. And if you get a compile error start by fixing the first one because any following ones might be caused by it. You can find your errors in the code by looking at the response
Say the output shows: tkm01s.cpp (384)
That means check the tkm01s.cpp on line number 384 and you will see the line that has the error. The tkm01s.cpp is a modified version of tkm01s.scp, so you should most likely recognize the line it is in the acutal .scp file and be able to find and fix it. The line numbers in most cases won't be anywhere near matching so that's why you look at the .cpp file.
How are you getting on with things now? Once you have begun to understand the basics of scripting, it really is surprising what can be achieved with a few lines of code! Muldrf has given me enormous amounts of help in this regard and I suspect that his email inbox is full of my questions!! sorry Muldrf!.
I posted up the full scriptinterface page at our cjg wiki.
I don't have many of the commands detailed, most were already noted originally, but I think I added a few descriptions. But most are fairly self explanatory.
I'm thinking of maybe setting up a Legacy Modding Blog. Possibly largely Mission Scripting based, but other potential subjects.
Hey, if you set up that blog, count me in, if you need other bloggers ;)