Iban Explains it All

[Brian_Smith3]

I still have no loving idea how to make a scope
Please rewrite scopes because I have no idea how to work them and it seems like you kinda put a little less effort into it.

[Ad Bot]

[Stocking]

Uh, hello? :|

The only time a debris object is created is by the engine during weapon fire states and in explosions.
 
You have a few options here:
1. You can create an explosion to pop out three shells in the onFire function.
2. You can create multiple image states in the weapon to fire out multiple cartridges one after another.
3. You can use a finite loop in the weapon states to call the firing state multiple times until there are no more preloaded rounds.

[takato14]

The only time a debris object is created is by the engine during weapon fire states and in explosions.
 
You have a few options here:
1. You can create an explosion to pop out three shells in the onFire function.
2. You can create multiple image states in the weapon to fire out multiple cartridges one after another.
3. You can use a finite loop in the weapon states to call the firing state multiple times until there are no more preloaded rounds.

1: I cant have two muzzlepoints.
2: That wont work. I cant control the image states from a function, thusly I cannot change the number of ejected shells depending on how many times the trigger has been clicked
3: Possible, but would make my current system entirely useless.


So what you're saying is that there is NO function that spawns a debris datablock. Nope, dont buy that.

[Plexious]

I have a question:

If I were to have a package and rewrite the same functions without using packages, would it still work? Do some things have to be packaged?

[Nexus]

have a package without using packages

hmm...

if you mean to rewrite a function without using packages, then the original will break.

[Stocking]

1: I cant have two muzzlepoints.
2: That wont work. I cant control the image states from a function, thusly I cannot change the number of ejected shells depending on how many times the trigger has been clicked
3: Possible, but would make my current system entirely useless.


So what you're saying is that there is NO function that spawns a debris datablock. Nope, dont buy that.

I'm almost 100% certain that there is no way to spawn debris. You'll have to make do with the state system or just half-ass it and only eject 1 shell.

I have a question:

If I were to have a package and rewrite the same functions without using packages, would it still work? Do some things have to be packaged?

I'm not quite sure what you're asking, but keep in mind the defintion of "works" is very flexible.

The idea of putting everything in a package sometimes rises up, because packages enabled after the server starts are automatically disabled when the server closes, and this prevents stray script from operating if the person restarts the server with your add-on disabled.

What bugs me is that there is no standards in add-on creation. Badspot seems to get a static shock whenever he tries touching the issue of add-on development for his own game and the only time he even posts about the subject is when talking about exploits being created or features being disabled. Nobody really knows how X should be done, and in a game like Blockland where almost all of the functionality can be exposed, this can be very bad when you have so many hands in the cookie jar that somewhere along the way something breaks and then you have a bunch of broken add-ons and even core game components not working.

But, to answer your question, it depends on what you want. Any function that is overwriting an existing function ABSOLUTELY MUST be in a package, otherwise you're destroying core game functionality. However, if we're going to create a brand new function that does not exist, it does not need a package, no.

The best thing to do when trying out hypotheticals like this is to just make a quick and dirty script and try it out. Learning any programming language is usually as simple as using it.

[Greek2me]

But, to answer your question, it depends on what you want. Any function that is overwriting an existing function ABSOLUTELY MUST be in a package, otherwise you're destroying core game functionality. However, if we're going to create a brand new function that does not exist, it does not need a package, no.

Not entirely correct. If you are completely overwriting a function, chat for example, you do not package the function. This would cause all other mods that package chat to parent your chat function. The danger there is not including all the functionality of the original function, but if you do, it works fine. You have to do this in some cases to change things, like name color in chat.

If you are only adding a check or something that occurs before or after the original function, you package it.

[Stocking]

Not entirely correct. If you are completely overwriting a function, chat for example, you do not package the function. This would cause all other mods that package chat to parent your chat function. The danger there is not including all the functionality of the original function, but if you do, it works fine. You have to do this in some cases to change things, like name color in chat.

If you are only adding a check or something that occurs before or after the original function, you package it.

I struggle to imagine even one scenario in which it would be advantangeous, ethical, and practical to overwrite core game functionality without a way to disable or turn the effect off.

You're literally destroying something that cannot be replaced without a game restart. It's unacceptable to do that, ever.

• Packages can be disabled, leaving core game functionality working as intended.
• Packages are automatically disabled once the server shuts down, preventing interference with other mods with stray script if the server owner reboots the server without your add-on enabled.
• Overwriting a function prevents the add-on maker from adding in an option to disable certain features with something as simple as a boolean variable change, using something like Ephialte's RTB Preferences.
• Making Badspot's scripts not working can forget with other people's add-ons, and assuming that the add-ons aren't complete trash in the first place, this is a great sign of disrespect and poor ethic.

It's not OK to destroy core game functionality, ever. There's no reason to, and any reason invented has a simple work around with packages. This is not up for discussion.

[Kalphiter]

I struggle to imagine even one scenario in which it would be advantangeous, ethical, and practical to overwrite core game functionality without a way to disable or turn the effect off.

Preventing a player from mounting to a vehicle where we stop a function that mounts them to a vehicle

Code: [Select]

package GSFnoMount
{
    function WheeledVehicleData::onCollision(%this, %obj, %col, %vec, %vecLen)
    {
if(%col.client.GSFmount == 1 || %obj.dataBlock !$= "carriervehicle")
    Parent::onCollision(%this, %obj, %col, %vec, %vecLen);
   
    }
};

function servercmdnomount(%client)
{

    if(%client.GSFmount)
    {
%client.GSFmount = 0;
%status = "un";
    }

    else
%client.GSFmount = 1;

    messageClient(%client, '', "You are now "@ %status @"able to mount to aircraft carriers");
}


[Stocking]

Preventing a player from mounting to a vehicle where we stop a function that mounts them to a vehicle

Thank you for proving my point. There's a package in there that only filters out some functionality in a very controlled environment

[Nexus]

Any situation where someone creates a weapon addon, or any addon with a projectile, usually has a non-packaged collision function.  Many special playertypes do the same thing with arrmor::ontrigger.
Any worthwhile chatmod completely overwrites servercmdmessagesent.
Just a few common examples

[Greek2me]

I struggle to imagine even one scenario in which it would be advantangeous, ethical, and practical to overwrite core game functionality without a way to disable or turn the effect off.

The ONLY way to properly modify chat, as Nexus just said, is to completely overwrite serverCmdMessageSent. I had to overwrite it and completely rebuild it so I could change the name color in chat based on team.

[Stocking]

Any situation where someone creates a weapon addon, or any addon with a projectile, usually has a non-packaged collision function.  Many special playertypes do the same thing with arrmor::ontrigger.
Any worthwhile chatmod completely overwrites servercmdmessagesent.
Just a few common examples

You're not overwriting core default functionality when you are creating scripts for your specific add-on.

ConsoleObject
- Lots of other Classes -
ProjectileData Namespace
Specific ProjectileData
Specific Projectile

All you're doing is adding a function for your Specific ProjectileData. If you were to write something over the ProjectileData namespace, that would be core functionality.

The ONLY way to properly modify chat, as Nexus just said, is to completely overwrite serverCmdMessageSent. I had to overwrite it and completely rebuild it so I could change the name color in chat based on team.

Rewriting any function, including serverCmdMessageSent and serverCmdTeamMessageSen, is considered a hack. While it's true that the structure of the chat system is rigid and hardcoded so it's not possible to add your own colors, that doesn't excuse the fact that it's still considered a hack to rewrite how the chat system works. Hacks should always be considered a last resort and these sorts of exceptions are not even worth the merit of including in a post about the Parent/Package system because if you're resorting to a hack you're already reaching a point of desperation and ethics are irrelevant.

[takato14]

So what you're saying is that there is NO function that spawns a debris datablock. Nope, dont buy that.

Would still appreciate some help here...

[Nexus]

You're not overwriting core default functionality when you are creating scripts for your specific add-on.

I was mostly referring to the questions about packaging, but it is considered overwriting default functionality.  Honestly it is a bit of a stretch to call much anything "core" unless it has something to do with torque itself.

Would still appreciate some help here...

Try a trace for when derbies are spawned.