forum

Tweaks to _M parameter (storyboarding) ???

posted
Total Posts
7
This is a feature request. Feature requests can be voted up by supporters.
Current Priority: +0
Topic Starter
awp
This map has been deleted on the request of its creator. It is no longer available.
Cecilthemos
Wow, I'm not understanding any of that, I would totally do a story if it was an ingame editor rather than pure text...
Topic Starter
awp
I actually gave some thought into making a simple scripting script in Java because I have GUI fever atm

but I'm probably too lazy. The way it is now is easy enough to use (at least for those of us who think like compilers/script interpreters) and by the time I write a script-writer, assuming I have the motivation and energy to do so, peppy'll probably have in-game implemented already anyhow.
peppy
This map has been deleted on the request of its creator. It is no longer available.
eyup
I don't think you should have to choose between hard-move or tween when implementing what awp suggests; you just have to create a new parameter specifying whether it is a tween or not (1=tween, 0=hard move, or something). Hard moves should definitely be features available to storyboarders.

If I'm understanding properly, awp is only suggesting that a sprite's current x/y coords don't have to be inputs in the _M call, as they should already be known when calling the sprite anyway.
Echo
I've heard variable sized arguments usually get icky in coding?[/side thought] If this is implemented, I think eyup's solution is the best so far, by using 1 or 0 to differentiate between hard/tween.

However, we do have to remember that the UI will be implemented soon, so this wouldn't really make that much of a difference, unless you're someone who gets emotionally attached to manually typing out the storyboard. It's just 1 or 2 more arguments, and I think the current way (ie. explicitly saying what it's going to do) is better.

Hard moves can be down presently by repeating the (x,y) coordinates twice, I think.
Topic Starter
awp
It's true that this would only be a very brief change...to be honest, it's not really a big deal, either. I'm kinda getting used to it pretty quickly.

Though being able to have whitespace (hello tabbing) would certainly make things easier to read for me (I'm a bit of a whitespace nazi when I code) scripting is pleasant enough now with the error-catch that the client stops crashing on me every 30 seconds.

I'll just keep goin' with what we've got.
Please sign in to reply.

New reply