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 »
526
Proposals / Re: Thoughts on forum registration...
« on: November 04, 2010, 12:10:50 pm »
A non-changing question like yellow fruit would be easy to program a bot to bypass. You need to switch it up.
527
Function Peer Review / Re: action_move
« on: November 04, 2010, 12:08:08 pm »
The [9] was to emphasize that only 9 characters will be considered. I'm not sure if that'd cause any problems for the null at the end or not, but I don't even look at the null; it doesn't matter to me.
As for macro, good luck writing that. I also haven't been able to get #define to work quite right in definitions for defining dnd actions. It's like it gets ignored.
As for hspeed and vspeed, I wasn't sure how that worked.
As for whether the rest of the code is right, I've already been using it for a while in a new catch-the-clown d&d version, and it works great.
As for macro, good luck writing that. I also haven't been able to get #define to work quite right in definitions for defining dnd actions. It's like it gets ignored.
As for hspeed and vspeed, I wasn't sure how that worked.
As for whether the rest of the code is right, I've already been using it for a while in a new catch-the-clown d&d version, and it works great.
528
Function Peer Review / Re: action_move
« on: November 03, 2010, 04:25:54 pm »
Because the DND action direction argument is passed as a string of 9 bytes. Changing it would require a change in the underlying mechanism, and then a backwards compatibility mechanism to get it to still work with GM.
529
Function Peer Review / action_move
« on: November 03, 2010, 10:44:10 am »
I'm trying to write up the action_move function, since it doesn't really have a direct GML equivalent, due to the direction argument being multiple-choice which then gets randomly selected.
I'm also working on an educated assumption here, trying to recall from when I still had access to GM, how it behaved.
Assumption 1: It will randomly select one of the depressed directional buttons, but will not select a between value (so the resulting direction will always be a multiple of 45).
Assumption 2: The directional string directly corresponds with the directions in the dirs array. (I've done a bit of testing, so I think it is correct)
Note 1: The first argument should always be an array of characters of size 9. Longer strings are fine, but only the first 9 characters will be examined. Shorter strings may cause this to look at memory beyond the string.
Note 2: This code makes use of the random(x) function.
Note 3: A few minor optimizations can be made around random.
3a: To avoid the use of random when there's only 1 choice. Replace:
choices = int(random(choices)); //choices is now chosen
With
3c: Replace random with integrated choose() function once it's implemented, if it's more efficient.
I'm also working on an educated assumption here, trying to recall from when I still had access to GM, how it behaved.
Assumption 1: It will randomly select one of the depressed directional buttons, but will not select a between value (so the resulting direction will always be a multiple of 45).
Assumption 2: The directional string directly corresponds with the directions in the dirs array. (I've done a bit of testing, so I think it is correct)
Code: (C++) [Select]
void action_move(const char dir[9], int argspeed) {
int dirs[9] = { 225, 270, 315, 180, -1, 0, 135, 90, 45 };
int chosendirs[9];
int choices = 0;
for (int i = 0; i < 9; i++)
if (dir[i] == '1') chosendirs[choices++] = dirs[i];
if (choices == 0) return;
choices = int(random(choices)); //choices is now chosen
//We use rval.d for efficiency, so hspeed/vspeed aren't set twice.
const double newdir =
((enigma::object_planar*)enigma::instance_event_iterator->inst)->direction.rval.d = chosendirs[choices];
if (argument_relative)
argspeed += ((enigma::object_planar*)enigma::instance_event_iterator->inst)->speed;
const double newspd =
((enigma::object_planar*)enigma::instance_event_iterator->inst)->speed.rval.d = chosendirs[choices] == -1 ? 0 : argspeed;
((enigma::object_planar*)enigma::instance_event_iterator->inst)->hspeed.rval.d = newspd * cos(newdir);
((enigma::object_planar*)enigma::instance_event_iterator->inst)->vspeed.rval.d = newspd * sin(newdir);
}
Note 1: The first argument should always be an array of characters of size 9. Longer strings are fine, but only the first 9 characters will be examined. Shorter strings may cause this to look at memory beyond the string.
Note 2: This code makes use of the random(x) function.
Note 3: A few minor optimizations can be made around random.
3a: To avoid the use of random when there's only 1 choice. Replace:
choices = int(random(choices)); //choices is now chosen
With
Code: (C++) [Select]
if (choices == 1) choices = 0;
else choices = int(random(choices)); //choices is now chosen
3b: Replace random with randomInt if it's more efficient (and if it exists).3c: Replace random with integrated choose() function once it's implemented, if it's more efficient.
532
General ENIGMA / Re: DnD Functions
« on: November 02, 2010, 09:27:02 am »
Don't forget negative numbers.
533
General ENIGMA / Re: DnD Functions
« on: November 01, 2010, 09:30:00 pm »
The problem is that there are different conditional actions, and action_if is just a function name. For conditional actions, I do already prepend "if" for it, and then handle "not" by also prepending "!". The function then follows, so it's simple enough to just write the code for it, but I can't assume that action_if is necessary the if action, because it could very well be user coded with special conditions, in which case it should simply behave as a "return x != 0;"
534
Function Peer Review / Re: GML: All draw_text functions +(string_width, _height, _width_ext, _height_ext)
« on: October 31, 2010, 09:27:52 pm »Quote
When you draw text, even rotated, the text is still following a linear pattern: You can trace a line across the tops of the glyphs.Er... Maybe I'm taking this out of context here, but since when has this been true? Glyphs should only be aligned by their baseline, which is usually closer to the bottom of the glyph (even for the "p", "g", "q", and "y" glyphs). Most notably, your theory falls apart for capitalisation - the top of the "c" and "C" glyphs should not align.
535
General ENIGMA / Re: DnD Functions
« on: October 31, 2010, 09:00:56 pm »
I'm not completely sure, but this might fall apart when the user selects "not". Judging by the way I coded LGM to handle it, I think action_if, when passed "x" and having "not" selected, LGM will generate the following code:
if !action_if(x)
Which would make yours generate the following code after resolving the defines:
if !if(x)
Perhaps a better solution might be
inline boolean action_if(var x) { /* return x != 0 */ }
or
#define action_if(x) (x != 0)
if !action_if(x)
Which would make yours generate the following code after resolving the defines:
if !if(x)
Perhaps a better solution might be
inline boolean action_if(var x) { /* return x != 0 */ }
or
#define action_if(x) (x != 0)
536
Function Peer Review / Re: GML: All draw_text functions (WIP)
« on: October 29, 2010, 04:59:21 pm »
That's what I meant, I just didn't feel like writing the code out. In fact, I don't know if GM does this, but if "//#" is displays the / glyph followed by a newline, you could do that with a boolean that toggles for each '/' encountered, and you don't have to look backwards then.
Also, watch out for EnigmaSettings.cppStrings, which is currently not passed to Enigma yet, but is togglable by the user. When toggled, # is treated as a literal # glyph, and / no longer serves as an escape character.
Also, watch out for EnigmaSettings.cppStrings, which is currently not passed to Enigma yet, but is togglable by the user. When toggled, # is treated as a literal # glyph, and / no longer serves as an escape character.
537
Function Peer Review / Re: GML: All draw_text functions (WIP)
« on: October 29, 2010, 04:15:48 pm »
Regex in EGML would be extremely useful. But for the purpose of finding non-escaped #s in strings... it's overkill. It's really not that hard to do an char *num = indexof(str,'#') and then num != str && *(num-1) != '/'
538
Function Peer Review / Re: GML: All draw_text functions (WIP)
« on: October 29, 2010, 02:32:25 pm »
Actually regex isn't all that slow. In fact, the term "regular" means that it should be able to search a string in runtime O(N) where N is the length of the string, which is the fastest runtime that you can search an unindexed, unsorted string for a single character (unless you know something about the string, of course).
539
Proposals / Re: Decrease Code Size?
« on: October 21, 2010, 08:19:39 pm »
I know PHP very well. As for caching, I think it'd be an admin-run script which would generate a release for people to download, rather than user run. Again, if we could create a set of exact rules on what to do, I can write a script to do it.
540
Issues Help Desk / Re: enigma on windows
« on: October 21, 2010, 08:08:15 pm »
freezway: This is caused from you using an old, old version which exhibited this bug, caused by the updater not asking for a program restart after updating the jar. The fix would be to download and use a newer version, but workarounds exist.
You must first shut down the program. At this point, you almost definitely have an outdated enigma dll/so which may or may not work, so it needs rebuilding. LGM+plugin does not know to rebuild it automatically (in your version). 3 ways to force a rebuild:
1) The recommended way: Delete libCompileEGMF.so or compileEGMf.dll.
2) Wait for another update to come around, which should cause enigma to update and rebuild when you run LGM+plugin.
3) Build it yourself, using any approved builder (such as Make or C::B).
Once you have done this, simply run the program (unless you chose option 2, in which case the program is already running). If you chose option 1, LGM will issue a rebuild. Otherwise, LGM should pickup the newly built enigma and work with it.
A possible 4th way does exist, if you have upgraded LGM+plugin to a new enough version. This was the way that we solved the problem.
4) (java) Preferences.userRoot().node("/org/enigma").putBoolean("NEEDS_REBUILD",true);
(basically, in windows, this adds an entry to the registry somewhere called NEEDS_REBUILD with value of true. In linux, it does so with a file somewhere.) The next time LGM+plugin is run, it will read this entry, realize that it needs rebuilding, and do so.
You must first shut down the program. At this point, you almost definitely have an outdated enigma dll/so which may or may not work, so it needs rebuilding. LGM+plugin does not know to rebuild it automatically (in your version). 3 ways to force a rebuild:
1) The recommended way: Delete libCompileEGMF.so or compileEGMf.dll.
2) Wait for another update to come around, which should cause enigma to update and rebuild when you run LGM+plugin.
3) Build it yourself, using any approved builder (such as Make or C::B).
Once you have done this, simply run the program (unless you chose option 2, in which case the program is already running). If you chose option 1, LGM will issue a rebuild. Otherwise, LGM should pickup the newly built enigma and work with it.
A possible 4th way does exist, if you have upgraded LGM+plugin to a new enough version. This was the way that we solved the problem.
4) (java) Preferences.userRoot().node("/org/enigma").putBoolean("NEEDS_REBUILD",true);
(basically, in windows, this adds an entry to the registry somewhere called NEEDS_REBUILD with value of true. In linux, it does so with a file somewhere.) The next time LGM+plugin is run, it will read this entry, realize that it needs rebuilding, and do so.