What would be the best way to approach removing features? (namely: the old CreateParticle)
I mean, I cannot simply replace the script function without breaking all existing scripts. Even if I marked it as legacy to remove it later on, I could not call the new particle function "CreateParticle" then because it would break all existing scripts who use CreateParticleEx then..
So? Mark as legacy, use CreateParticleEx and at some point rename that to CreateParticle and write a script-wrapper for CreateParticleEx?
The reason I want to remove it is because the new particle system can do anything the old could do, only better .
I mean, I cannot simply replace the script function without breaking all existing scripts. Even if I marked it as legacy to remove it later on, I could not call the new particle function "CreateParticle" then because it would break all existing scripts who use CreateParticleEx then..
So? Mark as legacy, use CreateParticleEx and at some point rename that to CreateParticle and write a script-wrapper for CreateParticleEx?
The reason I want to remove it is because the new particle system can do anything the old could do, only better .
Why not Ctrl+Shift+f the whole repos and search for C4Script functions which use CreateParticle and rename that to CreateParticleLegacy for now, and remove it from the engine when we replaced everything using the legacy code.
Then you can already rename your function to CreateParticle.
Also I'd suggest you start replacing some of the code, since you made the change.
Edit: Writing a wrapper sound like a very ugly solution to me.
Then you can already rename your function to CreateParticle.
Also I'd suggest you start replacing some of the code, since you made the change.
Edit: Writing a wrapper sound like a very ugly solution to me.
>Then you can already rename your function to CreateParticle.
And suddenly break all user-created stuff :/
Yes, I am sure they are able to Ctrl+Shift+f as well :)
This is how we did it in the past with proplists e.g. as well. Nothing to cry about too much I'd suppose.
Better than living with an ugly solution and obsolete engine code for ever. What do you think the control changes will do to user content?
We are still not developing a stable engine and never promised backwards compatibility with any previous version of Clonk (may that be OC or CR).
This is how we did it in the past with proplists e.g. as well. Nothing to cry about too much I'd suppose.
Better than living with an ugly solution and obsolete engine code for ever. What do you think the control changes will do to user content?
We are still not developing a stable engine and never promised backwards compatibility with any previous version of Clonk (may that be OC or CR).
>What do you think the control changes will do to user content?
Actually, I think there is only one think which is not 100% compatible: the IsReadyToUse callback prior to the OnUse. But even that won't break anything.
I might be terribly wrong though. Has been a long time that I did something in the controls branch..
I'd say "Better now than later", while user-created stuff is still.. rare.
>And suddenly break all user-created stuff :/
The Minecraft devs pretty much break all the user mods with every single update they make. Just sayan...
At this point, I see no problem removing the old functionality yet.
If you want to be extra nice, you can make sure the old function signature still works (so it doesn't error out with a type cast error) and just not create any particles. Missing particles shouldn't affect user gameplay that much.
If you want to be extra nice, you can make sure the old function signature still works (so it doesn't error out with a type cast error) and just not create any particles. Missing particles shouldn't affect user gameplay that much.
Are you planning on replacing the existing particles in the repos, at least?
Yes, that shouldn't be too much of a hassle, since I would just declare one static proplist per particle definition and use that to replace the old CreateParticle calls
Where would you define these proplist, can a particle constain a Sript.c or does that go into System.ocg?
A particle only consists of a graphic and a proplist defining behaviour, right?
The Particle.txt is still used to link the graphics to the particle name, though
I see, but since you can have different behaviours per particle now it makes sense to define a few standards in System.ocg :)
Because it's a technical decision how much we would like to break downward compatibility. No deeper reason, you can move it if you want to
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill