Getting a list of scripts that contain vehicle datablocks? (New Question!)

[BluetoothBoy]

So, I know it's possible to find out which datablocks are vehicle datablocks, but is there a way to find out their parent scripts (the .cs, that is)? Also, if I write to that script if it's in a zip, will it only do a cached overwrite, a complete overwrite, or not work at all? In case you're wondering why I need to do this, I'm trying to make a vehicle support addon. I don't want to give away what it is until release, though.

[Ad Bot]

[Zeblote]

So, I know it's possible to find out which datablocks are vehicle datablocks, but is there a way to find out their parent scripts (the .cs, that is)? Also, if I write to that script if it's in a zip, will it only do a cached overwrite, a complete overwrite, or not work at all? In case you're wondering why I need to do this, I'm trying to make a vehicle support addon. I don't want to give away what it is until release, though.

You can't write to files in zips. Blockland has an unpacker but that's all.
The engine stores which script created the datablock, but you can't access that without hacks. So what you're going to do is
1. find all files ending with .cs
2. make sure to only check in files from enabled add-ons
3. use fileobject to read file
4. scan for "datablock wheeledvehicledata"
5. check whether an actual datablock declaration follows
6. add file to a list if it does

However, you should NOT try to automatically modify scripts. that will end in massive FAIL most of the time. Instead, modify the datablocks / do it manually.

[BluetoothBoy]

Ok, since I can't write to the file(s), is it possible to detect individual vehicle collisions from a seperate server.cs?

Edit: The way I'd be modifying the script would be fairly foolproof because I'd just be adding a function guaranteed to work with any vehicle datablock. The problem is writing to the file. Since it seems this is highly improbable, I need to know whether or not I can detect individual vehicle collisions from a base server.cs that is not in any way connected to the vehicle scripts. And with your above post, I now know it had to be done without directly modifying the vehicle's script. I plan to take a look at Support_HeightControl later, since it does something similar to what I'm trying to accomplish; adding functionality to vehicles on an individualized basis.

[Swollow]

can you try to explain exactly what you're trying to do

[BluetoothBoy]

Well, I think I solved the problem now, I just need to test it. I might as well say it, since not many people view this board anyway.

What I'm trying to make is support for impact damage to players in vehicles. I though at first it'd mean adding a function to every single vehicle script. I was wrong; it looks like the following (untested) should work:

Code: [Select]

function WheeledVehicleData::onCollision(%this, %player, %client, %obj, %speed)
{
   Parent::onCollision(%this, %player, %client, %obj, %speed);
   if(%toggled)
   {
      if(%obj.getDataBlock().playerImpactDamage)
      {
         if(%speed >= %obj.getDataBlock().slowImpactSpeed && %speed < %obj.getDataBlock().fastImpactSpeed)
         {
            %player. //Subtract health here.
         }
         else if(%speed >= %obj.getDatablBlock.fastImpactSpeed)
         {
            %player. //Subtract health here.
         }
      }
   }
}
This isn't the whole code by the way, I have some more for toggling it on and off.

[Port]

Err, what? In your code, %player would be the vehicle that was hit, and %client would be the vehicle that hit it (if I remember correctly? it's been a while since I messed with collisions).

[Swollow]

Well, I think I solved the problem now, I just need to test it. I might as well say it, since not many people view this board anyway.

What I'm trying to make is support for impact damage to players in vehicles. I though at first it'd mean adding a function to every single vehicle script. I was wrong; it looks like the following (untested) should work:

Code: [Select]

function WheeledVehicleData::onCollision(%this, %player, %client, %obj, %speed)
{
   Parent::onCollision(%this, %player, %client, %obj, %speed);
   if(%toggled)
   {
      if(%obj.getDataBlock().playerImpactDamage)
      {
         if(%speed >= %obj.getDataBlock().slowImpactSpeed && %speed < %obj.getDataBlock().fastImpactSpeed)
         {
            %player. //Subtract health here.
         }
         else if(%speed >= %obj.getDatablBlock.fastImpactSpeed)
         {
            %player. //Subtract health here.
         }
      }
   }
}
This isn't the whole code by the way, I have some more for toggling it on and off.

I don't see why you need to loop through zips and write into the actual code of the zips

[BluetoothBoy]

Err, what? In your code, %player would be the vehicle that was hit, and %client would be the vehicle that hit it (if I remember correctly? it's been a while since I messed with collisions).

Oh crap, did I mix those up? Someone tell me the correct order, please?

I don't see why you need to loop through zips and write into the actual code of the zips

I don't need to, I just thought I did for some reason. I had a brain fart. A pretty big one too. :/

[Port]

WheeledVehicleData::onCollision(WheeledVehicleData dataBlock, WheeledVehicle obj, SimObject col, Vector3F direction, float speed)

So basically %this, %obj, %col, %direction, %speed.

[BluetoothBoy]

WheeledVehicleData::onCollision(WheeledVehicleData dataBlock, WheeledVehicle obj, SimObject col, Vector3F direction, float speed)

So basically %this, %obj, %col, %direction, %speed.

Ok, thanks. I'll be testing in a little while here.

[BluetoothBoy]

Update: I have the basic functionality down, but am stumbling across a problem. When I call applyDamage(); on the player, it works just fine, up until the player dies. Once the player dies (as a result of applyDamage();), he does not respawn, and the screen stops refreshing properly, causing me to need to return to the main menu. I am almost certain this is a direct result of the player being killed via applyDamage();, and was thinking of using kill(); instead of applyDamage(); once the player's health level is lower than the next applyDamage(); increment. This fixes the above issues, but I am wondering if it's the most efficient/reliable method. Is there, instead, a way to fix the screen upon player death (or simply not have it occur at all)?

[Greek2me]

Update: I have the basic functionality down, but am stumbling across a problem. When I call applyDamage(); on the player, it works just fine, up until the player dies. Once the player dies (as a result of applyDamage();), he does not respawn, and the screen stops refreshing properly, causing me to need to return to the main menu. I am almost certain this is a direct result of the player being killed via applyDamage();, and was thinking of using kill(); instead of applyDamage(); once the player's health level is lower than the next applyDamage(); increment. This fixes the above issues, but I am wondering if it's the most efficient/reliable method. Is there, instead, a way to fix the screen upon player death (or simply not have it occur at all)?

I believe that you should call Player::Damage, not ::applyDamage.

[BluetoothBoy]

I tried that in console, but it didn't seem to work, it just spat out "ouch" emotes.

[Xalos]

There are specific arguments you have to use. I don't remember exactly what they are.

If you don't care who hurt who or what damage type it is, however, you can just use %pl.addHealth(); with a negative value.

[BluetoothBoy]

There are specific arguments you have to use. I don't remember exactly what they are.

If you don't care who hurt who or what damage type it is, however, you can just use %pl.addHealth(); with a negative value.

Oh, really? That's kinda neat, I was wondering about that. I'll give it a shot tomorrow.