Print

Liero v1.0 – 100lt
IP: 37.205.11.54
Game Mode: Death Match
Lives: 7
Max Kills: 15
Version: OpenLieroX 0.58 rc3

Players:

Liero v1.0 – 100lt
IP: 91.156.42.210
Game Mode: Death Match
Lives: 5
Max Kills: 20
Version: OpenLieroX 0.58 rc3

Players:

Cruel v0.96 – 50lt
IP: 69.255.183.244
Game Mode: Death Match
Lives: 5
Max Kills: 0
Version: OpenLieroX 0.58 rc3

Players:
iRod(0 lives, 0 kills)
[CPU]I'm Not A Human(5 lives, 0 kills)
[CPU]I'm Not A Human(5 lives, 0 kills)

Unknown

Unknown – 0lt
IP: 89.73.201.14
Game Mode:
Lives: 0
Max Kills: 0
Version: LieroX 0.56b

Players:

Liero v1.0 – 8lt
IP: 89.73.201.14
Game Mode: Death Match
Lives: 20
Max Kills: 0
Version: OpenLieroX 0.58 rc3

Players:
Django(5 lives, 10 kills)
:P(6 lives, 9 kills)
DEFULT(6 lives, 19 kills)

[DarkCharlie]

Ok, I'll do that. Btw, your first post is too programmer-dependent, dunno if all modders will understand your syntax.

Five more things I just remembered. I'll write them here befre i forget them:
Specify projectile importance - when OLX runs out of projectile slots, projectiles with low priorities could be removed to be able to spawn new more important projectiles

Add DestroyAllChildren property to a projectile - when a projectile gets destroyed, all the projectiles it spawned will be destroyed as well (for example to destroy a snake when you hit its head).

Add a property to turn off shadows of the projectile.

Allow semi-transparent images!

Allow RGBA colors (semi-transparent) colors.

[Sakmongkol]

Btw, your first post is too programmer-dependent, dunno if all modders will understand your syntax.

That's what I was thinking, I thought there were some cool suggestions all over this thread but when I got to reading them listed in the first post, I couldn't understand much of it. I think you could keep that kind of syntax there, but also add a simple English description of what it means to us regular mortals. Would be appreciated

[albert]

For projectile priority: Don't you think that would make it too complicated? That means, for each spawning of a new projectile, you would have to check all other projectiles if there is no free place. (Or we would need to make other more complicated changes, like a register multimap<int,CProjectile*> (int is the priority) and check in there.) I am not sure if it is worth to do that. Hopefully we can minimize the amount of projectiles anyway by the new attributes (as there are less hacks needed).

Keep in mind for some of the other attributes you mentioned that they are also not too simple (or would make the whole current system a lot slower and would require a lot more memory). E.g. DestroyAllChildren means that we have to save a list of all spawned projectiles for every projectile.

[albert]

Btw, your first post is too programmer-dependent, dunno if all modders will understand your syntax.

That's what I was thinking, I thought there were some cool suggestions all over this thread but when I got to reading them listed in the first post, I couldn't understand much of it. I think you could keep that kind of syntax there, but also add a simple English description of what it means to us regular mortals. Would be appreciated

Well, you have a list of attributes already right now and that is just the list of new attributes. Each attribute has to have a name and a type (like e.g. if it is a number, or another projectile-type, or so).

I used the following type-names:
float: That is a accurate number, e.g. something like 1.25.
int: That is an integer, e.g. somethink like 42.
bool: A boolean value, so only two possible values: true or false
projectile_t: A projectile-type.
weapon_t: A weapon.

Are some of them unclear or does it make the first post more clear for you? I was already thinking there how we can name the attribute and which type it should have.

[DarkCharlie]

For projectile priority: Don't you think that would make it too complicated? That means, for each spawning of a new projectile, you would have to check all other projectiles if there is no free place. (Or we would need to make other more complicated changes, like a register multimap<int,CProjectile*> (int is the priority) and check in there.) I am not sure if it is worth to do that. Hopefully we can minimize the amount of projectiles anyway by the new attributes (as there are less hacks needed).

The check would be done only if the maximum of projectiles would be reached. And it could be of course optimized by remembering the lowest possible priority (therefore if you find such projectile, you can just remove it) and perhaps even more. Anyway, it was just a suggestion

Keep in mind for some of the other attributes you mentioned that they are also not too simple (or would make the whole current system a lot slower and would require a lot more memory). E.g. DestroyAllChildren means that we have to save a list of all spawned projectiles for every projectile.

Yes, that's right. Do you think that a list would make trouble? We could also use std::tree, but that would be probably very slow.
[/quote]

[pelya]

I think we can go without LUA if we'll implement (or better rip off from somewhere) the expression calculator - some finite state machine with a stack that converts expressions to Reverse Polish notation and substitutes variables to the pointer offset inside CWorm or CProjectile class, it will give the same possibilities as Lua, and we can optimize it and it possibly will get implemented faster. Ithe only problem is that our leet expression calculator should process int, bool and float types differently.

Oh, and "area damage" is not action, it's event - if someone is close enough to projectile, then make some damage to him.

BTW I don't want to make another mod compiler, let's parse gamescript right from source files.

[DarkCharlie]

Updated the first post.

[Reclip]

Mp3 support would be very nice, because mp3s save space.
Edit:
Are these updates going to make old mods unplayable??

[Sakmongkol]

Mp3 support would be very nice, because mp3s save space.

I guess OGG would be better for that.

[pelya]

No, old modding system will be supported 'till we all pass into oblivion.

Another proposition: when the weapon is guided, trigger some Events when user presses arrow keys (like GuidedKeyPress_Left, GuidedKeyPress_Jump and so on), so I can implement the Sheep weapon from Worms game - the sheep should jump around and be controllable with Left / Right keys, with Up key it will jump higher, when Fire key released it will explode. Maybe if Jump key pressed it stops being guided and explode on timer.

[miri]

let's parse gamescript right from source files.

Wouldn't that increase stealing like it's being done with the skins?

[pelya]

let's parse gamescript right from source files.

Wouldn't that increase stealing like it's being done with the skins?

It certainly will, but you can tell stealing easily anyway. We can do something as stupid as zipping txt files together and xoring zip archive - pretty noobish, but will prevent most noobs from decompiling a mod. I would rather not bother with that.

[albert]

I think we can go without LUA if we'll implement (or better rip off from somewhere) the expression calculator - some finite state machine with a stack that converts expressions to Reverse Polish notation and substitutes variables to the pointer offset inside CWorm or CProjectile class, it will give the same possibilities as Lua, and we can optimize it and it possibly will get implemented faster. Ithe only problem is that our leet expression calculator should process int, bool and float types differently.

Oh, and "area damage" is not action, it's event - if someone is close enough to projectile, then make some damage to him.

BTW I don't want to make another mod compiler, let's parse gamescript right from source files.

See my txt in SVN: doc/hirudo/EventBasedModEngine.txt

There are already some quite complete thoughts about this. Complete them or make other comments there if you like. But I think this is also more a longterm solution, nothing which can be implemented (in a clean way!) & fully tested within half a day, so a bit offtopic here in this thread.

Btw., I would keep the game compiler. It would make the parsing slower by factor of 20 or so (just measured by the size of the source compared to the binary; not to mention that the parsing is much harder). And it's easy to update the current game compiler (we just need to add the new attributes).

[jwei44]

Btw., I would keep the game compiler. It would make the parsing slower by factor of 20 or so (just measured by the size of the source compared to the binary; not to mention that the parsing is much harder). And it's easy to update the current game compiler (we just need to add the new attributes).

Are you talking about Game Compiler or LMS?

[DarkCharlie]

Btw., I would keep the game compiler. It would make the parsing slower by factor of 20 or so (just measured by the size of the source compared to the binary; not to mention that the parsing is much harder). And it's easy to update the current game compiler (we just need to add the new attributes).

Are you talking about Game Compiler or LMS?

Game Compiler, we don't have LMS sources.

[albert]

Karel, do you have a version of the first post before you edited it? You changed some of the vars in a way which makes their meaning much differnet then before I think. At least I don't understand some of their meaning not anymore. E.g., didn't we had somelink like ChangeWormSpeed? Now you have written UseWormSpeed and WormSpeed (with explanation to WormSpeed after shooting), which is totally different what I wrote before, something like that it changes the wormspeed by this value when hit. Would be nice if I could get somehow the different versions of the post.

[DarkCharlie]

Karel, do you have a version of the first post before you edited it? You changed some of the vars in a way which makes their meaning much differnet then before I think. At least I don't understand some of their meaning not anymore. E.g., didn't we had somelink like ChangeWormSpeed? Now you have written UseWormSpeed and WormSpeed (with explanation to WormSpeed after shooting), which is totally different what I wrote before, something like that it changes the wormspeed by this value when hit. Would be nice if I could get somehow the different versions of the post.

Hm, I doubt so. I didn't fully understand some things you wrote there so I wrote down what I thought they were. If you think there is something missing, just add it (but with a full description please). You can try Google cache to recover the original post.

[Griffin]

I don't think it's there already so I'd like to request recursive projectiles: e.g. we don't need 100 different text files for (almost) the same projectile, we can say that the projectile spawns itself. It should make mods a little smaller and cleaner.

[albert]

I don't think it's there already so I'd like to request recursive projectiles: e.g. we don't need 100 different text files for (almost) the same projectile, we can say that the projectile spawns itself. It should make mods a little smaller and cleaner.

Isn't it possible already for a projectile to spawn itself?

Or what do you mean?

[Griffin]

I don't think it's there already so I'd like to request recursive projectiles: e.g. we don't need 100 different text files for (almost) the same projectile, we can say that the projectile spawns itself. It should make mods a little smaller and cleaner.

Isn't it possible already for a projectile to spawn itself?

Or what do you mean?

If you make a projectile spawn itself the game compiler crashes because it appends a new projectile to the end of the mod until it runs out of memory.
(At least I think it does, it's been a while since I took a look at it.)