OpenXcom Forum
Contributions => Programming => Topic started by: Yankes on December 20, 2014, 03:27:45 pm
-
Isn't this time to warp thing up and create new milestone?
Most mods don't work with 1.0 if it work with Nightly and vice versa.
Lot of new stuff was added, and probably recent SupSuper patch (loading original saves) could be "selling point".
Another this is that Warboy is now focusing on TFTD it could introduce breaking changes that break mods (like recent map changes).
New milestone could create new environment for mods authors to work in without worrying about changes in nightly builds.
-
I'm pretty sure a lot of the discussions about what to use which milestone numbers for included at least partial TFTD support for 1.1.
And if Warboy has to break mods in an upcoming patch, he might as well branch the development for TFTD, and figure out as many things he'll need to break as possible, so he can break them all at once.
-
It doesn't break mods more than it already did with nightlies. All changes are already going into the master, they are simply unused in Xcom1Rulesets.rul.
-
It doesn't break mods more than it already did with nightlies. All changes are already going into the master, they are simply unused in Xcom1Rulesets.rul.
And that is the problem, many mods depend on specific nightly and when someone upgrade to latest can't go back because old one aren't publicly available.
We have already couple people and mods affect by this.
My point is that current 1.0 is obsolete for mod authors, many great features was added after it. My suggestion is to create alternative that will be protected form breaking changes.
Version of this new milestone is irrelevant. It could be 2.0, 1.1 or 1.0.1, only important is content of it.
-
And that is the problem, many mods depend on specific nightly and when someone upgrade to latest can't go back because old one aren't publicly available.
We have already couple people and mods affect by this.
My point is that current 1.0 is obsolete for mod authors, many great features was added after it. My suggestion is to create alternative that will be protected form breaking changes.
Version of this new milestone is irrelevant. It could be 2.0, 1.1 or 1.0.1, only important is content of it.
At the same time, the more milestone versions get released, the bigger the confusion. And preparing a milestone takes time that could be better used to further development.
If you release a new milestone at this point then it will break a lot of mods, plus it is likely that those mods will need to be updated, again, if something is changed on further nightlies and when TFTD gets finished. So for some mods you'll need 1.0, others 1.1, and then there will still be mods that only work with the latest nightly.
My point is that current 1.0 is obsolete for mod authors, many great features was added after it. My suggestion is to create alternative that will be protected form breaking changes.
1.0 is completely fine for me regarding the Terrain Pack and for a lot of other mods. I've made a deliberate decision of keeping the updates to my mods compliant with 1.0 due to a number of reasons:
* Most players won't care about downloading a nightly just to try a new feature.
* It can take a lot of time to be constantly updating a mod that requires a nightly.
* And the new nightly features required by mods have a minimal impact in the overall game, despite what we mod authors would like to believe :)
So, if you choose to use nightly features in your mods, keep in mind that you'll have to deal with the above points.
-
And that is the problem, many mods depend on specific nightly and when someone upgrade to latest can't go back because old one aren't publicly available.
Really, mods are tertiary in this respect. Breaking someone's mod shouldn't care developers or stop of making necessary changes. Why should it?
Xcom1 support and bug-less matters. TFTD support and bug-less matters. Everything else is pretty much irrelevant.
You can stick with your mods to obsolete 1.0 version, or constantly update your mod to work with nightly (because nightly is "almost-final"), or go both ways, if you don't mind wasting time on 1.0. Thing is, in the end mods for 1.0 will simply be updated to nightly.
There's no point to support 1.0. Any bug reports considering 1.0 are actually ignored long time. In the fact it's the past.
And I would suggest anyone update mod version to work with nightly, and drop 1.0 support (Frankly, most of mods aren't even broken). There's good point not to live in the past.
-
volutar you didn't get my point. I want exactly that, drop 1.0 as "official" current version and introduce new one that have all features from toady nightly.
Because of current focus on TFTD most modders could focus on this new version.
And I don't propose any change to how nightly work, it break mods and this is fine, but I think it would be good if most of features from toady nightly could be available in more stable environment.
And lastly as you point out, current 1.0 is bugged, maybe It should be updated by bugfixed one? :)
Overall it won't be bad if we don't have new version until full TFTD support is implemented, but I think it would be more healthy for community if we have new milestone available.
-
Yankes, 1.1 version, besides obvious gameplay fixes and patches, and tftd supporting things, should also include noticeable amount of "quality of life" things, to be much more attractive than 1.0. And there are not much of them right now. Need some more. And then, perhaps, new milestone will popup. I guess it will be first months of 2015.
-
Yankes, 1.1 version, besides obvious gameplay fixes and patches, and tftd supporting things, should also include noticeable amount of "quality of life" things, to be much more attractive than 1.0. And there are not much of them right now. Need some more. And then, perhaps, new milestone will popup. I guess it will be first months of 2015.
What urgent QoL changes do we need for 1.1? Really QoL changes can be added at any point that we're NOT trying to lock down bugs and create a milestone build.
-
Obviously bugs are pretty well known, and only couple of them left and to be fixed.
QoL things - offscreen walking (under panel walking) and primed grenade indecator in battlescape (not only in inventory). Pretty much that's it.
-
You know...you don't need a blessing from above to have a stable point.
Start a thread and simply come to an agreement on which nightly is a good endpoint. Once divined, consider that version OpenXcom 1.1. Thats the version everyone considers plateau if they so choose. Put a link of it on the mod site. Mention it in the download of your mod. Etc.
IMO, asking the Vactican to give you a new Pope is going to be a small exercise of frustration.
-
You know...you don't need a blessing from above to have a stable point.
Start a thread and simply come to an agreement on which nightly is a good endpoint. Once divined, consider that version OpenXcom 1.1. Thats the version everyone considers plateau if they so choose. Put a link of it on the mod site. Mention it in the download of your mod. Etc.
IMO, asking the Vactican to give you a new Pope is going to be a small exercise of frustration.
:o, Supsuper does not tolerate child molestation in the openxcom team!
More seriously it seems like a worthwhile idea:
1. Grab the latest nightly and fork it.
2. Link it in a forum post and on the mod site as 1.1.0
3. Address any serious bugs that arise in the forked version as versions 1.1.1 - 1.1.5 etc
4. Label mods as 1.1.x compatible until the Scooby Gang releases 1.2.0 with TFTD support.
That way Warboy and Supsuper can continue whatever it is they're doing and not get blamed if anything goes awry. I'd do it myself but a) github confuses me because I'm not a real programmer so even if I managed to fork a nightly I probably wouldn't be able to rebuild it if after any bug fixes, and b) I don't follow OXC stuff reliably, modders/players would need someone that checks their inbox more then twice a month in case a link breaks or something.
-
Mods are NICE but they can be updated to match the current release. Is not a big deal. Just a few rul changes probably. I think devs should do what they be doing making the engine better and not have to worry about breaking mods. Right now for me at least TFTD support would be major improvement be more like version 2 than 1.1.
-
We've given up on 1.1 because:
- Everyone is waiting on TFTD. Everyone. Nobody cares about little fixes and improvements, we've gotten much more requests about TFTD than issues in the bug tracker in the last year. Everyone wants the shinies.
- Modders keep attaching themselves to the latest nightly, which triggers more fixes and requests, which makes the "stable" constantly shift forward. Everyone wants the shinies.
So for us, trying to reach stability is pointless. You've forced our hand, it's full speed ahead until TFTD (2.0). There will probably be a pre-2.0 to iron everything out but that's it. If you wanna pick a "nightly" to stick to, feel free.
-
Foolish decision.
SupSuper, your problem is care not for the game, but for the community.
-
At least we know about it. Better than not knowing ;-)
-
Foolish decision.
SupSuper, your problem is care not for the game, but for the community.
Ok you pick a suitable milestone now that we're half-way into TFTD and that won't just get us tons of comments asking where's TFTD.
-
and that won't just get us tons of comments asking where's TFTD.
Why should that bother me?
When there are two ways:
1. Ironing out code, fixing bugs, vanillifying, and THEN adding features.
2. Adding features, multiplying bugs geometrically, and THEN trying to fix them (in some unseen future).
I would pick first. And noone's comments and requests for features gonna change that.
There is a programmer's rule. And it shouldn't be broken. Not even if the Pope is asking.
-
Foolish decision.
SupSuper, your problem is care not for the game, but for the community.
Did you read different post that I? SupSuper did exactly what you ask him to do, don't stop and go speed ahead to TFTD support.
I would preferred different decision, but I will support it.
And second point, without community would be no OXC.
-
The way I see it, adding TFTD support changes the internal structure enough that exclusively fixing bugs might end up being a waste of time since many areas end up getting rewritten anyways.
Besides, it's not like SupSuper is the only coder only working on TFTD. There is also bugfixing at the same time; they just merely don't warrant an official release.
The same justification applies to mod compatibility - the quest for TFTD also will alter the mod code, so going from a theoretical stable release between now and the TFTD release would just offset the compatibility complaints further down the line as more TFTD features get added to the nightlies. But once TFTD support is more or less finished, there isn't much more in the way of significant new features to add, so mod support will be less prone to breaking changes in future versions.
-
Did nobody notice this thread? https://openxcom.org/forum/index.php/topic,3287.0.html
Pick a commit that is stable, fork it, have the community crown it as 1.1. Cherry-pick some commits that fix relevant bugs if need be.
-
SupSuper did exactly what you ask him to do, don't stop and go speed ahead to TFTD support.
Why do you think I asked that? I wasn't ASKing. I was accounting on making wise decisions. And ramming forward towards features by the cost of accumulating bugs is not wise. Or you can end up with the version more buggy than vanilla TFTD.
The way I see it, adding TFTD support changes the internal structure enough that exclusively fixing bugs might end up being a waste of time since many areas end up getting rewritten anyways.
TFTD support doesn't touch battlescape code yet. And yet, battlescape has lots of bugs to fix and things to polish, and will affect xcom1 and any other played mod. But instead - new bug-o-features gonna be added to geoscape, which will postpone battlescape fixing even more.
-
We've given up on 1.1 because:
- Everyone is waiting on TFTD. Everyone. Nobody cares about little fixes and improvements, we've gotten much more requests about TFTD than issues in the bug tracker in the last year. Everyone wants the shinies.
- Modders keep attaching themselves to the latest nightly, which triggers more fixes and requests, which makes the "stable" constantly shift forward. Everyone wants the shinies.
So for us, trying to reach stability is pointless. You've forced our hand, it's full speed ahead until TFTD (2.0). There will probably be a pre-2.0 to iron everything out but that's it. If you wanna pick a "nightly" to stick to, feel free.
I'm a hungry dog circling the table, ready to chew any piece of food that somehow drops from it.
1. I think things.
2. I implement what I can.
3. I check the Nightlies section and see that the latest one adds "cool feature x" and "amazing stuff y".
4. I use it right away so I can implement more/ better the things I thought initially.
5. Rinse and repeat.
Also asking is a collateral activity of what I'm doing; doesn't mean though that you have to do what I ask or rush to it.
I feel I'm in no position to declare a potential "stable", I don't even know well the development roadmap to tell when is a good time to stop the train, I don't even know the TFTD ETA to tell if it makes sense to have "pit-stop" or rush.
I think the key point if you decide to have 1.1, is not to release "shinies" for a bit after it, so modders won't immediately have new shiny things to flock to (they will; I will).
(Modders at this point are sticking to the latest nightly also because they are ephemeral, the nightly you choose to stick to could disappear from download page relatively soon).
-
When there are two ways:
1. Ironing out code, fixing bugs, vanillifying, and THEN adding features.
2. Adding features, multiplying bugs geometrically, and THEN trying to fix them (in some unseen future).
I would pick first. And noone's comments and requests for features gonna change that.
There is a programmer's rule. And it shouldn't be broken. Not even if the Pope is asking.
I can only agree here with volutar. First the iron, then the bugs -> stable well running code.
Then add new features on a solid an properly working codebase, iron them, fix their bugs, then next feature.
Build code in steps testing each segment to the heart, and when you know it is working perfectly then the next.
In the end your overall codebase, will be more stable.
I rather tend to fix bugs right away then let them queue up in the long run, because even if you have written the code yourself, not looking at specific sections (because they are considered working) will only bring you more pain, more time consumption on fixing bugs etc..
anyway my 2 cents.
-
I actually quit modding when the map rework was introduced. I was busy, and it caused problems of many kinds, which I did not know how to address or even identify.
When I work on project, I tend to do it in an incremental way: Introduce Feature, Test, Debug, Fix -> Release new version -> Restart.
There have been a few features that would have warranted new releases since I have been interested in OpenXCom, the main ones being: Two weapon tanks and the new map stuff. Tanks were really wanted by users and Maps made big changes. Shortly after their introduction, when sure that things work, releasing v1.1 (Tanks) and v1.2 (Maps) would have been great.
Mods could then say: "Works with v1.*" and everybody would know what to use them for. My mod collection works with "v1.1" or rather what I defined as "v1.1" myself: A certain build that had 2 weapons HWPs but not the crazy map stuff.
For a certain time, no mod worked with "v1.2" if it had anything to do remotely with maps (including crafts). Mod authors would need to do nothing, since their mod would states "Works with v1.1", it is implied that it does not with v1.2. Much better than a slew of bug reports from people trying to use the mod with a nightly build and being entirely unaware that something changed overnight. Having the nightly gives some people the false impression that they have something stable, it's the nightly! After a while people would have gotten around to updating their mod and could apply the "Works with v1.2" seal or, if they are really daring, "Works in nightly" which I personally would never use.
The other thing is: I have no idea where to get the info about what's new in a nightly and how to cope with it. Sometimes the XCom1Ruleset.rul changes and you can guess at what's needed, other times you can't. Is there a resource somewhere with informative content as to what was committed for those who can't read the OpenXCom code?
-
Having the nightly gives some people the false impression that they have something stable
I don't really understand this. It says on the download page for the nightlies that they are prone to having the latest bugs. Plus this is true of any other programming project out there.
If anything, I think it's mostly the fault of modders. I understand the need to use the biggest and best features, but it's the modders and not the devs in this case that push people to keep up with the nightlies rather than for testing purposes. In most other modding communities, people generally are reluctant to officially release mods using features unavailable in latest stable versions. If they do, they also make clear what build the mod is intended to work with. This prevents all the confusion you mention.
The other thing is: I have no idea where to get the info about what's new in a nightly and how to cope with it. Sometimes the XCom1Ruleset.rul changes and you can guess at what's needed, other times you can't. Is there a resource somewhere with informative content as to what was committed for those who can't read the OpenXCom code?
Yeah, the changelog on the nightly download page (https://openxcom.org/git-builds/) describes changes, and so does the commit tracker on Github
I'm still not seeing the "adding features before fixing bugs" tendency that some of you mention the devs have. Look at the commits yourself. (https://github.com/SupSuper/OpenXcom/commits/master) Almost every other commit is a bugfix. Much of the time the reason the bugs don't get fixed until later is that it is a while before they are even found, and usually are in fact uncovered by the addition of new features. Looking over code relentlessly does not yield anywhere near the amount of discovered bugs that users and testers are able to find.
-
I'm still not seeing the "adding features before fixing bugs" tendency that some of you mention the devs have. Look at the commits yourself. (https://github.com/SupSuper/OpenXcom/commits/master) Almost every other commit is a bugfix.
And it should be ratio of like dozen(fixes) to one(feature).
Most of recent gameplay fixes was mine and dozen should be made. But surprise - the bugfixing has been moved away from the path towards buggy tftd. I can't understand this. And can't figure fair excuse.
-
I don't really understand this. It says on the download page for the nightlies that they are prone to having the latest bugs. Plus this is true of any other programming project out there.
Well, this comes from reading posts in mods (or troubleshooting) where users say they encountered an issue and when asked what they use just reply "the nightly" without any associated date or other way of finding out what they are actually using. IT then often turns out that they are using either an old nightly that doesn't work for the mod, or one that is too recent for which the mod is not ready..
If anything, I think it's mostly the fault of modders. I understand the need to use the biggest and best features, but it's the modders and not the devs in this case that push people to keep up with the nightlies rather than for testing purposes. In most other modding communities, people generally are reluctant to officially release mods using features unavailable in latest stable versions. If they do, they also make clear what build the mod is intended to work with. This prevents all the confusion you mention.
The problem is that in most other games, you don't go straight from 1.0 to 2.0, you get 1.1, 1.2, etc. as well. In OpenXCom, that did not happen. It very much looks like we will go from EU to TftD with nothing in between even though the game itself has changed a lot from 1.0.
If you want a new feature, you have to use the nightly. And obviously, people want the new features and modders want people to want to use their mods. We could wait for the next 1.* to release a new version of a mod, but not for 2.0. So far, it seems rather difficult to "pick" a nightly because, since there is no shared decision on which to pick, you would get a series of mods that all use different versions of the game. That's totally useless, so modders either stick with 1.0 (ie the latest stable version) or chase the nightly but inevitably fall behind when life and a big update happen simultaneously. And there's some people who think we should all use the nightly to help find bugs and support the project on top of that...
Yeah, the changelog on the nightly download page (https://openxcom.org/git-builds/) describes changes, and so does the commit tracker on Github
I'm still not seeing the "adding features before fixing bugs" tendency that some of you mention the devs have. Look at the commits yourself. (https://github.com/SupSuper/OpenXcom/commits/master) Almost every other commit is a bugfix. Much of the time the reason the bugs don't get fixed until later is that it is a while before they are even found, and usually are in fact uncovered by the addition of new features. Looking over code relentlessly does not yield anywhere near the amount of discovered bugs that users and testers are able to find.
I am well aware that looking at code doesn't do you nearly as much good as trying to run it in terms of finding bugs, but it is not something that we can all do. I can code, I spend most of my work doing that, but I can't code in C++, neither can I really make sense of much of what changed in the commits.
What I was asking is whether there was a source of information on how to cope with the changes/what they did/what their impact is for modders who can read yaml and are familiar with OpenXCom but not its code. This recent commit (https://github.com/SupSuper/OpenXcom/commit/4d51d1e218757eeb7e31538355c5a502a8b01db2) is great: it tells modders how to cope with it. Now take look at most other commits that may impact on gameplay/mods and it says rather little. The big map script commit being an obvious offender (which has thankfully been taken care of since, I think).
-
If you want a new feature, you have to use the nightly. And obviously, people want the new features and modders want people to want to use their mods. We could wait for the next 1.* to release a new version of a mod, but not for 2.0. So far, it seems rather difficult to "pick" a nightly because, since there is no shared decision on which to pick, you would get a series of mods that all use different versions of the game.
That is why I got really upset about. There was a definite way to 1.* version (1.1 or 1.2 or 1.5), and suddenly that changed. "WTF!" was the first thought seeing that.
There was a plan of getting that intermediate versions, at least one, with dozens of gameplay fixes and changes being made (not only crashes), and know what? - they gonna never be released until TFTD! "F that", I would say! It's not they way how things should be done! That really pissed me off, and STILL doesn't let go.
There should be really "stable" release with all noticed issues being fixed. You know, there was no stable releases. At all. 1.0 was full of hilarious bugs.
For the God sakes, let LPers and modders rely on some milestone stable release for the next 1/2 years until 2.0 come...
Sorry.
-
Don't apologize volutar, you're standing up for the community ;) I, for one, fully agree!
I currently use a nightly from the fall (after 2 weapon tanks, before map scripts) that seems to do things pretty well for what I want. So should I label my mod as "Works in nightly 2014-10-22"?
You can't download anything older than the 31st of January (but for good ol' 1.0 of course) so there's absolutely no point on doing that. I might as well be the sole user of my mod and not publish it instead of requiring something 99% of users won't be able to find.
And would users go through the trouble of getting an old nightly instead of grabbing the most recent one and benefiting from its most recent developments (along with the mods that can manage to follow)? It is harder to get an old nightly than the most recent one, after all...
If there were a 1.*, it would be easy to grab for users (the milestone is much easier to install than any nightly) and it would change much less frequently (so it would be easier to keep on top of things for modders).
Plus, encouraging the users to run the latests milestone would mean that developers get relatively reports of recent bug (the old ones having been purged from the milestone), instead of things that happen in 1.0. So it helps with the development as well, whereas 1.0 users don't really.
Seems like a Win/Win/Win scenario to me...
Did nobody notice this thread? https://openxcom.org/forum/index.php/topic,3287.0.html
Pick a commit that is stable, fork it, have the community crown it as 1.1. Cherry-pick some commits that fix relevant bugs if need be.
I just replied there (just got back to OpenXCom from a few months break). It indeed doesn't really have to be picked by the devs, but it should be released on the main website as 1.1 as well. There's no point in modders picking a nightly to use as 1.1 if regular users coming in still install 1.0 and the only nightly available for Windows only go back 2 weeks (and I have no idea how to pick for Mac or Linux..).
The next milestone, regardless of who picks it (devs or modders) has to be widely distributed so that users will use it instead of other version. The whole point of publishing mods is for people to use them. If only modders use the modders' milestone, then it's pointless.
-
i'm kinda with volutar on this one... while supsuper does make a good point about the fans demanding tftd, i think we might see more "benefit" from stabilizing the code for another milestone build, if for no other reason than to try and migrate people away from the year and a half old build. maybe we could alter our approach a little too? like have a "stable" branch that receives critical bug fixes, and continue working on the nightly branch until we reach another "milestone". the fans may be disappointed that there's no tftd, but an update to the "standard" could make things a lot better for everyone, modders and bughunters inclusive. i'll grant you we don't have a suitable candidate at this exact moment but it's still something we could work towards?
-
I concur, Warboy. The moving target is hard to cope with. I'd gladly go with a newer milestone before TftD. As much as I love TftD, I think that its going to be so much harder than the original, I'm probably OK, with staying here in OpenXcom enjoying mods for a while.
So count my small vote in on settling on a patched 1.1 milestone, before TftD.
-
I wouldn't hope for good result with the twin release concept (a. current nightly with all changes, b. stable with only critical fixes).
First of all, that would harden devs lifes (make commits and fixes for both will raise human factor mistakes). And only that alone would make that "no-no".
Second of all, devs gonna be blind in terms of bugtest with the "a" release, because community will prefer "b", and devs don't have "bugtesting crew".
Thirt, it wouldn't really help anyone, having that "half-updated" milestone.
Bottom line - I see no weighty point of going that way.
I remember when 1.0 was released SupSuper said that we should probably start making more frequent milestones. I really liked this one, and hoped it would be for real.
And by the way, I don't see why TFTD supporting version should be named "2.0", it could be named "1.4" or "1.5" just as just another milestone.
-
Probably because 1.1 (which it would be given the current direction) is nowhere near glamorous enough for OpenTftD. And TftD is the 2nd xcom so it seems fitting..
I agree that keeping the nightly and milestone on the same branch is probably best. I will soon setup the same as Hobbs has started using, to give it a bit more momentum.
-
yeah, fair enough, splitting the tree doesn't really alleviate any of the problems and probably makes things more confusing all around
-
Eh, why not create "stable" branch on git and use standard approach to release schedule? Only we need is maintainer for that branch, who would say "Yes, this commit good enough for release candidate/release/gold" and will backport all needed fixes from master branch.
No only LPlayers and modders need stable release, package distributors from Linux also wants hard tarball with version on it.
-
Eh, why not create "stable" branch on git and use standard approach to release schedule?
Why? What for? Is it necessary to multiply entities? What's wrong with keeping it as before just not to neglect making milestones?
-
Because you can't maintain stable release and backport fixes without importing all changes between stable milestone and actual fix. These changes can also have bugs.
Your approach require model "as fast as can" with 3-4 week between releases. Otherwise you cannot catch up HEAD with features and bugfixes.
SupSuper's approach (as I can see) is "ship it with huge features" with 0,5-1 year release cycle.
So my suggestion is compromise between them - "release not often but with bugfixes and small features" with 2-3 month cycle.
-
Because you can't maintain stable release and backport fixes without importing all changes between stable milestone and actual fix.
Can't devs just release milestone 1.1 (from the main branch) as planned and move on as usual? Without making mess, huh? o_O
-
Can devs decide witch exactly commit is bug-free and stable as rock for 1.1? Eh?
-
Can devs decide witch exactly commit is bug-free and stable as rock for 1.1? Eh?
Was 1.0 bug-free and stable as rock? Hell, no!
It's not easy to find a commit which would be more buggy than 1.0.
So the answer is - yes, certainly, to a greater extent, than it was with 1.0.
New milestone should be "stable" in the sense, which Meridian and Ivandogovich were telling. "not moving target". Not updatable until next milestone. So it's absolutely nonsense idea to make some weird fork with partial, cherry-picked commits, and to hope these commits gonna be more "bug-free" than same commits for the main branch.
-
Why not pick the most stable nightly and simply call that 1.1? This will advance most people who don't like the nightlies 1 year forward. Get that nightly git pull branch the one that people swear by it being the most stable one. Nothing is bug free. What you want is no game breaking bugs.
-
So TFTD is going on hold? Well doggone it!
Before the milestone build, add something someone suggested awhile back. Letting us rename our operatives in the inventory equip screen. Just click the name and edit. Thanks to whoever came up with that. That's a feature that fans will like to see.
-
no, tftd isn't on hold at all, work is progressing at full steam, we're simply discussing the release schedule
-
That is why I got really upset about. There was a definite way to 1.* version (1.1 or 1.2 or 1.5), and suddenly that changed. "WTF!" was the first thought seeing that.
There was a plan of getting that intermediate versions, at least one, with dozens of gameplay fixes and changes being made (not only crashes), and know what? - they gonna never be released until TFTD! "F that", I would say! It's not they way how things should be done! That really pissed me off, and STILL doesn't let go.
There should be really "stable" release with all noticed issues being fixed. You know, there was no stable releases. At all. 1.0 was full of hilarious bugs.
For the God sakes, let LPers and modders rely on some milestone stable release for the next 1/2 years until 2.0 come...
Sorry.
You got a lot of nerve.
First, may I remind you, that you were the one that pushed into renaming the stables as milestones, because you always found them "old and buggy". You were the one that pushed into making the nightlies more prominent on the site, if not just make nightlies the only way to download the game. You are always pushing for major changes and features for the sake of "vanillaness" which often lead to a lot of problems and bugs to be fixed later down the line. You were involved in all the recent major structural changes to the game just for TFTD vanillaness, like map scripting et all, which create a whole lot more issues. In fact if it was up to you 1.0 would never have been released because it wasn't "good enough". But sure, act surprised, insult the devs, slander our work, claim only you know what's best and just want "stability".
Second, "1.0 was full of hilarious bugs". That's funny, we've had over 100k downloads of 1.0, and I've never seen anyone suffering from such major game-breaking bugs that completely ruined their experience and made it impossible for them to play and enjoy the game. But I'm sure you're right, people everywhere just can't stop denouncing our bug-ridden mess. We would've saved a lot of time if we just hadn't bothered. After all, 0.9 was feature-complete, we could've just left it at that. Instead we spent over an year just on fixes, quality of life changes, reworking the options, mod support, saves, even including a lot of stuff you called for like integrating the Adlib music player which took a lot to get everything right, all so the community would get the best experience the deserved, a worthy milestone they could look to without needing to keep up with changes. But I guess instead we should just leave them with the nightlies, even though there's only 10 nightly downloads to every 100 milestone downloads.
After 1.0 we thought of just settling down and putting out quick releases with just little fixes and changes, but the demand for TFTD was overwhelming, and soon development just darted in that direction, so we made that our goal. This is not news, all the major changes since 1.0 have been done in the name of TFTD and moddability. The engine and battlescape changes, externalized UI, externalized globe, dual fixed weapons, map scripting, etc etc. The actual vanilla gameplay experience is largely the same. This doesn't mean we just mindlessly put out feature after feature, it means we're working towards a goal. A lot of these features have major impacts to the game, requirements brought on by TFTD keep changing them up and we may need to rethink our solutions over and over until everything's straightened out and we reach "stability". I think just stopping and leaving all these associated features half-implemented is much more dangerous and prone to bugs, as we have to support and live with everything we made for the release, and will just upset people further if we keep pulling the rug between releases.
But I also don't like reliance on nightlies. If you look at most games you will not see nightlies, at most you can only get the latest nightly hidden away somewhere. That's it. The goal of nightlies is testing and experimenting for people that can't compile code. If there is a bug in the stable, they can check if it's still in the nightly, and if so, report it. You can also use them to get testing before a release or experiment with new features. But they are a programmer tool, ever-changing with the code and should not be relied upon.
However, OpenXcom has a slow development cycle, so I conceded and let people have nightlies to get to play with stuff earlier. Now the community pretty much lives by the nightlies, and every request is answered with "get the nightly". The problem is nightlies are not releases. They are automated builds made from the latest code. These code changes can have huge to no visible changes to players. The commit logs might make sense or they might be complete gibberish. There are no instructions or installers. New nightlies might come every hour or every month. So this often just leads to tons of confusion and bewilderment as players are repeatedly told to grasp something not designed for them.
On top of that, it limits the dev team too. We can no longer do big sweeping changes and experiment as necessary, we can't do lots of small iterative changes, because every public change we make to the code is expected to be stable and working. We often have to keep adding in workarounds and compatibility for WIP changes that people ended up relying on. If we have to make anything big, we have to keep it in private for days or weeks until we're sure it's all good to go, during which none of that code can be collaborated upon.
And that, I consider a personal failure, and I am deeply sorry the OpenXcom release cycle has come to this. OpenXcom has always had a big focus on the community, and I always do my best to provide you support, but the nightlies are a big thorn in that. Not everyone may agree with me. Reading this thread, it's pretty clear not a lot of people agree with me and I don't see eye to eye with a lot of issues going on, and my posting just seems to incite more arguing and misinformation. So I'm out, I'd rather stay behind the scenes doing what work needs to be done. Warboy will handle the release schedule however he sees fit.
-
I didn't imagine the situation to be this dire. I started modding relatively recently (with 0.9 already out) so I don't know how it was before. I started using nightlies because the sheer amount of new pro-modding features was too appealing to pass (my aliens mod are still 1.0 compatible actually). If you want nightlies to go "under the radar" I think a new milestone (so called 1.1) should be made, there's just too much difference with 1.0 at this point. And then *maybe* (I don't know) come up with a solution so modders don't have tons of new features "locked" in nightlies for 1 year or so after the milestone. I can turn off the "frenzy mode" if it's for the best of the project, but please don't leave me behind too much, I'll get frenzy again if you do (I don't know if there are that many modders that use nightlies, could be that they're just very vocal?).
(I also didn't expect nightlies to be stable or retro-compatible, I though they were the wild west; and actually finding them reliable encourages people in using them).
My intention in writing my 2c in this topic wasn't to make people flip tables. I apologize if I did.
-
I don't want to sound flippant or insensitive, but wasn't Volutar banned for this kind of abrasiveness? Did I miss something?
-
My intention in writing my 2c in this topic wasn't to make people flip tables.
I'm mostly with Robin on this: I don't want to take sides in a debate, don't care that much about mods, etc, if I offered an opinion it was as a free exchange of ideas between people who love this project. I'm very grateful for anything that is out there, very grateful to all the devs etc, and nobody is going to be the supsuper usurper.
OpenXCom has taken my favorite game of all time, which happened to have been released in 1994, and made it fun again in 2015. I had no idea that 100k people agree. That is a very remarkable achievement.
-
I think most modders do things that work under both the nightly and 1.0. Stuff like adding XCom weapons/armors/crafts and tweaking the research/manufacture.
The "need" for the nightlies mostly comes from players and a (few) avid modders. A fair few invested (=vocal) players will want to use features like 2 weapon tanks and will get convinced to install the nightly even if it is a bit more complicated in order to take advantage of a mod that offers it. Once the player uses the nightly, more ambitious 1.0 mods (dealing with aliens/deployments/missions/etc.) stop working so other modders decide to "upgrade" to address the issue.
If we could get a 1.1 milestone soon after the currently ongoing alien mission redesign, it would encapsulate everything we have so far (and include more new features like the possibility to have terror/artefact-like missions so the cutting edge modders can take advantage of it). Then even the casual players who installed 1.0 could upgrade since it's no more difficult to install one milestone than another, so we actually gain in terms of following for the modern OpenXCom.
From then on, developers could be free to do the next large scale "game breaking"/unstable work that's needed for TftD, release it nightly for those who want to be testers while not worrying about breaking the game for players. Players and modders would be happy with a stable 1.1. Once the next "major feature" or "big step to TftD" is implemented, we can get 1.2.
Is releasing a milestone complicated? Or could it not just be a matter of "Alright, new feature X has worked as intended for the past week, we patched a bunch of bugs, here comes milestone 1.Y"? Something like: "Multiple fixed weapons implemented, players want it -> QC -> Make milestone -> work on something new", "The map script works as intended -> Make milestone -> work on next feature" and soon "Mission redesign completed -> Make milestone -> work on new feature".
Nobody is going to complain if we get milestones every few months. It's much less work than compiling a nightly every week or even day and is a rate that modders can cope with easily in terms of updating mods to keep them working.
Plus, seeing the digits after the 1. go up gives everybody a sense of excitement that TftD is coming closer!
-
Arthanor, I like how you think. My perspective is really from the player, and hobby modder (not an overly ambitious one). Nightlies feel like a bit of a moving target for me, and I've been pretty happy with 1.0. I know Volutar is pretty unhappy with me continuing to advertise 1.0 in my LP, and feels like that just freezes the project in the past, and doesn't help push the project forward. I really don't know if that is the right perspective or not. I'd be satisfied with a Quarterly milestone or something, but I'd also be happy right where I am.
I think I am most disappointed that SupSuper has gotten so frustrated that he's ready to disengage from the release process and just work behind the scenes. I completely honor and value his role in the project, and I feel like his contribution is incredibly important.
Most importantly, I want the Dev team to know that I for one, support them and just want to facilitate whatever it is they are doing. If feeding them Scooby Snacks would help, I'd set up a constant supply to ensure they had everything they need. :)
-
First, may I remind you, that you were the one that pushed into renaming the stables as milestones, because you always found them "old and buggy". You were the one that pushed into making the nightlies more prominent on the site, if not just make nightlies the only way to download the game.
Because people keep using outdated version. Temptation to use "stable" no matter how old it is, really inevitable. That's why I wanted to make nightlies more available and prominent. Because we lack of good thorough tests. Only players and LPers can get into situations. And what's the point of them getting into already fixed situation inside of obsolete version?
But obviously people still prefer "milestones" over the nightly (as you stated 100/10 is the ratio). What can we do? Just to make another milestone, apparently. Why are you surprised with that logic?
You are always pushing for major changes and features for the sake of "vanillaness" which often lead to a lot of problems and bugs to be fixed later down the line.
That's the developing concept. You won't get any progress otherwise. You can't make things entierly bugless with the first try. Good testing is important.
You were involved in all the recent major structural changes to the game just for TFTD vanillaness, like map scripting et all, which create a whole lot more issues.
As far as I remember, this update didn't cause LOTS of issues. You're exaggerating.
In fact if it was up to you 1.0 would never have been released because it wasn't "good enough".
Yeah, if it was up to me, Currenty we would have 0.95 or something. But it doesn't mean we woulnd't make milestones. Number is irrelative here.
But sure, act surprised, insult the devs, slander our work, claim only you know what's best and just want "stability".
Insult devs? Are you kidding? I'm one of them, I'm feeling responsibility of what's going on with the project, and I can't stand aside and ignore not wise (from the perspective) decisions. There was no schedule plan in the first hand. Whole project was like "as it goes", and for you it was surprise that it came to so trustful vanillish state. Frankly, not lot of people trusted it CAN be that trustful. But I trusted what I knew. Because I was the one who digged insides of vanilla and made them replicable with that level details. If not with this project, then with another.
And really, "stability" is not of my concern. It's what players are expecting. Not lots of people are willing to test bugs and help BY DEEDS project evolve (not only by words). The only way to do that - is either block really outdated milestone version from loading (which is bad), or keep up milestones.
Second, "1.0 was full of hilarious bugs". That's funny, we've had over 100k downloads of 1.0, and I've never seen anyone suffering from such major game-breaking bugs that completely ruined their experience and made it impossible for them to play and enjoy the game.
Oh, come on. Really?
There's a list of what was fixed since 1.0: fire didn't spread (at all); after been hit AI woke up towards any, not towards the shooter (as it should be); AI got stuck at barn's windows; celatids didn't miss and could spit through entire maps; radar ranges were generally smaller; radar ranges of the alien ships were 3 times less -> 10 times less chances to retaliate => need to artificially adjust detection chance for higher difficulties; retaliation didn't stop even after base defense mission is won; wrong soldier experience allocation; sporadic battlescape crashings and hangings (due to direction of facing, or MCing by aliens and blocked paths); wrong kneel TU reserving; sometimes broken autosaves; smoke was always illuminating; melee accuracy really wrong (it was almost 110); landing time was 5 times shorter => almost no chances to get to landed UFO in time; blocked vision for diagonals; free grenade prime for AI; tanks got vanished after ufo defense "repel" screen; wrong 20th turn logic; reaction/los distance mismatch; promotions were wrong; annoying "hidden" walk under panel (quick animation); offset of fire origination caused mass "no line of fire" and corner hits. Plus different QoL things, like inventory templates and armour cloning with RMB.
The project cries for the next milestone. No matter how many of TFTD features are implemented.
I just don't feel postponing next milestone until full list of TFTD features gonna be completed (until summer in best case) is right decision.
-
Yeah, I also know my share about the pressure from the community.
@Devs: after a certain level (and I think we've reached that level already)... just do whatever you think is best. With sufficient amount of people on the forum, you will find all sorts of people. People who will have different opinions, different priorities and different attitudes. You will find people who love the project, who like it, who dislike it, you will find trolls and you will even find people who will (willingly or accidentally) hurt the project. You will find people who know how to listen and collaborate, but you will find also people who think only they are absolutely right and everybody else is absolutely wrong. You will find people who know what your work is about and how much time it consumes, but also people who have no idea and their first post will be why is TFTD taking so long? (It is basically the same game, it shouldn't take more than 2 weeks, right?)
Well, that's how it is.
You cannot listen to everyone; and for OXC's sake please don't try to satisfy everyone.
I honestly wish you strong nerves and endless patience with us, mere mortals.
I support any decision you will make (except stopping the project of course) and look forward to new features, new mods, new TCs and everything else. It doesn't matter if it takes 2 weeks, 2 months or 2 years! Just do whatever you feel is right.
-
First of all, i am gone say that so far this project seems to be a success and the entire developer team put a lot of effort into it to rewrite this awesome game which we all love so much, for us, with us, for themselves.
It's a matter of fact that the last release Version, which was 1.0, seemed to a great success. People accepted it, Let's player started playing it, promoting it on Youtube etc...
It is also clear that a release version usually should go through a testing phase, a code review, which lead to major bugfixes and so on. But this is something a small Opensource Project maybe not able to handle, because it requires much more resources, more people to review the code etc.. So you are basically stuck with bugs which get reported from the people who play the game. This has obviously happened as the difference between the newest nightly and release 1.0 in terms of fixed bugs and stability of the game has been greatly increased (i so far never had any crashes from openxcom itself, mostly Mods not finding files (case sensitivity and so)).
And since it is now nearly a Year since Version 1.0 has been officially released, i would recommend implement Missionsite stuff, fix whatever bugs there are (which are known), fix them. Make a big anouncement release it as Version 1.1,
not only Modders would profit from that but also a load more people which give free advertisement (the let's players), which tend to go for release Versions, because not anybody is willing or able to compile code itself, or install the required libraries.
Keep working on the TFTD support, release your changes over the nightlies and when you have reached a state in which the basic features for TFTD are implemented, do a new release. Fix bugs over nightlies, so people have the ability to upgrade whenever they like.
I mean come on you've done a great work here be proud of it and make it known!
People want this game, give it to them :)
-
Nightlies have no compile requirements on windows, do not need external libraries, or anything else. In fact they are simpler then the release version which has an installer. You do have to copy the original game files yourself or put it in the same folder used by the release version installer though.
I'm all for a 1.1 sooner rather than later with only currently known and easy bugfixes, which is already done.
I say it's damn time for an unofficial 1.1 - so I'm doing it.
-
I say it's damn time for an unofficial 1.1
you say that, but that doesn't make it so
-
I've been around ye olden internettes a long time, and here's the #1 problem open-source/freeware/fan-made projects run into: dev burnout.
So honestly, Warboy, SupSuper, all yall - fuck trying to please everyone. You do exactly what is easiest - and most fun - for you. If that means making nightlies less accessible, slowing down progress, backtracking, whatever - you do what you need to do. People will bitch and moan no matter what you do. That's just how humans work. So do what you think is best. If anyone disagrees too strongly with you, they can make their own fork or whatever else - otherwise they can dealwithit.jpg
Also, bear in mind, you guys could quit right NOW, and we already have a better Xcom than we've ever had before. You've done it - you've won. The project wasn't abandoned at v0.037 (or whatever) like so many other unpaid projects littering the tubes. We have a complete, playable, new-and-improved game, and we have y'all to thank for that.
If I were you, I would just seal off OXC at either 1.0 or whichever nightly you're most comfortable with, and rename all the new nightlies OpenTFTD - essentially making it its own project. That way you don't have to worry about TFTD support interfering with OXC gameplay, and anyone playing the latest builds would be doing so essentially as beta-testers for project#2, OTFTD. If that makes sense.
Either way, you do what you want/need to do, end-users can suck it up. :)
-
I've been around ye olden internettes a long time, and here's the #1 problem open-source/freeware/fan-made projects run into: dev burnout.
So honestly, Warboy, SupSuper, all yall - fuck trying to please everyone. You do exactly what is easiest - and most fun - for you. If that means making nightlies less accessible, slowing down progress, backtracking, whatever - you do what you need to do. People will bitch and moan no matter what you do. That's just how humans work. So do what you think is best. If anyone disagrees too strongly with you, they can make their own fork or whatever else - otherwise they can dealwithit.jpg
Also, bear in mind, you guys could quit right NOW, and we already have a better Xcom than we've ever had before. You've done it - you've won. The project wasn't abandoned at v0.037 (or whatever) like so many other unpaid projects littering the tubes. We have a complete, playable, new-and-improved game, and we have y'all to thank for that.
If I were you, I would just seal off OXC at either 1.0 or whichever nightly you're most comfortable with, and rename all the new nightlies OpenTFTD - essentially making it its own project. That way you don't have to worry about TFTD support interfering with OXC gameplay, and anyone playing the latest builds would be doing so essentially as beta-testers for project#2, OTFTD. If that makes sense.
Either way, you do what you want/need to do, end-users can suck it up. :)
this.
I think developing should be fun. If you have to come up with stuff every so often based on a schedule then it's a job. You wanna release things when you feel things are readt to be released. Opensource should be more flexible and organic.
I personally update my Openxcom as often as I can. If a new feature is introduced I try to use it right away. To be honest I have yet to find one game breaking bug in an Openxcom nightly.
screw 1.1 let's go straight for 2.0
-
you guys need to relax and enjoy the game!!
there is a saying
"I don't know the key to success, but the key to failure is trying to please everybody" -Bill Cosby
Although this project is built around a community devs need to say this is the way and be done, sure personally i would like more milestones or "stable" releases, but that is irrelevant.
I just wish OXC keeps moving forward
-
Nah, they need to continue taking requests. Our boys enjoy being with this awesome and small diehard UFO community.
-
Being away for a year, I'm surprised to learn that there has been a clash there !!
I'm not sure to well understand the reasons of this, but...
Please, please... Do not bother SupSuper !!!
You can challenge him, lots of community members are making lots of amazing evolutions, and I'm very grateful for that. But do never forget SupSuper (and Warboy) realized what nobody never did before and certainly will never perform in the future regarding UFO. Even if you sometimes disagree with his point of you, be eternally grateful to him (them) for the amazing job they realized.
I agree with CryptoCactus conclusion (except for suggestion, as I don't really have any opinion on that)
I've been around ye olden internettes a long time, and here's the #1 problem open-source/freeware/fan-made projects run into: dev burnout.
So honestly, Warboy, SupSuper, all yall - fuck trying to please everyone. You do exactly what is easiest - and most fun - for you. If that means making nightlies less accessible, slowing down progress, backtracking, whatever - you do what you need to do. People will bitch and moan no matter what you do. That's just how humans work. So do what you think is best. If anyone disagrees too strongly with you, they can make their own fork or whatever else - otherwise they can dealwithit.jpg
Also, bear in mind, you guys could quit right NOW, and we already have a better Xcom than we've ever had before. You've done it - you've won. The project wasn't abandoned at v0.037 (or whatever) like so many other unpaid projects littering the tubes. We have a complete, playable, new-and-improved game, and we have y'all to thank for that.
If I were you, I would just seal off OXC at either 1.0 or whichever nightly you're most comfortable with, and rename all the new nightlies OpenTFTD - essentially making it its own project. That way you don't have to worry about TFTD support interfering with OXC gameplay, and anyone playing the latest builds would be doing so essentially as beta-testers for project#2, OTFTD. If that makes sense.
Either way, you do what you want/need to do, end-users can suck it up. :)
Edit: yes, I am a SupSuper inconditional !
-
Right before releasing 2.0 OpenTFTD, change the website's background to TFTD's redish space geoscape :)
For trailer you guys amazed me with the last one, so I hope to see something better for this one!!
-
1.1 ha! 2.0 8)
-
We've given up on 1.1 because:
- Everyone is waiting on TFTD. Everyone. Nobody cares about little fixes and improvements, we've gotten much more requests about TFTD than issues in the bug tracker in the last year. Everyone wants the shinies.
- Modders keep attaching themselves to the latest nightly, which triggers more fixes and requests, which makes the "stable" constantly shift forward. Everyone wants the shinies.
So for us, trying to reach stability is pointless. You've forced our hand, it's full speed ahead until TFTD (2.0). There will probably be a pre-2.0 to iron everything out but that's it. If you wanna pick a "nightly" to stick to, feel free.
hello guys! Since i'm not very fussy abou shinies, may i suggest to slow down a bit on open tftd and focus more on next openxcom milestone? As for the latter, may be a feature freeze in septrmber, amd then a new relase in oct/nov? Then gomfor a first opentftd relase, maybe in jan/feb 2016.
most important, happy holidays!!! ;)
-
TftD is already out dude :P Kind of in beta-test mode. I am pretty sure there is no hope for a non-tftd milestone anymore.
We'll likely see OpenXCom 2.0 once they are happy with the state of TftD, which could be relatively soon as the game seems to be going pretty well.
-
TftD is already out dude :P Kind of in beta-test mode.
We'll likely see OpenXCom 2.0 once they are happy with the state of TftD.
You forgot the most important question: will it work with Linux? :P
-
lol I run linux too and I can say that the "TftD beta" does, so no worries there ;)
Most mods run in linux too, if their author is careful. But I think the dev in charge for the mod system said they even looked into the crippling case-sensitivity issue (WiNdOwS dOeSn'T cArE iF yOu TyPe LiKe ThIs) so that even if authors are not careful, OpenXCom would be able to cope with it. After that, I don't see why we would have any more trouble than others.