This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »
721
General ENIGMA / Re: Proposal for guidelines on changes to the master branch of enigma-dev/enigma-dev
« on: June 05, 2013, 08:21:27 pm »
I didn't say that the issue ruined anyone's day (Even though I strongly implied it ruined mine). I said it was an issue. An issue that could have been easily avoided by using a branch. Four steps here:
From there, all anyone has to do is check out your branch, implement a fix, and merge the branch back into master. Now no one ever has to incur a problem.
- Create a branch. [snip]git checkout -b ima_break_some_shit_to_move_mouse_x_and_y[/snip]
- Implement fix. This is the hard part, that you were going to do anyway.
- Commit and push your fix. [snip]git commit -m "i fixd the shit on winblowx and brok it on evry1 els"[/snip] [snip]git push origin ima_break_some_shit_to_move_mouse_x_and_y[/snip]
- Tell people on Linux and Mac to check out your branch and fix the shit on Linux and Mac, respectively.
From there, all anyone has to do is check out your branch, implement a fix, and merge the branch back into master. Now no one ever has to incur a problem.
722
General ENIGMA / Re: Proposal for guidelines on changes to the master branch of enigma-dev/enigma-dev
« on: June 05, 2013, 06:06:06 pm »
polyfuck: How important a particular feature is does not pertain to the issue at hand. The issue is that the tracker is overflowing with little shit, the IRC is full of people who can't get the installer working, and amid all of that chaos, someone mentions, "Oh hey, mouse_x and _y aren't working."
Anyway, thanks much for the post, forthevin.
What I'm personally thinking is that we should do what we did on the SVN, only a little cleaner. I propose that everything in master be deemed "stable"; that is, no changes are made to it which have not been tested. Changes for testing are merged into the "testing" branch, from the "development" branch, when it's deemed that it might be a good time to push to stable.
Bug reports should be fixed in the most stable branch exhibiting the bug. That is, a bug should be fixed in master if it exists in master, otherwise it should be fixed in testing, or otherwise in development. If a bug is fixed in master, the fix is then merged into testing and development. If a bug is fixed in testing, it is merged into development. Bugs fixed in development, as stated, should have only been fixed there because they are absent from master and testing.
What I've just described is so simple, it's probably standard. The only reason we *aren't* doing that is because we failed miserably at it with the SVN, because no one ever remembered, "Hey, this would be a good revision to mark for (testing|stable)!"
If I thought we were responsible enough not to have a three-month-dead master branch on that system, I'd be interested in pursuing it.
Anyway, thanks much for the post, forthevin.
What I'm personally thinking is that we should do what we did on the SVN, only a little cleaner. I propose that everything in master be deemed "stable"; that is, no changes are made to it which have not been tested. Changes for testing are merged into the "testing" branch, from the "development" branch, when it's deemed that it might be a good time to push to stable.
Bug reports should be fixed in the most stable branch exhibiting the bug. That is, a bug should be fixed in master if it exists in master, otherwise it should be fixed in testing, or otherwise in development. If a bug is fixed in master, the fix is then merged into testing and development. If a bug is fixed in testing, it is merged into development. Bugs fixed in development, as stated, should have only been fixed there because they are absent from master and testing.
What I've just described is so simple, it's probably standard. The only reason we *aren't* doing that is because we failed miserably at it with the SVN, because no one ever remembered, "Hey, this would be a good revision to mark for (testing|stable)!"
If I thought we were responsible enough not to have a three-month-dead master branch on that system, I'd be interested in pursuing it.
723
Announcements / Re: LateralGM Update
« on: June 04, 2013, 08:50:57 am »
11th plague:
The Author field under "API" is the name of the person that wrote the specific system you're trying to use, in case you need to contact them (especially if it's third-party). It's not added to the game or anything.
The Author field under "API" is the name of the person that wrote the specific system you're trying to use, in case you need to contact them (especially if it's third-party). It's not added to the game or anything.
724
Issues Help Desk / Re: Some problems I have found.
« on: June 03, 2013, 01:55:06 pm »
Do some of your objects have sprites set which do not exist? Or maybe they're drawing a sprite that doesn't exist? I'll have to fix that error message to give the appropriate IDs so we'll know for sure.
725
Off-Topic / Re: Dear Polyfuck: Stop breaking the fucking repo
« on: June 03, 2013, 10:34:24 am »
Using your fork and using a branch are two different things. If you don't use a branch, no one will accept any pull requests until any breaking changes you are working on which should have been in a branch are completed. This includes changes which just aren't given the benefit of the doubt, even if you think they work.
The switch to Bridges/ was trivial enough for me not to give you a hassle. Don't think for a second that every change you may make at my suggestion will be so nonchalantly merged.
The switch to Bridges/ was trivial enough for me not to give you a hassle. Don't think for a second that every change you may make at my suggestion will be so nonchalantly merged.
726
Issues Help Desk / Re: Some problems I have found.
« on: June 03, 2013, 10:10:37 am »
The point of debug mode is to provide useful error messages for diagnosing and fixing an issue. As polydip pointed out, leaving a tile problem for the background subsystem to sort produces non-useful error messages that only I know how to read. What if someone deletes a background without deleting tiles/layers that use it? There should be better error handling in the engine during debug mode.
The macro is DEBUG_MODE. When that's set, check *everything* and report errors. If needed, open a discussion here about debug mode levels, so highly expensive, ultra-frequent checks can be enabled apart from usual debug checking.
The macro is DEBUG_MODE. When that's set, check *everything* and report errors. If needed, open a discussion here about debug mode levels, so highly expensive, ultra-frequent checks can be enabled apart from usual debug checking.
727
Issues Help Desk / Re: Some problems I have found.
« on: June 02, 2013, 10:16:54 pm »
SuperRiderTH:
Make sure that in the room in question, all backgrounds are either not marked visible, or are assigned a valid background ID (one that exists). Then make sure that all tiles have valid IDs (switch to the tile list, and remove any whose backgrounds are missing).
Make sure that in the room in question, all backgrounds are either not marked visible, or are assigned a valid background ID (one that exists). Then make sure that all tiles have valid IDs (switch to the tile list, and remove any whose backgrounds are missing).
728
Off-Topic / Re: Dear Polyfuck: Stop breaking the fucking repo
« on: June 02, 2013, 04:18:20 pm »
Git has branches for a reason. They are trivial to use and create. Most projects have branches that live less than a week on average. When you want to make a change that breaks fucking everything (such as moving updaters someplace platform-specific, or moving wgl code to a new Bridges/ folder), you do so in a branch. Anyone that needs to work on that branch does so, and then it is merged into master.
Robert fucking refuses to use branches. You just didn't bother. Next time, do so.
Robert fucking refuses to use branches. You just didn't bother. Next time, do so.
729
Off-Topic / Dear Polyfuck: Stop breaking the fucking repo
« on: June 02, 2013, 03:19:30 pm »
Dear Polyfuck: Stop breaking the fucking repo
If you continue to break the fucking repo on all non-Windows platforms--which I'll remind you that the majority of our users are on, because the rest can tolerate GM by virtue of being able to tolerate Winblows--I'm going to have you join Robert in club commit-to-fork-and-drop-pull-requests, where you should have been from the get-go.
We have *far* too many problems with the engine from the new MinGW release and the new release zip to be worrying about you fucking breaking mouse_x on a whim without so much as telling anyone.
At very least, tell Robert, because he won't fucking shut up about it until it's fixed, whether he fixes it, or he asks me how to fix it, or I fix it.
If you continue to break the fucking repo on all non-Windows platforms--which I'll remind you that the majority of our users are on, because the rest can tolerate GM by virtue of being able to tolerate Winblows--I'm going to have you join Robert in club commit-to-fork-and-drop-pull-requests, where you should have been from the get-go.
We have *far* too many problems with the engine from the new MinGW release and the new release zip to be worrying about you fucking breaking mouse_x on a whim without so much as telling anyone.
At very least, tell Robert, because he won't fucking shut up about it until it's fixed, whether he fixes it, or he asks me how to fix it, or I fix it.
730
Issues Help Desk / Re: Some problems I have found.
« on: June 02, 2013, 01:06:31 pm »
It's your fault, polyfuck. You're drawing a background in screen_redraw without making sure it exists--ie, is not -1.
That debug code tells me all I fucking need to know to figure that out. -5 is global.
That debug code tells me all I fucking need to know to figure that out. -5 is global.
731
Issues Help Desk / Re: Some problems I have found.
« on: June 01, 2013, 08:38:33 pm »
Hiya;
See if the behavior changes in debug mode. Debug mode is designed to catch problems that ENIGMA does not waste checks on during regular engine runs.
The problem you are having is very generic. If debug mode does not catch it, that's terrible. I'll need you to file a bug report on the matter, complete with the game file or steps to reproduce.
If debug mode does catch it, you will receive an error message either in your console or in a popup window.
See if the behavior changes in debug mode. Debug mode is designed to catch problems that ENIGMA does not waste checks on during regular engine runs.
The problem you are having is very generic. If debug mode does not catch it, that's terrible. I'll need you to file a bug report on the matter, complete with the game file or steps to reproduce.
If debug mode does catch it, you will receive an error message either in your console or in a popup window.
732
Issues Help Desk / Re: ENIGMA isn't ready yet
« on: June 01, 2013, 01:23:04 am »Quote
The first time this came up, I'd had the program open for two hours.Did that fix it? If not, some error may have occurred. It should be in your console, and is probably that one from before, in which case it should be solved in the next day or two; I need a box with the latest GCC to make sure that when the ISO is not explicitly set to C++11, it still defines the __cplusplus macro appropriately.
Quote
And now, I can't even make it remember its window positioning (I exit fullscreen, it comes back windowed, every time).It's likely no one ever coded that. You might want to file a feature request with LateralGM.
Quote
As well, when I try to save a project, it tells me something can't be moved to a backup so I have to overwrite,Okay, this shouldn't be happening. What file format are you saving as? And where are you trying to save the file? Is the backup file marked read-only? Otherwise, this is an LGM bug, and we'll need to file it on LateralGM's tracker, too.
Quote
and when I exit, it still asks me if I want to save my progress, even if I just saved.That was Robert's doing. Something is wrong with the way LateralGM handles change tracking, so the program can't check for usaved chages when you try to close it. Before, it just closed without warning. Robert modified it to prompt every time instead. The bug is known, and in fact has been known for some time; we have no ETA on a fix. There's a big push for GMX support in LGM, though, which will mean a substantial amount of refactoring. It's possible these changes will include a fix for this issue, too.
733
Issues Help Desk / Re: error EGMF
« on: May 30, 2013, 04:25:11 pm »
Relatively soon. I'm deciding what to do. The assholes used [snip]long long unsigned int[/snip] as their size_type, which is NOT valid in the previous ISO. I get warnings for an attempt to use long long in my own code. Still, I suppose our only option is to overload it now that the alternative is an error. The intelligent thing to do would be to overload it for size_type, but that would conflict with the other overloads on systems wherein it was just long. Their stupid change puts me in an awkward position.
EDIT: Good news; this was an ISO decision, not a MinGW decision. The type [snip]long long int[/snip] is now guaranteed to exist, and be no less than 64 bits and at least as large as a regular [snip]long int[/snip].
I've asked polygone to replace the [snip]USE_LONG_LONG[/snip] macro in the compiler with [snip]__cplusplus >= 201100[/snip], which should let us filter out compilers that support the new standard a little better.
How did you end up with a compiler that uses the new standard by default?
EDIT: Good news; this was an ISO decision, not a MinGW decision. The type [snip]long long int[/snip] is now guaranteed to exist, and be no less than 64 bits and at least as large as a regular [snip]long int[/snip].
I've asked polygone to replace the [snip]USE_LONG_LONG[/snip] macro in the compiler with [snip]__cplusplus >= 201100[/snip], which should let us filter out compilers that support the new standard a little better.
How did you end up with a compiler that uses the new standard by default?
734
Issues Help Desk / Re: Out of memory error while compiling
« on: May 30, 2013, 02:37:58 pm »
This smells like a bug in GCC. Nothing ENIGMA puts in that code should make it bloat to 2GiB. The only other file that might bloat up immensely is IDE_EDIT_objectaccess.h... Even then, though, 20,000 lines is hardly a reason to require 2GiB of RAM.
Would you be willing to share either of the game file or that folder (Preprocessor_Environment_Editable)? It contains a loose C++ translation of your game code, but it's not enough to reverse-engineer back to the original game.
Would you be willing to share either of the game file or that folder (Preprocessor_Environment_Editable)? It contains a loose C++ translation of your game code, but it's not enough to reverse-engineer back to the original game.
735
Issues Help Desk / Re: error EGMF
« on: May 30, 2013, 11:19:43 am »
It's possible you're trying to run a 32-bit ENIGMA from a 64-bit JVM. Do you have a 32-bit Java installed?
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »