| possible scripts.dll 1.8 in the works [message #91276] |
Mon, 31 May 2004 03:35  |
|
|
So far, all it is is a few tiny changes that dont matter much plus some experienemts with stuff that requires moving over to the "dark side" (i.e. maknig direct calls to renegade engine to do stuff that couldnt be done before).
I cant do anything that requires sending stuff to the client and processing it on the client-side (because I havent gotten that far) or stuff that requires modifying the renegade codespace (also because I dont want to/havent gotten that far yet) but I can call functions in renegade.
And I still have work to do to make all this go with the LFDS and WFDS.
So far, changes for a possible 1.8:
1.new script, JFW_Flying_Infantry. When created, if the thing this is attatched to is a SoldierGameObj, this script calls Toggle_Fly_Mode on the SoldierGameObj which makes it able to fly if it cant and unable to fly if it can.
2.new script, JFW_Flying_Infantry_Custom. When this recieves a message, it calls Toggle_Fly_Mode on the object that its attatched to, only if its a SoldierGameObj though.
3.new script, JFW_Flying_Infantry_Zone. When entered or exited or both (settings settable by mapmaker), it calls Toggle_Fly_Mode on the thing unit that entered the zone if its a SoldierGameObj.
Credit to SK for origonally discovering that its possible to do flying infantry in renegade.
I am also working on (no promises) new functionality for a Get_Animation_Frame function which would allow you to pass -1 for the FirstFrame of the animation scripts to mean "the current frame"
Also, logic for Get_Shield_Type that would mean JFW_Invulnerable_On_Custom_3 same as JFW_Invulnerable_On_Custom_2 but without needing to pass the NormalArmour as a parameter.
Again, I stress, these are only possiblilities.
But if anyone has any suggestions (including suggestions that might use engine functionality), post them here. If they arent in this thread, they wont be in 1.8.
BTW, no, this new "engine calls" stuff doesnt mean working poke, working sounds, working text output or working stealth stuff. (although the work SK is doing should help in that area)
It does mean I can do things like retrieve more information from game data structures and such.
Ideas appreciated.
Jonathan Wilson aka Jonwil
Creator and Lead Coder of the Custom scripts.dll
Renegade Engine Guru
Creator and Lead Coder of TT.DLL
Official member of Tiberian Technologies
|
|
|
|
| possible scripts.dll 1.8 in the works [message #91279] |
Mon, 31 May 2004 04:17  |
Deactivated
Messages: 1503
Registered: February 2003
Karma: 0
|
General (1 Star) |
|
|
COM_Airstrike_Controller
Iniates time-delayed (charging) Airstrike flare spawing once all SAM Sites have been destroyed on the map.
It will not spawn (time-delayed) another beacon until the beacon is placed.
Plays text cinematic once the beacon object exists on the map.
Will become disabled if attached building (Comm Center) is destroyed.
COM_SupplyDrop_Controller
Iniates time-delayed (charging) Supply Air-Drop flare spawing.
It will not spawn (time-delayed) another beacon until the beacon object exists on the map.
Plays text cinematic once the beacon object exists on the map.
Will become disabled if attached building (Comm Center) is destroyed.
COM_IonCannon_Controller
Iniates time-delayed (charging) Ion Cannon beacon spawning.
It will not spawn (time-delayed) another beacon until the beacon object exists on the map.
Will become disabled if attached building (Advanced Comm Center) is destroyed.
COM_Temple_Nuke_Controller
Iniates time-delayed (charging) Nuclear Missile beacon spawning.
It will not spawn (time-delayed) another beacon until the beacon object exists on the map and plays an animation (Silo doors open).
When the beacon object no longer exists on the map, it will play the animation backwards (Silo doors close)
Will become disabled if attached building (Temple of Nod) is destroyed.
|
|
|
|
| possible scripts.dll 1.8 in the works [message #91281] |
Mon, 31 May 2004 04:38 |
|
|
ok, good ideas.
Here is how I can implement them
First, JFW_Spawn_Timer.
takes a custom to start the spawning (sendable either after all the sams go away somehow or at startup, depending on what you want)
Would only start charging again when beacon is collected.
Would require another script on the beacon powerup to tell the controler when its been "collected" (I think one of the existing "custom" related scripts should be able to do it.
Will also send a specified custom to a specified object when the beacon is spawned. You can do stuff with that such as opening the silo doors etc.
As for destruction, you can destroy the daves arrow or whatever the controller is on using JFW_Death_Destroy_Object.
For the becaons where a cinematic is desired, you can send a custom to something to make the cinematic start.
Same with the doors for the temple, JFW_Set_Animation_On_Custom should handle that.
Note that once its collected, there is no way to track the beacon anymore. Hence the need to handle stuff only on "collected" (an event thats easy to test for)
Jonathan Wilson aka Jonwil
Creator and Lead Coder of the Custom scripts.dll
Renegade Engine Guru
Creator and Lead Coder of TT.DLL
Official member of Tiberian Technologies
|
|
|
|
|
|
|
|
| possible scripts.dll 1.8 in the works [message #91294] |
Mon, 31 May 2004 05:57 |
Deactivated
Messages: 1503
Registered: February 2003
Karma: 0
|
General (1 Star) |
|
|
| jonwil |
Note that once its collected, there is no way to track the beacon anymore. Hence the need to handle stuff only on "collected" (an event thats easy to test for)
|
Beacon object should send a message to its corresponding controller.
|
|
|
|
| possible scripts.dll 1.8 in the works [message #91296] |
Mon, 31 May 2004 06:02 |
|
|
thats the plan, sticking one of the existing scripts on the beacon object to tell the controler its been collected.
Jonathan Wilson aka Jonwil
Creator and Lead Coder of the Custom scripts.dll
Renegade Engine Guru
Creator and Lead Coder of TT.DLL
Official member of Tiberian Technologies
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| possible scripts.dll 1.8 in the works [message #91368] |
Mon, 31 May 2004 12:55 |
 |
TheKGBspy
Messages: 96
Registered: April 2003
Karma: 0
|
Recruit |
|
|
Silent kane: Look final version of 1,8 isnt released.. so he will probably change the form. dont be mad you should be happy about that. people (including me) are happy to see that you found that and this wont be forgoted. you r doing a good job discovering stuff like that and the community need that kind of help. yes maybe one form does have been released.. but not an official version yet.. so that will change.
JonWil: you can get any value now? how about getting the warhead that hitted you on damage void?
void Ra2Ven_DemoTruck::Damaged(GameObject * obj,GameObject * damager,float damage, const char* Warhead)
{
}
can you do a command to get the model name?
we already have the set command but i want a get command:
const char* model;
model = Commands->Get_Model(obj);
Ra2: Vengeance Project lead(it's Dead... sorry)
An empty Ghost since 2005.
|
|
|
|
|
|
|
|
|
|
|
|
| possible scripts.dll 1.8 in the works [message #91409] |
Mon, 31 May 2004 16:41 |
CnCsoldier08
Messages: 136
Registered: November 2003
Karma: 0
|
Recruit |
|
|
Haha, If SK is a n00b, I really want to know what you consider yourself to be. :rolleyes: And, do you even know half the shit SK has done?
Just because his isnt public...
WOL:tweekbee
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| possible scripts.dll 1.8 in the works [message #91465] |
Mon, 31 May 2004 19:24 |
|
|
Physics/vehicleflip/etc no.
Get_Model I can probobly do, dont know for sure yet.
Swimming is a nice idea that I will look into.
As for warhead, I dont think I can do that.
But it might be possible to do a command to find out what warhead the GameObject * damager object is using (although the issue of primary/secondary weapons will cause hiccups)
Mabie I wont use my flying infantry scripts to keep SK happy (I havent decided yet) but I will certainly be doing all sort of other stuff (including the other stuff from this thread), some of which will use engine calls.
And if SK or anyone else doesnt like me using engine calls (and btw, none of the ones that I will be using will be usefull to cheaters), tough, its my dll, you dont like it, you are welcome to fork it and release your own version (as long as you comply with GPL)
as for C&R_Damaged_Transporter , thats possible.
Basicly, all infantry units would have it attatched.
Then, when the unit is damaged, if its got less than <some value passed to the scripts so you can have different values per unit> health, it will send a custom to a specified object, with the ID of the unit its attatched to as the param.
This way you can have a standard object (with a particular ID that has to be the same for each map) that goes on each map (a Daves Arrow for example) that has JFW_Teleport_Custom on it.
Then you get a per-map location instead of needing it to be hardcoded for all maps.
Jonathan Wilson aka Jonwil
Creator and Lead Coder of the Custom scripts.dll
Renegade Engine Guru
Creator and Lead Coder of TT.DLL
Official member of Tiberian Technologies
|
|
|
|
|
|
Search
Help
Members
Register
Login
Home
