Release process for 0.2.7.1
the release canidate 4 exe isnt working
this pops up when i try to install.
Code: Select all
This application has failed to start because SDL_image.dll was not found. Re-installing the application may fix this problem.
That's because it is not an istaller, but only the game exe itself. I can't yet build full installers again. You have to install a previous version and copy the exe over the installed one.Your_mom wrote:the release canidate 4 exe isnt working
this pops up when i try to install.Code: Select all
This application has failed to start because SDL_image.dll was not found. Re-installing the application may fix this problem.
Jonathan found another bug
Its a CPU time DOS bug. The server will get unresponsive for a long time ( depending on luck and server power, some seconds to maybe days ). This bug can be circumvented by setting BUG_TUNNEL to 1, but of course this will unleash all sorts of tunneling and teleporting bugs again. I'll work on a solution and post updated sources yet again.
Edit: and I think that like the stab bug, it won't happen with sensible cycle_delay and cycle_rubber_mindist settings. But that's of course no excuse for it being there.
Its a CPU time DOS bug. The server will get unresponsive for a long time ( depending on luck and server power, some seconds to maybe days ). This bug can be circumvented by setting BUG_TUNNEL to 1, but of course this will unleash all sorts of tunneling and teleporting bugs again. I'll work on a solution and post updated sources yet again.
Edit: and I think that like the stab bug, it won't happen with sensible cycle_delay and cycle_rubber_mindist settings. But that's of course no excuse for it being there.
That would answer my question on how you handle the unix-style text problems, tooklax wrote:About the windows build: now that I remember maybe it worked for me because I used the old project vs6 files and added the missing files (sorry tank )
I'll try to build a windows-sources zip file where all text files are converted properly.
The worst part of the performance DOS is fixed. Here's RC5. It makes RC4 obsolete, so the question is now whether we'll use RC3 or RC5 for the release.
You do not have the required permissions to view the files attached to this post.
- klax
- Project Developer
- Posts: 481
- Joined: Tue Jun 08, 2004 3:51 pm
- Location: Barcelona, Spain
- Contact:
Armagetron Advanced RC5 Windows Installer Files.
Edit:
In deustch now it shows the correct title.
Documentation is now 'updated'.
Edit:
In deustch now it shows the correct title.
Documentation is now 'updated'.
You do not have the required permissions to view the files attached to this post.
Last edited by klax on Sat Mar 05, 2005 5:07 pm, edited 1 time in total.
To clarify the DOS bug:
In version 0.2.7.1, there is a new facility tracking changes to the grid layout; whenever the grid gets reorganized because a wall is drawn, this facility stores which of the old faces are replaced by which new faces. Sometimes, a clean replacement is impossible: when an edge gets turned, two faces get replaced by two new faces, so each of the old faces needs to reference both new faces. When that happens several times in a row, you end up with a tree of face replacements that grows exponentially with the number of replacements made ( it does not grow that big in memory, but it grows that big logically for the code that later analyses the replacements ). The bugfix is to just eliminate handling the same face twice in each run.
It is not really a catastrophic bug since with the BUG_TUNNEL setting, you can turn the problematic facility completely off and revert to 0.2.7.0 behavior.
Edit: Here are the RPMs. This time, I did some basic tests ( installs & runs ) in SuSE in vmware.
In version 0.2.7.1, there is a new facility tracking changes to the grid layout; whenever the grid gets reorganized because a wall is drawn, this facility stores which of the old faces are replaced by which new faces. Sometimes, a clean replacement is impossible: when an edge gets turned, two faces get replaced by two new faces, so each of the old faces needs to reference both new faces. When that happens several times in a row, you end up with a tree of face replacements that grows exponentially with the number of replacements made ( it does not grow that big in memory, but it grows that big logically for the code that later analyses the replacements ). The bugfix is to just eliminate handling the same face twice in each run.
It is not really a catastrophic bug since with the BUG_TUNNEL setting, you can turn the problematic facility completely off and revert to 0.2.7.0 behavior.
Edit: Here are the RPMs. This time, I did some basic tests ( installs & runs ) in SuSE in vmware.
You do not have the required permissions to view the files attached to this post.
Last edited by Z-Man on Sat Mar 05, 2005 3:44 pm, edited 1 time in total.
I'm afraid I don't have the slightest clue how you do remote or postmortem crash analysis in Windows. Is the second message box what appears when you click on the "To see what data this error report contains, click here"? If not, this information may be useful.llaffer2 wrote:Any ideas?
The one thing I read from the message is, since the instruction address and the memory address are the same, AA tried to execute code in nirvana. This could be a corrupted function pointer or a call to a virtual function of an already deleted object.
What version did this error first occur in?
Edit: the executable and data client RPMs are attached.
You do not have the required permissions to view the files attached to this post.
I first saw it with the 2.7.1 release that was put out a few months ago, but the problem didn't start happening until about 2 weeks ago. I don't know what, if anything, has changed in my system in that time.
I clicked on the "To see what data this error report contains", and it has good data that may be usefull, but it isn't selectable for me to copy and paste. It also mentions a file that would be sent, but I'm not sure that's very usefull - I'll attach it just in case.
I'll see if I can find some way of posting that information.
I clicked on the "To see what data this error report contains", and it has good data that may be usefull, but it isn't selectable for me to copy and paste. It also mentions a file that would be sent, but I'm not sure that's very usefull - I'll attach it just in case.
I'll see if I can find some way of posting that information.
You do not have the required permissions to view the files attached to this post.
- klax
- Project Developer
- Posts: 481
- Joined: Tue Jun 08, 2004 3:51 pm
- Location: Barcelona, Spain
- Contact:
llafer2: didn't know that bug was there. Any other windows player here??
I've reuploaded RC5 Windows Builds with "updated" documentation (also did not have compile.htm and readme_windows.htm). Also corrected duplicated COPYING.txt :s
z-man: I've added in cvs commands.txt to /src/doc (it was missing, how did u generated the docs?). Also this commands.txt adds a few lines thrashed when u moved the doc dir (two new commands in 0.2.7.0).
I've reuploaded RC5 Windows Builds with "updated" documentation (also did not have compile.htm and readme_windows.htm). Also corrected duplicated COPYING.txt :s
z-man: I've added in cvs commands.txt to /src/doc (it was missing, how did u generated the docs?). Also this commands.txt adds a few lines thrashed when u moved the doc dir (two new commands in 0.2.7.0).