So .. I guess ignore that reply.Sometimes, you'll get errors from compiling .rc files with complaints about an illegal version format. In that case, open up src\tTrueVersion.h and edit the last line, it needs to read "MAJOR_VERSION a,b,c,d" where a to d are numbers (not starting with 0 unless they are 0) between 0 and 65535. Just get it to that form somehow.
What it is it going to take to make a .4 stable release?
Re: What it is it going to take to make a .4 stable release?
Wiki already had an answer to that ..
Re: What it is it going to take to make a .4 stable release?
So, would anyone be willing to test if it runs? Attached to this post.
- Attachments
-
- armagetronad.zip
- (4.23 MiB) Downloaded 250 times
Re: What it is it going to take to make a .4 stable release?
Wow, that is a difficult decision. I will say this: I rely on sound to give me a sense of my surroundings without glancing. I guess it seems more natural to choose camera+facing rather than cycle+heading?Lucifer wrote: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?
Upon further consideration, I think I'm wrong about making the zone sound monophonic. The current settings give you a good sense of position on the grid when it's only a couple zones appearing during a round, even when they fire simultaneously. I know at one time you fantasized about support for LADSPA plugins, though I'm not sure sending the sound through a compressor would have a good effect. This is another difficult problem. I know that in the beginning of a Sumo round, hearing 8 simultaneous instances of the same sound at the same position doesn't give me any more information than one instance of the sound. If I play a CTWF map with two dozen zones, the sounds furthest away will be hidden by the nearest ones. There must be some way to restrict redundant audio information. Maybe all that needs to be done is to drop sounds that are too close in proximity? Divide the grid into sectors and only allow one zone event from each to sound simultaneously? It's that reasonable? That way we could keep the valuable position information and intensity without overdriving the mixer.Lucifer wrote: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...
Re: What it is it going to take to make a .4 stable release?
Picture below is what happens when I try to open itLight wrote:So, would anyone be willing to test if it runs? Attached to this post.
bye
- Lucifer
- Project Developer
- Posts: 8683
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
Re: What it is it going to take to make a .4 stable release?
@Magi and Light: There are files missing from the zip archive. But the fact that it got that far is actually a Good Sign that the build works, if it had the missing files. The missing files are translation files, nothing major (in terms of the compiled binary running), so hopefully providing those files will fix it. So, Light, try to build the zip again, but including all the files needed for it to run?
I didn't resolve this when I originally wrote this code. I think I picked camera as the origin, but I remember arguing with myself about it.
Let's write off the support for LADSPA plugins. Yes, it would be cool and awesome, and all sorts of sinewav would love it. But it's not happening. Not yet, probably not ever.
The redundant sound problem can be tricky. See, the sound engine gets a location for the sound, but the location itself can be hard to nail down. What I mean is that it's all floating point stuff, and we can't do a simple == comparison to make sure we're not recycling redundant crap.
The sound engine is built to handle different sound effects differently, so there may be tests we can run. I need to revisit it, it's been so long, but I know damned well I built that feature into the design, so I need to see how well/if it has been implemented.
That's where the debate happens. In smartcam, your eye is following the camera, and your ears expect to hear something that matches up with what you see. But like you say, without glancing, what you here should represent what's going on on the grid, which may not match up with what the camera is showing. But if we make it match what's happening on the grid, and it doesn't match what the camera is showing (because it's smartcam), then we run the risk of having YOU make decisions badly based on bad information.sinewav wrote:Wow, that is a difficult decision. I will say this: I rely on sound to give me a sense of my surroundings without glancing. I guess it seems more natural to choose camera+facing rather than cycle+heading?Lucifer wrote: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?
I didn't resolve this when I originally wrote this code. I think I picked camera as the origin, but I remember arguing with myself about it.
[/quote]Upon further consideration, I think I'm wrong about making the zone sound monophonic. The current settings give you a good sense of position on the grid when it's only a couple zones appearing during a round, even when they fire simultaneously. I know at one time you fantasized about support for LADSPA plugins, though I'm not sure sending the sound through a compressor would have a good effect. This is another difficult problem. I know that in the beginning of a Sumo round, hearing 8 simultaneous instances of the same sound at the same position doesn't give me any more information than one instance of the sound. If I play a CTWF map with two dozen zones, the sounds furthest away will be hidden by the nearest ones. There must be some way to restrict redundant audio information. Maybe all that needs to be done is to drop sounds that are too close in proximity? Divide the grid into sectors and only allow one zone event from each to sound simultaneously? It's that reasonable? That way we could keep the valuable position information and intensity without overdriving the mixer.Lucifer wrote: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...
Let's write off the support for LADSPA plugins. Yes, it would be cool and awesome, and all sorts of sinewav would love it. But it's not happening. Not yet, probably not ever.
The redundant sound problem can be tricky. See, the sound engine gets a location for the sound, but the location itself can be hard to nail down. What I mean is that it's all floating point stuff, and we can't do a simple == comparison to make sure we're not recycling redundant crap.
The sound engine is built to handle different sound effects differently, so there may be tests we can run. I need to revisit it, it's been so long, but I know damned well I built that feature into the design, so I need to see how well/if it has been implemented.
Re: What it is it going to take to make a .4 stable release?
@Lucifer and sine: Yeah, I'd pick the camera as a reference point even for the sounds that aren't shown on the screen. The player is the target of the visual action on the screen and the audible one that comes out of the speakers. if you regard the camera as the proxy for the human eyes/the player's head, then the ears are basically at the same position regardless what is shown on-screen. That should be the most natural solution IMO. Then the sounds still provide information about stuff you don't see, like in other games.
edited a little, original post seemed a bit lazy.
edited a little, original post seemed a bit lazy.
Last edited by Word on Sat Jan 23, 2016 1:47 pm, edited 2 times in total.
Re: What it is it going to take to make a .4 stable release?
Two things .. The path seems to be from my wine, which seems like it could be an issue? But that might be from hopping around between Linux and wine CodeBlocks. So, you need the source to run the executable?
I'm gonna try also redoing this now that I have things set up right, and just running it through one compiler.
I'm gonna try also redoing this now that I have things set up right, and just running it through one compiler.
Re: What it is it going to take to make a .4 stable release?
I think I did it! Side note .. When I tried zipping the stuff, I got that language file not found, but if I compress with tar/gz or 7z it works fine? Not sure why that is. Also, my version of "working fine" is that wine attempts to open it without the regular errors. It can't seem to open the game though.
Last note .. I can't upload over 5MB here and it's a little over 7, so that's why it's uploaded externally. Would one of you mine trying this one out and seeing if we have a working copy? I made a script to do all the work up to here, including creating the archive, so uploading it would be a simple thing to add and we'd have automated builds again? I'd just have to come up with a way to make sure there's a new version before I run it, unless there's without a doubt a change every week, which I'm doubting.
Anyways ... can we see if it works?
// Going to provide a new download link in a few minutes. I don't think my symlinks are going to be useful to Windows users ... Just running a full rebuild of everything to make sure I don't break anything by trying to replace them.
Last note .. I can't upload over 5MB here and it's a little over 7, so that's why it's uploaded externally. Would one of you mine trying this one out and seeing if we have a working copy? I made a script to do all the work up to here, including creating the archive, so uploading it would be a simple thing to add and we'd have automated builds again? I'd just have to come up with a way to make sure there's a new version before I run it, unless there's without a doubt a change every week, which I'm doubting.
Anyways ... can we see if it works?
// Going to provide a new download link in a few minutes. I don't think my symlinks are going to be useful to Windows users ... Just running a full rebuild of everything to make sure I don't break anything by trying to replace them.
Re: What it is it going to take to make a .4 stable release?
Maybe that was more than a couple minutes. Ran to the store. So, maybe this time everything will work?
http://www.filedropper.com/armagetronadalpha20160123
http://www.filedropper.com/armagetronadalpha20160123
Re: What it is it going to take to make a .4 stable release?
You are right, I don't see any way to get around the smart-cam problem. Honestly, I feel like testing both methods myself is the only way to make a decision. You mentioned above it is possible to make this user configurable? That might be the best solution.Lucifer wrote:But if we make it match what's happening on the grid, and it doesn't match what the camera is showing (because it's smartcam), then we run the risk of having YOU make decisions badly based on bad information.sinewav wrote:I guess it seems more natural to choose camera+facing rather than cycle+heading?
Re: What it is it going to take to make a .4 stable release?
A couple people tried running the Windows build and it just crashed instantly when opened. Apparently they didn't get any errors though. I have no idea now. I thought I had it.
Re: What it is it going to take to make a .4 stable release?
So, I have come to a success with this. I have the script throwing together an archive for Windows and Linux. My next goal may be to cross compile to Mac, but I've never dealt with that and have no way to test it (like in wine), so that may have to hold off, but should be possible.
Here's my result: http://lightron.org/Download
I'd happily upload these to the weekly builds thing if Z-Man wants me to. They both include the client and server.
Here's my result: http://lightron.org/Download
I'd happily upload these to the weekly builds thing if Z-Man wants me to. They both include the client and server.
- Lucifer
- Project Developer
- Posts: 8683
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
Re: What it is it going to take to make a .4 stable release?
We'll just have to do that, because when you start dealing with custom cams, people might find they need the sound effects to use the cycle as the reference to better match the cam, and there's no logical way to test the differences without having it configurable.sinewav wrote:You are right, I don't see any way to get around the smart-cam problem. Honestly, I feel like testing both methods myself is the only way to make a decision. You mentioned above it is possible to make this user configurable? That might be the best solution.
Can you post the scripts you wrote to do all this? I'll use those as the starting point for a buildslave.Light wrote: So, I have come to a success with this. I have the script throwing together an archive for Windows and Linux. My next goal may be to cross compile to Mac, but I've never dealt with that and have no way to test it (like in wine), so that may have to hold off, but should be possible.
Of course, right this minute I'm trying to fix my broke-ass car, so it'll be a bit, but hey, I'm finding time to post here, logic dictates that means I'm finding time again.
Re: What it is it going to take to make a .4 stable release?
I really hate to say it, but at this point, it's not going to do much for you. I had to move a bit of stuff around to make any of this work. I do plan on cleaning it up a little though so I can throw it on my server and set a cronjob to do the dirty work. So, maybe next weekend I can post something more helpful.Lucifer wrote:Can you post the scripts you wrote to do all this? I'll use those as the starting point for a buildslave.
Of course, right this minute I'm trying to fix my broke-ass car, so it'll be a bit, but hey, I'm finding time to post here, logic dictates that means I'm finding time again.
I basically just wrote a script to run through the wiki instructions though. The issues I hit were from messing in both wine and Linux builds, but I have a decent start for the next part. My end script is going to do a little more than just build once a week though. I'm going to try keeping up with revisions. My current script already makes sure there's a new revision before doing anything, so I really just need to get this all going as a job.
On the other hand, I may be on the road to doing what you wanted anyways? I could always add uploading to sourceforge into my script, but I have the client and server packaged together and not nearly as many options as were on Z-Man's. I had a couple problems I didn't work out yet with all of that, but right now it's doing the important parts and can make working builds.
- Lucifer
- Project Developer
- Posts: 8683
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
Re: What it is it going to take to make a .4 stable release?
Well, making a buildslave is really just translating to Buildbot's api, all in Python. Also, the build master handles checking for changes and telling the buildslaves when to build, and even goes so far as to send the changes to the slaves. If you want to go that route, I'll re-prioritize the buildbot.Light wrote:I really hate to say it, but at this point, it's not going to do much for you. I had to move a bit of stuff around to make any of this work. I do plan on cleaning it up a little though so I can throw it on my server and set a cronjob to do the dirty work. So, maybe next weekend I can post something more helpful.Lucifer wrote:Can you post the scripts you wrote to do all this? I'll use those as the starting point for a buildslave.
Of course, right this minute I'm trying to fix my broke-ass car, so it'll be a bit, but hey, I'm finding time to post here, logic dictates that means I'm finding time again.
I basically just wrote a script to run through the wiki instructions though. The issues I hit were from messing in both wine and Linux builds, but I have a decent start for the next part. My end script is going to do a little more than just build once a week though. I'm going to try keeping up with revisions. My current script already makes sure there's a new revision before doing anything, so I really just need to get this all going as a job.
On the other hand, I may be on the road to doing what you wanted anyways? I could always add uploading to sourceforge into my script, but I have the client and server packaged together and not nearly as many options as were on Z-Man's. I had a couple problems I didn't work out yet with all of that, but right now it's doing the important parts and can make working builds.
Ultimately, build uploads from the buildbot will be on it's own webpage, and whenever we get it up running and stable, it'll basically be the new place for test builds.