This is my thread for discussing my own philosophies about BS-er's DLL Scriptor. I think I have a unique perspective given that I was basically handed 25 stories and had to figure out how to duplicate them in the Scriptor (talking about the BZ1 SP missions, if you've been living in a cave for the last few years...)
I'm going to start with basic philosophies and techniques, getting into specific code later on...
MAIN
My Scripts always starts with a 'Main' routine... [routine,Main,1,true] My background started with linear programming in Basic and I usually fall back on that to begin a project. I've also found it helps with debugging/testing, and with keeping things straight as far as having a place to return to as the mission progresses if you keep one 'master' routine and have it control the rest.
Yes, yes... "One routine to rule them all, and in the darkness bind them..."
I use 'Main' to first set up the pieces present in the mission. Being part of the 1.3 patch process and building/tweaking hundreds of units for eight races I learned the very very very VERY hard way that you NEVER just drop a unit in a map and save it. This will make you cry when something changes, whether it's the patch or you tweaking the model or ODF, and the map no longer loads.
There are also things that don't change easily once a unit is saved inside a map, like ammo/hull/addammo... where you'll find they keep their initial values even after you change the ODF, and only newly created tanks take on the new ODF values. Far better to spawn everything needed via the Script.
So rule number one is NEVER drop a unit in a map. Instead, spawn it via a position or path point. I prefer path points but some people aren't comfortable in the Shift-F9 screen so make a list of positions instead.
Back to the Scriptor.... in order to speed things up when setting up your map I initially run Main at a very high speed...
[routine,Main,9999,true]
//my stuff
createp,MyRecy,"avrecy",1,"myrecyspawn"
createp,MyGuard,"avtank",1,"guard1"
createp,MyGuard,"avtank",1,"guard2"
//bad guys
createp,TheirRecy,"svrecy",2,"theirrecyspawn"
etc.... I do have a set of pathpoint names but they've changed over the course of doing the missions, and usually now I default to the ODF name and a number. I use paper maps to decide what goes where, and the pathpoint name helps me make sure I don't spawn the wrong item. Set up your stuff, enemy stuff, nav beacons, set pieces, animals, whatever you need, then reset the run speed...
runspeed,Main,1,true
Back when I started scripting I'd set up other routines with a delay before kicking in, to give Main time to create everything. Remember, all of the routines marked as active start all at the same time, so you could easily have a routine start up before whatever it's watching has even been created. The easiest way to avoid this issue is to set up all of the sub-routines as [routine,subroutine,0,false] initially, and turn them on in Main when the time is right.
runspeed,WatchMyRecy,1,true
runspeed,WatchTheirRecy,1,true
Now you want to get into the guts of an SP mission. That means giving out objectives at the least, and playing a full blown cutscene at the most. Do that right in Main, and then start up whatever supporting routine you need.
Clear
Display,Obj1,white //"Retrieve the Relic at Nav 1"
StartSound,"Mission1-A.wav" //"Commander, get out there and get that relic!"
runspeed,WatchRelic,1,true
Now, there are some tricks you can do if you want to keep things strictly inside of Main, such as shutting it off at this point.
runspeed,Main,0,false
You can then have the WatchRelic routine turn it back on and it'll pick up where it left off. I tend to avoid this, though, as it's a sure way of having nothing further happen when some yahoo decides to do something odd and break your script, never restarting Main... :)
At this point you might want to wait a bit and then send the enemy after the Relic.
Wait,60
runspeed,EnemyToRelic,1,true
Then you may want to wait a bit before upping the pressure...
Wait,60
runspeed,ExtraAttackWaves,1,true
And finally, set up a timer to end the mission.
Wait,120
Clear
Display,Obj2,white //"Enemy reinforcements arrive in:"
starttimer,360,240,120
StartSound,"Mission1-B.wav" //"Commander, things look dark"
Wait,360
Runspeed,Armaggedon,1,true
Now you've got the basic framework for whatever will happen in your mission. It's laid out in such a way that you can go down it and fill in the missing routines and, when testing, jump around from section to section easily.
For example, you may not want to play the first 5 minutes over and over and over as you test the mission. Easy enough then to put a
jumpTo,TestPhase2
in there right after everything is set up, to jump you right to turning the enemy loose to get the Relic... saves a LOT of time when you do this, as you can perfect each section and jump right to what you need to test, one after another.
So there you have the basic philosophy I use when scripting. Make the general outline happen in Main, setting up the pieces, giving out the orders, playing the voiceovers and cutscenes, and controlling the flow such that you can jump forward in sections for testing.
***
So, was this helpful? It only took a few minutes to type (love the spellcheck in Firefox... :) ) and if it's helpful at all I'll keep going...
-Av-
Yes
Post more :-)
I think I'll use your BZS files as examples when ever I learn to do stuff in the scriptor...
Don't know if anyone cares but I've uploaded a variety of scripts that I have written over the years including scripts for my Mods, potential Starfleet MOD scripts and several other mods I was writting scripts for. I personally learn from examples which is why I'm uploading these so others can learn from them as examples.
http://www.starfleetplatoon.com/users/sonic/bz2/bz2_dll_scripts.7z
you actually did ITS??
i thought it had been abandoned...
Ack, this thread got STICKY stuff all over it, and it's just starting out... :-P
Quote from: Sonic on April 22, 2008, 08:30:20 PM
Don't know if anyone cares but I've uploaded a variety of scripts that I have written over the years including scripts for my Mods, potential Starfleet MOD scripts and several other mods I was writting scripts for. I personally learn from examples which is why I'm uploading these so others can learn from them as examples.
http://www.starfleetplatoon.com/users/sonic/bz2/bz2_dll_scripts.7z
You made those available long ago and I can't thank you enough for them. They really helped me get started when I first dove into the Scriptor. Many of the Scriptor routines are dead simple, but many need a little more in the lines of actual scripts to really show what they can do, and your examples do that very well.
OK, well, I'll do some more tonight then...
-Av-
Tanks AV, we do appreciate helpful information relating to modding for BZII. I personally don't have much practice with putting together scripts and this kind of info is like coming across a pot of gold. I think I've edited maybe 2 scripts just to get the feel of it, but love the thought that someone cares enough to actually share such jewels with other modders in a somewhat dry information landscape and it's like find an oassis in the middle of a very dry desert. Kudos AV!
OK, let's step back a second and get into prepping the map for the Script.
The first thing I do when making an SP mission is set up the Terrain. Sculpt it, paint it, (use Winter, can't stress enough how cool that is) and then lay out what is where... set up the pools, loose scrap, and at least the edge_path.
Now, on paper, I usually lay out where the enemy base is, where my base is, where I need the player to go and why, that sort of thing. Make a mission outline complete with map.
I then start up the empty map and use the editor to lay out the enemy base, my possible base, and place any ruins, relics, that sort of thing. I know, I know, I told you NOT to just drop things in the map, but this is different.
Now that I've got the actual objects in my map I go into the shift-f9 screen and place pathpoints for them all. This lets you get the alignment right, and usually makes sure you can build on those squares. It also shows me if I need to smooth the terrain out a bit more, or give them more elbow room.
Once the pathpoints are laid out (and recorded on my paper map) I erase all of the objects I've placed and save the map. This sounds like a lot of work, but you can always just skip placing the scrap and set off DaBomb if you're too lazy to delete everything... :) Using this method I've never once had a situation where the AI couldn't build what I told them to, where I told them to build it.
Finally, you set the name of the Script it's going to be using in the PATHS section and save.
NOW, you're ready to begin your script. :)
Again, as I stated earlier I usually set up the skeleton of the mission as the 'Main' routine. You can then run through it if you want, to get a feel of the timing, as it's sometimes important to actually DRIVE there when you're under a timer...
So, we've got the basics:
Map terrain complete with pathpoints.
Script that very quickly places all of the pieces on the map:
[routine,Main,10000,true]
//set up my stuff
createp,SvAPC,"svapcempty7",1,"svapc" (create at a point, Handle (name you use in the script), ODF name, Team, Pathpoint Name)
setGroup,SvAPC,0 (place it in the first Fkey)
createp,Svrecy,"Svrecy_nd",0,"svrecy"
//bad guys
createp,Wpower1,"abwpow",2,"abwpow1"
createp,Wpower2,"abwpow",2,"abwpow2"
createp,Abtowe1,"abtowe",2,"abtowe1"
createp,Absilo1,"absilo",2,"absilo1"
createp,Absilo2,"absilo",2,"absilo2"
createp,Prison,"abbarr",2,"prison"
setName,Prison,"Military Prison" (change the name seen when targeted)
beaconOn,Prison (light it up in the HUD so you can see it from anywhere)
SetMaxHealth,Prison,400
createp,Amrecy,"avrecy",2,"avrecy"
createp,Avturr1,"avturr",2,"avturr1"
createp,Avturr2,"avturr",2,"avturr2"
Places and names the navs:
//set up navs
createp,BaseNav,"abnav",1,"abasenav"
setname,BaseNav,"Nav"
Resets 'Main' to a normal speed and turns on the first set of routines needed to watch things:
runspeed,Main,1,true
runspeed,WatchMyRec,1,true
runspeed,WatchTheirRec,1,true
Now, THOSE routines are fairly simple. You just watch for the existance of an object and do something if it's destroyed. This is used usually for mission critical objects like your Recycler, or something you're supposed to guard.
You can do this by watching the object the whole time the mission is going, or you can add something to the ON DELETED routine to watch for that particular object to be destroyed. Let's talk about that...
There are two routines that are tricky with the Scriptor. The ON NEW OBJECT, and ON DELETED OBJECT routines run when something is added or removed from the map. This can be VERY powerful as it lets you watch, say, the enemy build units (or the enemy watch YOU build units), but they're also very tricky when you consider how many things are being added or removed from a map all the time. Ships, scrap, pilots, powerups, etc. all trigger these when created, used, or destroyed.
In Other Words it's best to save those for the more important things you can't do without them. Even running very fast in the Scriptor these routines can still miss things when there's a ton of fighting going on, what with things being destroyed and created constantly. Best to save those for later discussion.
So, to just watch something, especially something you've already placed on the map, it's easiest to just set up a routine to keep checking for its existence:
[routine,WatchMyRecy,0,false]
CHECKAGAIN:
GetByTS,MyRecy,1,1
IsAround,MyRecy
IfEQ,TRUE,CHECKAGAIN
//uh oh, it's gone...
StartSound,"Yousuck.wav"
Fail,20,"yousuck.des"
CHECKAGAIN: is the label, it allows the routine to jump back to that spot
GetByTS is "Get By Team Slot". It allows you to grab things like the Recy, Factory, etc. by finding out what's in that slot for that team. In this case it's Team 1, Slot 1 for the Recy. The Factory would be: GetByTS,MyFactory,1,2 for Team 1, Slot 2.
IsAround checks to see if the object now called MyRecy is still in the map.
IFEQ,TRUE,CHECKAGAIN says if the previous 'IsAround' came back TRUE, then jump back to the CHECKAGAIN label.
So every time it does this, and finds the Recy, it just jumps back to CHECKAGAIN. If it DOESN'T find a Recycler in your slot 1 it knows it's been destroyed and the IFEQ statement just lets the code drop through to the next line.
StartSound,"yousuck.wav" plays that wave file.
Fail,20,"yousuck.des" ends the mission in 20 seconds, and if it's been set up as an actual SP mission it'll display the yousuck.des file (text) after the mission ends. If you're just running the mission that statement won't do anything, it has to be run through the SP mission selection in the game, but you'll want to put it in now no matter how you're running the mission for testing. I use a shortcut to jump right into the mission, rather than running the whole game, but that's up to you.
I should also mention that it looks like that DES or TXT file has to have a name that's not more than 11 characters long with the extension. My testing showed that longer names don't get displayed. This may have changed in the 1.3 patch, but it's still a good idea to keep things as simple as you can. I name my missions things like "NSDF07", so that des file would be "NSDF07F1.des", or something simple like that.
So now you have a fully functional routine that watches for your Recycler and ends the game when it gets destroyed...
You may ask, if earlier I'm doing this:
createp,MyRecy,"avrecy",1,"avrecyspawn"
Then why do I have to use the teamslot function to get what my Recy is? It's already called "MyRecy" when I placed it...
The reason is that some objects change their states during the game. When the Recycler deploys it's actually being removed, and a building put in its place. This can 'break' the handle, so that the name is no longer associated with the object. If you just rely on the name you gave it when you placed it on the map the routine will run the minute you deploy.
The same sort of thing happens to the Player. In a lot of missions all I have to do to stop an attack wave from coming is hop out of my tank when I know they're on the way. Suddenly their target has disappeared and they don't know who to attack... This stalls them for the rest of the game, unless you deliberately re-order them OR have an AIP file active so the Idle Dispatcher can send them to their doom.
So,when in doubt, re-aquire your object by using one of the methods the scriptor gives us to find objects in the game. For things like the Recycler you can use the GetByTS method, but there's also:
GetByLabel - gets by the name of the object. Can be tricky as many objects are given a number on the end, and most end up called "unnamed_thisobject". Eyedropping a unit in the editor will help you figure out the names of objects if you can't guess it...
GetPlayer - gets the Player. I call this over and over for attack waves, in case the sneaky player jumps out of their tank...
[routine,AttackWave,1,true]
CHECKAGAIN:
GetPlayer,ThePlayer
Attack,Tank1,ThePlayer,9999
Wait,10
JumpTo,CHECKAGAIN
This routine will find the Player, assign that object to the handle "ThePlayer", send a tank to attack him at a high priority (9999), and then wait 10 seconds to do it all over again. This will keep that attack wave on track despite the Player changing tanks or trying to stall it by hopping out.
***
Whenever you're not sure how to lay out a command just call it up in the HELP menu. It'll outline just what you need to state to make the command work, and sometimes give you an example of that command working with another command:
EvalPos, position, integer, variable*
Evaluate the integer component of the position. If integer is 0, then the X component is the result. If integer is 1, then the Y component is the result, if integer is 2, then the Z component is the result. The result can be used by the statement that comes after it. If the optional variable is present, the result will be stored in that variable.
Example: evalpos,playerpos,1
Could be followed by: iflt,100,NOT_HIGH_ENOUGH
***
So now you should be able to take a blank map, add a few points, spawn some tanks there and have them attack the player...
-Av-
YES!!!!!
Tutorial information for Issue #5 of BZmag!!!!!!
:D
LOL... knock yourself out, and be prepared to edit for brevity... I sometimes go on for longer than I should...
-Av-
It's not like we're using real paper here at BZMAG!
*If I had a really good printer that could print the entire margin I would make a hard copy of the mags though. I wonder if I can get my cover art as posters.*
Having created a recycler vehicle by script.
Createp,myrecy,">ivrecy_me",1,"recycler"
and wishing it to be controlled by aip
setplan,"relaip1.aip",1
How can I make it deploy without being told to by the player?
The deploy script command does not make a recycler deploy.
I am trying to make the player a pilot, not a commander, for the first part of this mission.
Well, i think the stock AIP's should have that info, in IA / MPI the cpu recy starts out as avehicle and deploys on a pathpoint.
As far as I know the DLL can't do that directly. It may be that the AIP has a plan for this... I'd like to know that myself as something tells the AI Recycler to deploy in an IA/MPI game...
It can be faked in the Scriptor, though...
[routine,FakeRecyDeploy,1,true]
Createp,myrecy,">ivrecy_me",1,"recycler" create recy at pathpoint
Wait,20
GoTo,myrecy,"recydeploy",9999 send recy to deploy point at high priority
Wait,5
SetAnimation,myrecy,"deploy",1 set it to run 'deploy' once
StartAnimation,myrecy run the animation
Wait,5
Replace,myrecy,"abrecy",true replace the deployed vehicle with the building
No blue lines, or fading in/out of parts, but it IS faking it, after all... You could place the building first, then remove the vehicle, which would look a bit more like the actual deploy, but you'd have to grab the orientation of the recy manually first.
A lot of things can be 'faked', like undeploying recyclers, with animations and 'replace'... :)
-Av-
From PB2:
[Plan#]
planType = "Deployer" // New planType.
buildLoc = "pathname" // Required: Pathpoint name. Plan shuts down if not valid.
DeployClass = "ivrecy" // Required: GameObjectClass of what to send. Plan shuts down if not valid.
If the buildLoc or DeployClass are invalid/not found, then this
plan will go into a safety mode and do nothing. ["pathname" and
"ivrecy" above are only examples, the true defaults are empty strings,
i.e. do nothing] Note that all the other usual common/shared items in
a [Plan#] can be added. Things like conditions, buildIfNoIdle, and the
like can be specified as well. You'll probably want to at least put a
NotExists condition on the plan to ensure it doesn't keep building and
sending things to a destination. Also, this doesn't apply to just
'recyclers' -- it sends a 'deploy at' command to its target object.
Also, added a new pair of conditions to all AIP chunks
[Plan#]
planCondition = "PathBuildingExists"
planConditionPath = "pathname" // Required: pathpoint name. Condition ignored if invalid or not on current map
[Plan#]
planCondition = "NotPathBuildingExists"
planConditionPath = "pathname" // Required: pathpoint name. Condition ignored if invalid or not on current map
Of course, these should work in the other condition slots, e.g.
planCondition2, planConditionPath2 .. planCondition16,
planConditionPath16. A PathBuildingExists condition is satisfied when
there is a terrain-owning building (of *any* type) at the path. A
NotPathBuildingExists condition is satisfied when there is *no*
terrain-owning building (of *any* type) at the path. This type of
condition shold probably be used with the "Deployer" plan above, for
fairly obvious reasons -- cutting down on overbuild. It can be used on
other planTypes as well.
All this is pretty much untested. If it blows up, send me a save
with assets. [NM]
And there you have it... no need to fake it, just add the Deployer plan to your AIP...
Thanks RD!
-Av-
I had always assumed that the dll did take care of deploying enemy rec in mpi, as there is nothing in the aip's to tell it to do so.
Well, the engine is what takes care of it, but we now have access to it via the AIP's. :-)
You can tell something to deploy and undeploy using a DLL, but it the stock one doesn't.
The MPI/SP Dlls don't instruct the Recyclers to deploy, rather they deploy due to an AIP be setup. Which means, if you took Avatar's little script there, you could drop the entire deploy animation section and simply assign an AIP when the Recycler gets to where you want it to be. The Recycler at that point should auto-deploy and begin to do whats in the AIP.
Quote from: Avatar on April 24, 2008, 04:29:14 PM
LOL... knock yourself out
WHACK!
Now what? :P
Keep the information coming. It's helping me out too.
RL heated up, can basically surf a bit from work but am tied up most of the rest of the time.
This weekend I want to outline doing a complete mission, from making the map to writing the script...
-Av-
I'd love to add it to BZMag #6. ;) I've got a whole lot of content for BZMag #5. Thanks for letting me use your stuff for this issue. :)
I do promise to get back here as soon as my sister has a front wall again...
-Av-
Another car/tree/plane crash through it again?
"We'll take it!"
chopper? ufo?? sabre tank??
3 Seasons room falling down due to dry rot, soon to (re)become a full front porch.
Got the wall rebuilt, insulated, and wiring almost done. A little siding, some demolition of the existing walls (mostly windows) and it's done.
This weekend, I promise, I'll get on at night and due a full mission from placing path points to writing the script.
-Av-
OK, here we go.
Let's take a map we're all familiar with, Dunes.
Start the map by making a shortcut to it like this:
"C:\Program Files\BZ\Battlezone II\BZ2Edit.exe" dunesi.bzn /nobodyhome
That line should be in the 'target' window of the shortcut, and will start the map completely blank. No paths or DLL or anything...
Fire up the map and you're sitting in a Sabre in the middle of dunes. The exact middle, btw...
You'll also notice a LOT more map with this one. That's because loading it up empty removes the 'edge_path' that limits the view to the playable area of the map. Now you can see all of the terrain, including those areas that you normally can't. There are also no ruins or pools, but we'll deal with them later.
Once the map is up and running hit SHIFT-F9 to enter the path editor. It opens in a window for various reasons, so if you want to you can use SHIFT-ENTER to make it fullscreen. Just remember to put it back to a window before trying to save your map...
It should be mostly green-blue with a big yellow squiggle above a big green square. The green square is YOU, the yellow squiggle is the cliff in front of you. Use the '-' (minus) key to pull back and get more of a view of the terrain. The further out you go the more terrain it'll show and the slower the response. There's also a limit as my screen goes black if I pull back out too far.
There are other views, which you turn on via the simple menu used in the path editor. What you're looking at now is called 'slabs'. Hit 2, then 1 to turn them off and stare at a black screen. Hit 2, then 6 to get a green-screen height view. There are times and maps when you might want to view height rather than slabs, but usually slabs will give you a decent idea of where you are on a map.
Move the view by moving the cursor to the edge of the screen.
Now to set some paths.
Move your view 'up', to the area the humans usually spawn in, at the north end of the playable area. We'll lay a path point to create our Recycler.
Hit 1,2 and left-click somewhere on the map. A path point will appear and a small text box with 'path_1' in it will open at the bottom of the screen. Left-click on the text box and a dialog box will open in the middle of the screen. (if it doesn't you're one of those people that will HAVE to run the editor in a window)
This dialog box has a few things in it, but nobody's sure anything beyond the name does anything anymore. :) So for now just change the name of the point to 'myrecycler'. Hit "OK" and the box closes AND the name in the text box updates but doesn't close. To close it and end making the path right-click somewhere outside the text box.
There. You just made a path point. I don't know why some people are so scared of the Shift-F9 editor, as most of the time this is as complex as you need to get in there.
Place a few more points, 'myturret1' and 'myturret2', and then move down to the Southern area so we can set up the AI. Place 'airecycler', 'aiturret1' and 'aiturret2', which should be enough for now.
If you're in Full Screen mode hit Shift-Enter to get back into a window. Hit ctrl-S to save the map, preferably with a non-stock name. I usually exit the map at that point by hitting Shift-F9 again, then ESC and ABORT. Shift-F9 can be finicky, and it's easy to get stuck in it (or a sortof an editor view) after using it, so I just finish up and end the map after saving.
Now change your shortcut to get rid of the /nobodyhome and change dunesi.bzn to whatever you named your map. Start the map back up again and hit ctrl-e to enter the editor. Place some pools, some loose scrap, play with the ruins, and when you're done hit the PATH entry at the top right of the tool set. Notice where it says "empty.dll", and change that to "myscript.dll". Save the map again.
That's it for map prep for this simple mission. On to the Sciptor!
Fire up the Scriptor and hit BUILD, then save the blank script as "myscript", and do so IN the \missions folder. You can hit the 'auto add' button OR if you like, answer 'yes' to each object name when prompted. If you save the script there it'll build the DLL's there and they'll be ready when you run the mission. Just don't forget they're there, and remember to include them in the map zip when you release it.
We'll want an objective, so add some to the TEXT section of the script:
[text]
Obj1,"Destroy the enemy Recycler"
Obj2,"Good Job!"
Obj3,"You're DEAD!"
Now, I usually start with setting up the map as part of the MAIN routine. To do that quickly I set up MAIN to run very fast. I'm also going to make my comments Scriptor comments so below should actually work in the Scriptor:
[routine,Main,10000,true]
//Give yourself a Recycler and two turrets, built at the path points you placed.
createp,MyRecycler,"ibrecy",1,"myrecycler"
createp,MyTurret1,"ivturr",1,"myturret1"
createp,MyTurret2,"ivturr",1,"myturret2"
//which is of course:
// "Build at Path Point", Name of build object, ODF to build, Team to build it on, Path Point Name.
//Now for the enemy... you can copy/paste the above and change a few letters if you want...
createp,AiRecycler,"fbrecy",1,"airecycler"
createp,AiTurret1,"fvturr",1,"aiturret1"
createp,AiTurret2,"fvturr",1,"aiturret2"
//now slow this routine down to normal
runspeed,Main,1,true
//now for an objective, and light up the enemy Recy in your HUD.
Clear
Display,Obj1,white
Wait,5
BeaconOn,AiRecycler
//you might like some scrap to build pods, or make it enough to build a Scav if you want, but for this mission we'll just keep it at 10 for now.
SetScrap,1,10
//we'll turn on a separate routine to watch for YOU to die:
runSpeed,WatchPlayer,1,true
//now we'll set up to watch the enemy Recycler
CHECKAGAIN:
IsAround,AiRecycler
IfEq,True,CHECKAGAIN
//which will loop until you destroy the enemy Recy
Clear
Display,Obj1,green
Display,Obj2,green
Succeed,10,"misnWIN.des"
[routine,WatchPlayer,0,false]
//turned 'off' until we turn it on in MAIN
//get the Player object and make sure it's around
CHECKAGAIN:
GetPlayer,ThePlayer
IsAround,ThePlayer
IfEq,TRUE,CHECKAGAIN
//gets here only if you're dead, to display the bad news
Clear
Display,Obj1,red
Display,Obj3,red
Fail,10,"misnFAIL.des"
//that's it... a very simple mission but it does outline the steps needed to get a working mission up and running.
//So, maybe we should use this as a basis and add to it, based on requests? You tell me...
-Av-
That's a very good idea AV. Step by step helps to make following along a bit easier...BNG
Thanks, Av. :-) I copied and saved that for future reference.
Adding it to my collection to be published. Thanks, Av!
wouldve been nice to know before i had to learn all that the hard way :lol:
Special thanks to AV and the other modders who've taken the time to share this stuff. BBB, it would be nice if you followed suit and posted some tutorials yourself. BNG squeezes BBB's brain in an effort to obtain some knowledge.... Tanks Avatar your tutorials are very much appreciated...BNG.
im not the tutorial type person - however i am quite happy to answer any questions you have about modding
I have many many ideas for neat dll controled single player things. (and mp hopefully).
One of them was the same as something in Dune Command, A Dropship decending down, with a physical vehicle attached (Think Halo's Pelican + Warthog/Tank) and landing, dropping the vehicle and maybe spawning some troops, and then flying off.
Kudos if it can also shoot at stuff while flying past.
How would you do that?
My non DLL preliminary idea follows along the same lines as the pilots mortar packs, where a ship comes down, and deploys like a turret and fies a pack like the mortar, but it dispenses a tank and the model on the ship dissapears like the one in the back of the pilot mortar. Then the dll tells the ship to move off once the tank is spawned via the weapon.
I know, random, but I thought I should write this down somewhere... One of those things that hits me when im trying to fall asleep. Hehe, some of my greatest stuff has hit me then.
DLL should spawn the items too. If you are using DLLs, the less ODF tricks the better as they can get confusing and are ultimately unneeded in that situation.
You could use the QF shuttle technique and have it carry the unit until it gets to the landing point, then just drop it off.
nielk1's new DLL class work would get it to shoot if you attached turret taps to the 'pelican' vehicle.
and the QF shuttle would work, using a tug.
was the dune command stuff done with DLL? i always thought it was a special ODF configuration. although then again ive not played DC for years... maybe ill DL it again.
The QF shuttle is not a tug.
DC intercepts the hunt command and then replaces the object and does a little animation.
My attacher code originated from BBB's shuttle code. Though I have many more options and have it run though a C++ DLL.
not a tug? oh darn. well still, could work anyway lol...