How to get rid of Karts?

[mech 3]

Was funny on 1st of april. Not funny anymore.

Karts keep spawning as civil vehicles.

Please fix this asap. Give us an option to deactivate in command line pls.

[vegeta897 13]

Since the karts are in civilian vehicles, whatever script you're using to spawn them is simply grabbing from that list. Either the karts would have to be moved to a different classification, or the script will have to be modified. From a programmer's perspective, having a script dig out whatever it can find in a location that may have undesired content (in the future, or via mod) is not a very good coding practice.

What if BIS added some other vehicle, not part of a DLC, that you wouldn't want the script to spawn, but that would also be classified as a civilian vehicle? Perhaps a very large industrial vehicle that clips into buildings when the script spawns it, and explodes. Still a valid civilian vehicle on its own, that fits in a military simulator, but since the script is not written in a safe future-proof manner, things like that can happen.

The best option is for the script to explicitly list which vehicles it wants to allow. This is a basic concept of safe programming.

Edited June 1, 2014 by vegeta897

[mech 3]

You can't hardcode any classnames anywhere because

1. BIS has a tendency to change them from time to time.

2. That way you won't get any addons that the Admin !decided! to use.

Fun content must not be in the same lists as usable content.

But BTT: I need a fix for the bug and I need it fast or nearly all spawn Systems are screwed for our next mission.

[vegeta897 13]

You can't hardcode any classnames anywhere because

1. BIS has a tendency to change them from time to time.

2. That way you won't get any addons that the Admin !decided! to use.

Fun content must not be in the same lists as usable content.

I think you miss my point. It's about programming reliably.

What if BIS added some other vehicle, not part of a DLC, that you wouldn't want the script to spawn, but that would also be classified as a civilian vehicle? Perhaps a very large industrial vehicle that clips into buildings when the script spawns it, and explodes. Still a valid civilian vehicle on its own, that fits in a military simulator, but since the script is not written in a safe future-proof manner, things like that can happen.

A large industrial vehicle is not "fun content", but could easily cause problems with scripts that do not allow for vehicles outside of the parameters that may have held true at the time, but no longer do.

You have a good point about BIS changing class names, but that doesn't exactly nullify the idea of safe programming. BIS tries to avoid that as often as possible, and it should be happening less and less.

Your #2 point is exactly what I'm talking about. What if an admin decides to use something that unknowingly breaks some script that didn't plan for it?

Any script that relies on a change-able source of data is asking for trouble.

If you want a fix, get a list of the current class names that you want to spawn and use that list exclusively.

Edited June 1, 2014 by vegeta897

[mech 3]

A large industrial vehicle is not "fun content", but could easily cause problems with scripts that do not allow for vehicles outside of the parameters that may have held true at the time, but no longer do.

No such vehicle addon on my dedi. If I launch that on my Dedi, that I have to take care of that. If not, then not.

So you are going to give free coding to every community after they decided which addons to use and give them custom Alive spawnscripts? And custom COS as well if they want to use that too? And also after every update?

Your idea only works in a closed environment and until yesterday, I thought the best thing of Arma was, that it's open. Funny thing: I still like how it's open to the community but I'd prefer BIS to never ever again to release any DLC.

[vegeta897 13]

No such vehicle addon on my dedi. If I launch that on my Dedi, that I have to take care of that. If not, then not.

It was a hypothetical. It would be perfectly possible for BIS to add a large industrial civilian vehicle to the game, that in turn causes scripts to spawn them too close to buildings because the scripts assumed all vehicles it would ever spawn are below a certain size.

Your idea only works in a closed environment

No, see, that's the exact opposite. A closed environment is when there isn't a chance for unforeseen content to be added. I'm suggesting programming practices that allow for unforeseen content additions (and by "allow for", I mean do not break or cause undesired results, as you have brought to our attention). That's an open environment where anything may be added. Scripts are going to break in an open environment if they make assumptions about what content they are accessing. If you made this script that spawns civilian vehicles, you made the assumption that every vehicle that would ever be added to that classification was going to be acceptable. Turns out it wasn't, lesson learned.

Ask any experienced programmer who has had to work with unpredictable data.

You went with an inclusive rule instead of an exclusive list because it's more convenient. You can easily add vehicles you want and the script will use them. That's fair enough. But you have to accept the reality that it's not going to be 100% reliable if you go down that road. BIS is not going to cater to your preferences when it comes to these things. A gokart is a civilian vehicle.

Edited June 1, 2014 by vegeta897

[mech 3]

It was a hypothetical. It would be perfectly possible for BIS to add a large industrial civilian vehicle to the game, that in turn causes scripts to spawn them too close to buildings because the scripts assumed all vehicles it would ever spawn are below a certain size.

That should actually not be possible. Why would they force that on us? Why not create stuff as addon? BTT to solution finding:

No, see, that's the exact opposite. ...I'm suggesting programming practices that allow for unforeseen content additions (and by "allow for", I mean do not break or cause undesired results, as you have brought to our attention). That's an open environment where anything may be added. Scripts are going to break in an open environment if they make assumptions about what content they are accessing. If you made this script that spawns civilian vehicles, you made the assumption that every vehicle that would ever be added to that classification was going to be acceptable. Turns out it wasn't, lesson learned.

Ask any experienced programmer who has had to work with unpredictable data.

That sounds fun... you want to work with unpredictable content that you can only get from a list but you can't use that list because you know that the list includes garbage starting with K... or Z....

Any ideas? I'm serious... and the solution should also be serious because all addon programmers need to know this from now on. Any ideas in SQF?

[vegeta897 13]

unpredictable content that you can only get from a list

Get from a list once, not dynamically in the script. If you get it dynamically, you can get unwanted things. It's more work, sure, but it's 100% guaranteed to work (save for BIS changing class names, which I do not consider a common occurence) if you explicitly type out the string class names you want in your script.

I'm not an SQF programmer so I couldn't begin to tell you how this is done. You probably would know more than me. I'm speaking about common programming concepts that apply here.

[mech 3]

Get from a list once, not dynamically in the script. If you get it dynamically, you can get unwanted things.

Not possible because addons change, get added or removed. That's the idea of addons, you can decide to use them. Your idea makes any addons unusable in spawnscripts because the programmer would have to recreate his spawnsystem for every addon out there. You can only get that list at time of launch. Other ideas?

I'm speaking about common programming concepts that apply here.

Don't get too much into theory. We are talking ArmA here mate ;).

[vegeta897 13]

It comes with the territory, as far as I'm concerned. Why the assumption that every addon you download is going to have the classification you desire in order to be used by the scripts you want?

I agree with your point about addons being based on choice while DLC or other official patches are not. That's a good point, but like I said before, it still doesn't mean we should program recklessly. Your motivation here is convenience, whereas I see it as due diligence: If you acquire an addon and want your scripts to use it, it's not insanity that you should have to modify your scripts to do so. Maybe some of the scripts that would have included the vehicle automatically, you do not want to.

Hey now, the only sure way to limit yourself as a scripter or programmer is to ignore good practices. You can't grow that way :)

[mech 3]

It comes with the territory, as far as I'm concerned. Why the assumption that every addon you download is going to have the classification you desire in order to be used by the scripts you want?

I don't. It's my server and my responsibility to make sure it works. We are talking month of testing and preparation to get the map to the stage in which it is now. We have a carefully selected list of addons and new ones get tested, added, old ones removed... That's how this works. Especially if you have a game like ArmA3 without any usable content (polished, funny looking cars, aliens as enemies,...). But thanks to BIS we have the addon system that always gave us the choice and responsibility to add or not to add.

...That's a good point, but like I said before, it still doesn't mean we should program recklessly. Your motivation here is convenience, whereas I see it as due diligence: If you acquire an addon and want your scripts to use it, it's not insanity that you should have to modify your scripts to do so. Maybe some of the scripts that would have included the vehicle automatically, you do not want to.

I know you mean good buddy but I think you don't understand the pure "size" of the problem here. You say that every server admin that wants to use addons must know how to change Alive, COS, EOS, DAC,... to suit his addons? He must decompile and change every map that uses spawnsystems? Even if we go that way, can you even imagine how many hours of programming we are going to waste here? I can't... to big a number for me.

ArmA was a modular system and such a system should always be ready for chosen and selected new content.

But to use your argumentation: You want us to save some data (civilian-, east-, west-vehicles, units,...) not once but twice. Once in the system where I can dynamically request it and once in every script that I use to avoid any "forced" content. You know what that will always produce: Errors. After a change of classnames or removal of buggy content (you know that there is actually an alien tecture in A3?) you'd have to change every script out there. That also means every map or addon using any spawnscript. Your theory is nice but won't work here.

Edited June 1, 2014 by mech

[I give up 152]

Also I would like to know how to disable this.

I know, by default, we are not able to disable expansions and this never was a problem for me with ARMA 2 mainly because all the expansions are directly related with game theme.

Now, when we have a expansion obviously not related with game theme (at least the theme that was announced when I got the game) having the option to disable it would be a great help and would save us from inumerous troubles.

[Jona33 51]

I will admit I don't know how the spawning systems work, but (this is how I would have done it) if they created an array of all the civilian vehicles in your config (and randomly selected a vehicle from that to spawn) it should be doable to remove the known Kart classnames from that array. This means that you would only have to know the classnames of the vehicles you didn't want which would be something atleast. Though obviously in your situation that's not as good as simply disabling the DLC. Would simply deleting the Karts pbo work or would that just produce a small sh*tload of errors?

I don't know the actual code but something like

_availablevehicles=[getConfigList];

_Acceptablevehicles=_availablevehicles-["Kart1","Kart2","Kart3","Kart4"];

Then select random from _AcceptableVehicles

Edited June 1, 2014 by Jona33

[almanzo 144]

My first thought was also to make an exclude list instead of a list of vehicles to actually spawn. Must be easier to maintain than an allowed spawn list.

[vegeta897 13]

My first thought was also to make an exclude list instead of a list of vehicles to actually spawn. Must be easier to maintain than an allowed spawn list.

Good idea, an exclude list would in theory require less frequent updates than an include list. Unless BIS goes nuts and adds all manner of silly vehicles in several separate DLC :P

[Darkhorse 1-6 16]

So let me get this straight. You're blaming Bohemia because they broker a user-made script? If they had broken their own civilian/vehicle module I could understand this thread, but you're pissed that because they added karts to the civilian faction it's broken a user-script? You're crazy, tovarisch. Seriously.

[Nashable 10]

Yup a blacklist (exclusion) that filters out the main list would probably be best to get the results you want.

[mr burns 132]

My best guess would be a (serverside only) config replacement for following class names and making them scope = 0 :confused:

C_Kart_01_Blu_F
C_Kart_01_F
C_Kart_01_F_Base
C_Kart_01_Fuel_F
C_Kart_01_Red_F
C_Kart_01_Vrana_F

[SavageCDN 231]

So let me get this straight. You're blaming Bohemia because they broker a user-made script? If they had broken their own civilian/vehicle module I could understand this thread, but you're pissed that because they added karts to the civilian faction it's broken a user-script? You're crazy, tovarisch. Seriously.

Yeah I don't get it either. I think he's probably referring to ALiVE (DAC would not be affected by this.. not sure about the other 2 mentioned) which pulls from config classes. Next ALiVE update will have the carts blacklisted.

[thenach 10]

Blacklist will work as long BI keeps the same name for the classes during updates... something we know BI does not do.

To avoid future problems I think It will be good if the blacklist could be edited.

[maddogx 13]

Blacklist will work as long BI keeps the same name for the classes during updates... something we know BI does not do.

To avoid future problems I think It will be good if the blacklist could be edited.

Haven't the class names been stable since 1.0? I thought they only wanted to change them during alpha/beta.

[haleks 8212]

You can't hardcode any classnames anywhere because

1. BIS has a tendency to change them from time to time.

2. That way you won't get any addons that the Admin !decided! to use.

Fun content must not be in the same lists as usable content.

The over way around is easy though : just modify your script to exclude unwanted vehicles.

I don't really see what's the problem here, except the pain to do a quick modif to your script...

---------- Post added at 13:58 ---------- Previous post was at 13:53 ----------

Haven't the class names been stable since 1.0? I thought they only wanted to change them during alpha/beta.

There may have been a couple of changes after that, but I don't recall being annoyed with that in a long time.

[thenach 10]

Haven't the class names been stable since 1.0? I thought they only wanted to change them during alpha/beta.

actually no, check the last Zeus update.

[Harzach 2517]

actually no, check the last Zeus update.

What was changed? Regardless:

Edited June 6, 2014 by Harzach

[gdscei 1]

I still like how it's open to the community but I'd prefer BIS to never ever again to release any DLC.

"ermehgerd, I have to add 2 lines of script to my spawning scripts, I don't want that, so thousands of people are not allowed to have fun with DLC!" I mean, seriously, how can you be so inconsiderate and selfish?

Protip:

if(!(_vehicle isKindOf "Kart_01_Base_F")) then{
// spawn the vehicle here
};