I wholeheartedly agree, but I'm not sure where that came from... That applies most to closed projects though, as with open projects, especially on Git, you can compare changes submitted by multiple people, and utilise whatever parts of them you wish. It creates an ever-outward-spiralling changelog; and it is absolutely a pain in the arse.Originally Posted by Gleeok
When you have a project that multiple people work on you really don't want to be working on the same thing, or sometimes even the same files. It's already complicated enough without having conflicts that can create bugs. It's not like it's random or anything. We've thought about updating the scripting engine and removing allegro for a long time. It's mostly straight-forward except in this case where I kind of forgot what's going on with the enemies. My bad.
When I say 'replace' ffcs I'm talking about a more general mechanism for scripts to create scripts and handle game related stuff. For example: How many times have you created an ffc that has NO COMBO data set because you just want a script to run. I'm guessing lots.Also there would not be 32-per screen limit and there would be no memory or runtime overhead for scripts that you do not create.
As far as docs go I probably wouldn't read them anyway.
Anyhow, this is why I usually limit participants on projects that are extremely complex, or I make everything modular as hell. If you want to glimpse what I've been doing for the last three years...
https://github.com/ZoriaRPG/RPG_zh/t...ha-Development
Lots of files there. Thank goodness I have a documentation volunteer for all of that mess. Sort of like you do for this, except that I can never get a full, straight answer, when I need one to do any real work on internal code docs. :p
No complaints about a new object that allows that kind of thing, as long as classic ffcs are retained. I'd also advise prebuffering the classic ffcs only on screen loads to solve the mem issue, but we both know how complex that would be. Warps are the real problem. I have ideas on how this could work, but it's not high priority for me.
Between you and Saffith, you probably don't need such documentation, bur if you want people to contribute to this, we pretty much need those types of reports, to know what the flidd is going on. I glanced through some of the AngelScript stuff, but I have no idea how much is actually working, what works at all, or how much is in use, and not there as a placeholder, and what is next on the agenda.
Really, a simple plain text file that lists wat's working, not working, planned, and paused, would be good. Some list of what aspects need assistant / contrib coders, would also be good. Otherwise, multiple people will be working on the same things, out of sheer ignorance.
Did I really need to put a <sarcasm> tag in my remark; because a Skype dev group would, while amusing, be so fundamentally flawed and impractical, as to be worthless, for something like this. That's why I said 'neverending'. Do you know how many messages you end up with, having only four, or five participants, after a month or two? It's flipping sickening.
Sorry if you took that literally. Also, I know that neither Gleeok, nor Saffith use Skype, and I know that you don;t either...so, again, did I need a visible <sarcasm> tag, as i can always tack those on all over the place.
On another note, if Microsloth keep ruining it, I may shift messaging paradigms too, or move to an open-source client for it. I already can't run it on any of the OSX systems that I use, or to which I have access, which ruined one nice feature of being able to run it on a remote machine, and use VNC to log in and chat. They're such a bunch of tossers...
I do second the motion to make the dev forum public.
Reply With Quote