mods: SetLayer (by int) and IntOperator (with logical ops)

[Andy22]

Hi,

just two simple modifications for the default actions, one was requested by a other member and i noticed the lack of logical operations in the int action.

bye Andy

[jeanfabre]

Hi,

 This is great, but I would definitly not recommand making mods of existing actions, UNLESS you rename it properly, like SetLayerV2 or SetLayerByInt or something. Here we are not dealing with bug fixing, but with a different approach.

I guarantee that you will forget about this mod and on the next playmaker update, it will be overwritten and your project will bug and it will take you quite some time to fix this.

So, always prefer making existing actions mods with different names.

bye,

 Jean

[Andy22]

I guarantee that you will forget about this mod and on the next playmaker update, it will be overwritten and your project will bug and it will take you quite some time to fix this.

So, always prefer making existing actions mods with different names.

Ofc u are right will rename the actions/attachments properly.


bye Andy


PS: In our case we use PlasticSCM and we already need to always automatically modify UFPS and some other sources, so PlasticSCM would take care of this automatically for us.

[jeanfabre]

Hi,

 Can you explain the process with plasticSCM? quite curious about this actually.

bye,

 JEan

[Andy22]

Can you explain the process with plasticSCM? quite curious about this actually.

U basically create a branch with a specific changeset that includes all changes and reapply/remerge those automatically after each reimport of the org. package.

So we have a branch for UFPS changes and we need to simply remerge the changes back to the main branch after a upgrade. We could probably setup this somehow, without the need to manually trigger the re-merge, but thats literally seconds.

If we would license there new SemanticMerge tool, we could even automatically re-merge extremely complex changsets with ease. We circumvent this atm, by just merging the "partial" keyword to the UFPS source file classes and then we can add, change logic to our needs in a other file. So we avoid doing more complex changes to the org. source files, which may need human intervention.

Ofc thats not a optimal solution, but there is no other way sometimes and we need something that works, until it might be solved by the org. source author.

bye Andy

[jeanfabre]

Hi,

 ok, I see, thanks for the explanation. Indeed, sometimes you have to do what you have to do to get it working!

bye,

 Jean

[Lane]

That sounds pretty interesting.. I've been stepping on eggshells when updating my packages recently as I've started butchering them quite a bit and don't want to lose my changes accidentally. My alternative was to just make my own versions of stuff I change so it doesn't get overwritten but its *mostly* with art assets so has been pretty straightforward, keeping up with my script changes has been harder for me.

[Andy22]

That sounds pretty interesting..  keeping up with my script changes has been harder for me.

For the short time we use PlasticSCM we are quite happy with it, the UI and possibilities are a bit overwhelming at first, but if u ever worked with svn and now can practically create and remerge "real" branches thats like working with a total new way of SCM.
At first i did not believe the "one branch per changeset/job" statement, coming from a svn background, but now i just laugh at people using svn and similar systems.
It really changes the way u handle/apply code changes and is not some funky marketing slogan. Its also much faster than svn btw and even can handle gigabyte of asset data too, without some stupid "largefiles" hacks (yes Mercurial i look at u!) :p

We still have to try the Unity PlasticSCM plugin, but i delayed this evaluation until next year.


bye Andy

PS: Btw i did evaluate the SemanticMerge for c# and just wow! This actually works and i wish this had been around for c++, while i was working on really large projects and each svn checkin was merge hell!