What it is it going to take to make a .4 stable release?

[Z-Man]

* SDL2 support.

Isn't it merged already?

It is now But the build system I use for the "weekly" builds still is in the process of getting a replacement, that's why there are no current Windows or Linux builds.

[Lucifer]

Updating the list:

* Automated builds: Working on that right now.

Any success here? I tried setting up a Jenkins for windows builds. But my old windows laptop just went dead so no help there sorry.

In a word: no. Still trying to get the special needs kid to be independent enough that I'll actually have time for leisure activity that doesn't amount to watching TV and checking to make sure my kid's not currently trying to kill herself.

Just count me out for awhile, but I will be back at some point. If someone else would like to work on the buildbot, I'm happy to send the current config files I have and you can work from there.

[/dev/null]

I can offer compiling power if needed, but im far too lazy/untrustworthy to actually set up the builds. I figure Ill just drop you a shell to use as needed.

[Lucifer]

Updating the list, hopefully.

* Updated zones documentation. This should hopefully also include some copy&paste zones for effects people are used to seeing, or would like to reuse. As far as I know, there's still very little here.

* Cockpit issues. It's in many ways a non-trivial task to edit a cockpit, but it is also beyond the scope to make it easy to use configuration items to modify a chosen cockpit.

* Being able to choose cockpits. Z-man claimed this one.

* Sound complaints. I added some sounds. It seems reasonable, considering how sounds work now, to make configuration items to disable them. I'll see about that. (I'm assuming people don't like the countdown, but it doesn't matter, the way I set it up I should be able to make toggles for *all* sounds) Sound mixing seems to be the big thing here. One fix that was always intended to be a feature is actually marking certain sound effects as limited on how many can be played at a time. I think the zone spawn fix that would work best would be to limit it to two instances playing at a time, with the second being phase-shifted so avoid the two adding together too much.

* Make sure we have cockpits for all previous versions. And create a new cockpit for the new version. Current version is a show-off cockpit, not an actually reasoned-though cockpit. It shows what can be done. So we need to make sure classic gauges are respected and available, and have something new that truly represents 0.4. Sinewav is working on this right now, apparently.

* Automated builds: Work is currently stalled on the buildbot, but I seem to remember Z-man saying he's got something running still?

* Making cockpits easier to edit. I'm not sure what we can do on that one, but I'm open to discussion. The main complaint is being able to use settings to move cockpit widgets around, which is nearly impossible, but not completely. Let's talk some more. Talk was made about a cockpit editor tool, but until such a thing materializes, we must assume it will never exist.

* A way for users to report to the server admin abusive players. We've sorta ignored this. Maybe there's more we can do besides this? I definitely think looking at the ct+sty branch is a solid start.

* Speaking of the ct+sty branch, is there anything else in there that you'd like to see in 0.4? (Besides the CTF and styball, I don't believe we can extend the zones to include those for 0.4, but consider that a high priority as soon as 0.5 gets started)

* Merging Epsy's cockpit branch

* SDL2 support. Apparently this is a thing. Add to it: https://wiki.libsdl.org/SDL_GetPowerInfo as a data source for cockpits. Also, having re-read this thread, is there an OpenBSD port of SDL2 or are we going to have to try to support SDL1.3 for platforms that don't have SDL2 yet?

* Distributed resource repositories that mirror each other. In a perfect world, we'll release 0.4 with 4 repositories up and running and able to service clients and servers. I guess I'll run the "official" project repo, which should provide the baseline repository required to be in the rotation of distributed repositories. We also need all the current repository code people are using, and willing to contribute, to be put in a bzr branch and hammered out into something resembling a distribution. That way, the "official" repositories can all run on the same basic code, with expected individual improvements by the server admins running them.

Anything else that needs to be changed on the list?

[Light]

It is now But the build system I use for the "weekly" builds still is in the process of getting a replacement, that's why there are no current Windows or Linux builds.

What goes into that? I assume you just release the source for Linux, so what would need done to compile for Windows? Do you compile through Code Blocks on Linux, or do you have to use a Windows machine to properly build and distribute?

I would happily set something up if you wanna throw me in the right direction. The LP copy of 0.4 compiles and runs perfectly fine for me on xubuntu 15.10.

[Lucifer]

It is now But the build system I use for the "weekly" builds still is in the process of getting a replacement, that's why there are no current Windows or Linux builds.

What goes into that? I assume you just release the source for Linux, so what would need done to compile for Windows? Do you compile through Code Blocks on Linux, or do you have to use a Windows machine to properly build and distribute?

I would happily set something up if you wanna throw me in the right direction. The LP copy of 0.4 compiles and runs perfectly fine for me on xubuntu 15.10.

Codeblocks is the official build system for Windows, I believe. Z-man was last doing windows builds using wine and code blocks from Linux. So that should work. I was working on a buildslave that would cross-compile that way.

Also, if you're really interested in doing it, I'd love to see the autotools able to cross-compile arma from anywhere to anywhere. I did a proof-of-concept years ago where I built the dedicated server on linux, compiled for Windows. It was fun, but 'twould take quite a bit of time and work. But the advantages of using the same build system in an automated environment are obvious.

As for the source release, it's for all platforms. You can use the source release to build for any platform supported. It wouldn't be a full source release if you couldn't.

[sinewav]

* Sound complaints. I added some sounds. It seems reasonable, considering how sounds work now, to make configuration items to disable them. I'll see about that. (I'm assuming people don't like the countdown, but it doesn't matter, the way I set it up I should be able to make toggles for *all* sounds)

I replaced my local countdown sounds and like them very much. As is stands today, there are only two things that bother me about the sound in 0.4 — 1) the mixing and 2) the zone spawn sound. I'm sure you know this already, but I'll continue on for completeness.

Regarding mixing, I know the cycle engine level is based on camera proximity, am I correct? I feel like the current level is too quiet but too loud in incam. I feel like the sound balance should be the same regardless of camera location.

Regarding zone spawn sounds, this definitely needs fixing. Currently, a new instance of the sound will trigger for every zone. If multiple zones spawn at the same time, they all mix together and overdrive the sound output. In CTWF there is at least one map that sends a loud-ass stream of distortion through my speakers. The zone spawn sound should be monphonic, it should not sound while another instance is playing, or if it does, need to be progressively quieter (steeply).

[Light]

Codeblocks is the official build system for Windows, I believe. Z-man was last doing windows builds using wine and code blocks from Linux. So that should work. I was working on a buildslave that would cross-compile that way.

Also, if you're really interested in doing it, I'd love to see the autotools able to cross-compile arma from anywhere to anywhere. I did a proof-of-concept years ago where I built the dedicated server on linux, compiled for Windows. It was fun, but 'twould take quite a bit of time and work. But the advantages of using the same build system in an automated environment are obvious.

As for the source release, it's for all platforms. You can use the source release to build for any platform supported. It wouldn't be a full source release if you couldn't.

I set up the Linux version of Code Blocks to compile with a Windows compiler. At the moment hit the issue of Boost not being found, but working on that now. So, we'll see where it goes from here ..

As far as that goes, CB has command line options for building, so if I can get it to work, I can just keep Boost there to copy into the source and hit build I'm assuming? But I'll find out when I look at it a little more.

[Light]

Is there no longer Code Blocks setups released for the SDL mixer and whatnot? I remember like 5 extra things being there, and it doesn't wanna compile for me without it.

[Lucifer]

I replaced my local countdown sounds and like them very much. As is stands today, there are only two things that bother me about the sound in 0.4 — 1) the mixing and 2) the zone spawn sound. I'm sure you know this already, but I'll continue on for completeness.

Regarding mixing, I know the cycle engine level is based on camera proximity, am I correct? I feel like the current level is too quiet but too loud in incam. I feel like the sound balance should be the same regardless of camera location.

It's supposed to be based on position, and it's worse than you can imagine. It's SDL_Mixer's mostly incorrect way of trying to make 3d sounds. Seriously, if I can find the motivation, I'll totally rewrite the backend to use OpenAL and this complaint should just disappear. Otherwise, we might be stuck with it, but I'll look into it.

Edit: I didn't look into it yet, but I honestly don't know what Z-man did to add the cycle engine sound. At least, I think it was he that did it. But there's a debate about whether or not the sounds should be relative to the camera position and facing or whether they should be relative to the cycle's position and heading. Where do you stand on this one? Or should we consider a config item for it?

Regarding zone spawn sounds, this definitely needs fixing. Currently, a new instance of the sound will trigger for every zone. If multiple zones spawn at the same time, they all mix together and overdrive the sound output. In CTWF there is at least one map that sends a loud-ass stream of distortion through my speakers. The zone spawn sound should be monphonic, it should not sound while another instance is playing, or if it does, need to be progressively quieter (steeply).

I added this information to the line item in the list, but thought we might talk some more.

I'm thinking the zone sounds should be increased when many zones are spawning, but that the, er, emotional impact we want the player to get would be satisfied by limiting the sound to two instances, where we phase shift the second (you know, the way you fake-double a guitar line). Figuring out which instance to choose, on the other hand, would be tricky. Since it's supposed to be position-based, I think using the closest and farthest sounds would be best, but if there were some way to figure out that more than one zone is spawning, perhaps it would be best to just throw two instances into the mix, panned extreme left/front and right/back, with the second one phase shifted. What do you think? You're the sound engineer around here.

@Light: I haven't even tried to build with codeblocks in a year or so. There are instructions on the wiki, in case you haven't checked that yet. I was following those the last time I tried.

[Light]

@Light: I haven't even tried to build with codeblocks in a year or so. There are instructions on the wiki, in case you haven't checked that yet. I was following those the last time I tried.

That got me to look in the right place. I set things up to work with the linux script, but now there's an include for tTrueVersion.h which doesn't seem to exist. I don't know how to get past that. It built through quite a bit of it, and felt hopeful, but I think I'm stuck at this point as even Google wasn't helpful. If we could find a way to get past this and get a successful build, it would be decently easy for me to get a script going to do it automatically for new releases or weekly.

[Lucifer]

If you're working from a bzr branch, there's a script you have to run to generate that. I don't remember which script it is, though. If it's a tarball source release, that file's supposed to be there.

You might try running ./bootstrap.sh, since you're in linux. It might generate that file. (It does for the linux build, at least)

[Light]

Bootstrap didn't create that file for me, so not sure what point we get that file as it's never popped up as an issue for me. On the other hand, I ran the batch files through wineconsole and have gotten it. Attempting to build it again.

[Lucifer]

Configure probably makes it, then. And yes, the batch files were the way to go. Obviously, heh.

[Light]

Configure probably makes it, then. And yes, the batch files were the way to go. Obviously, heh.

I didn't realize wineconsole ran them fine. I don't really mess with wine much since I don't use Win programs. I actually had to specially install wine for this. lol

Now ...

Code: Select all

windres.exe  -J rc -O coff -i Z:\home\tom\DOWN~NTG\0.4\src\win32\ARMA~ZVR.RC -o ..\..\build\tmp\Armagetron_Dedicated___Win32_Release\src\win32\armagetron.res
windres.exe: Z:\\home\\tom\\DOWN~NTG\\0.4\\src\\win32\\ARMA~ZVR.RC:71: syntax error

Code Blocks drops me on this line ..

Code: Select all

 PRODUCTVERSION MAJOR_VERSION