Alright then, satoon. Guess for now I'll just install all this stuff for myself, and by the time I release the plugin to public, I hope pip would be implemented. A bit off-topic: if I can't include a custom package myself, I believe I should post it in the Module/Package Submissions forum. Then, say...

What if we have two plugins and a lib ⋅ Plugin A. Depends on the lib not older than version 1.0, shipped with version 1.0; ⋅ Plugin B. Depends on the same lib, but version v2.0, because it needs the very latest features. Shipped with lib v2.0; ⋅ Lib. Version 2.0 is back...

Well, I'll hapilly ship my own plugin with PyMySQL and SQLAlchemy, but what happens if every other plugin comes with its own stuff to the site-packages directory? One plugin uses PyMySQL vX.X, another one vY.Y, the third one vZ.Z etc. They will override each other and we will end up with conflicting...

I didn't know there already was a talk about SQLAlchemy, and I'm glad I'm not the only one who needs it. Well, will be looking forward to seeing it shipped. But for now I'll have to somehow embed it by myself.

I'm afraid there's no such example when it can't be avoided.
It's all about objects. You can store them, pass them back and forth, and it's beautiful.

I knew I saw CSmokeStack somewhere And I guess that rendercolor and renderamt already had shortcuts.

from players.entity import Player from colors import Color from commands.say import SayCommand from entities.entity import Entity from mathlib import Vector from engines.precache import Generic as PrecacheGeneric PrecacheGeneric("particle/SmokeStack.vmt", preload=True) @SayCommand...

1st approach. This strips all weapons from a player: for index in player.weapon_indexes(): weapon = Entity(index) # TODO: BaseEntity would be enough here? player.drop_weapon(weapon.pointer, Vector(0, 0, 0), Vector(0, 0, 0)) weapon.remove() player here ...

Hey there, So I'm getting pretty close to porting functionality that depends on accessing a remote SQL database. In ES I used sqlite3 for local databases and pypyodbc for remote databases. The latter was chosen as the one written in pure python, supporting Python 2.5 and being one python file - thus...

You sure you're getting UTF-8 from u.read()?

I can assume that you're actually getting binary data from that, and StringIO won't work in this case.
Try adapting your code to ByteIO.

There's also this CServerTools::ReloadParticleDefintions function, I guess it may end up sending something to client. But I'm unsure what kind of file the function requires (manifest?) and how to call it.

No, I tried PrecacheModel and it didn't work either. It only works when I put the following manifest in /custom/myparticles/particles_manifest.txt particles_manifest{    "file"        "particles/my_particle_systems.pcf"    "file"        "particles/achievement.pcf"    "file"        "particles/blood_i...

Also found a post at AlliedModders claiming that CS:S is something special in this case: No any precache here, i cannot use my own particle systems by that code, Just spawn is simple enough... My friend uses 3 ddl's and a lot of code to use them at cs:s he's vid: https://www.youtube.com/watch?v=b0hZ...

I did. from entities.entity import Entity from engines.precache import Generic as PrecacheGeneric from events import Event from mathlib import Vector from stringtables.downloads import Downloadables PARTICLE_FILE = "particles/my_particle_systems.pcf" my_downloads = Downloadables() ...

Any way to make custom particles work in CS:S? I tried uploading my *.pcf file to a client, but the client doesn't seem to recognize particle systems inside of it Attemped to precache unknown particle system "my_particle_system"! ... Attempting to create unknown particle system 'my_particle_system'

I actually misread a lot in your suggestion, Doldol, I was sleepy (and I am), and I made some significant changes to my previous post. Main things changed: 1. I don't get the point of taking the target pattern out of the rest of the connection: "floor1_relay": ["Disable",False,0,...

Well, thanks for this idea, haven't thought of it. In fact, I only finished switching to JSON yesterday, before that I used to use the KeyValues format for my transitional files. The reasoning behind that was "my precompiler import VMF as KeyValues, let's keep it simple and export KeyValues too, eh"...

Is there no way to access VPK content internally? I mean, from the engine level as it mounts VPK. I guess working with VPK from outside means a lot of wasted RAM.

but I don't know of it keeping track of how many times it was fired Yes, later I learned about delays, but haven't got around to actually removing that tick_delays part. Regarding to keeping track of how many times it was fired, well, here you need some instance to track. Because you can't judge if...

Some of the entities don't get networked thus my first post didn't work with them. I included some additional code (that's even more code!), should work fine now. I hope some of the Entity functionality would move to BaseEntity so that I can reduce the amount of my code again. See also http://forums...