Show Posts
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 »
467
Ideas and Design / Re: Rooms versus Windows
« on: January 23, 2011, 11:29:25 pm »
I like the idea, and I'm happy to assist in any way that I can, as long as we can maintain some level of compatibility with GM - meaning that I expect the GM-compatible side to be implemented first, I expect it to continue to function throughout the entire process, and I expect an immediate way for the incompatible stuff to either be immediately convertible or markedly inconvertible (e.g. a variable says "Wait, this isn't convertible with GM. We'll need to extend into our own incompatible format"). Preferably the prior option, but I can understand that some concepts are too extreme/revolutionary to be convertible, and I want to be somewhat open to them.
Also, I like where the extension system is going as well; I expected it to come, considering ENIGMA's extensibility. Again, however, I expect compatibility to be maintained.
Why? Because it's a bitch to try and restore it later, and everyone will get lazy and it will never happen.
Also, I'd suggest another name, like Frames or Panes or Panels. A window usually has the close button and such.
Also, I like where the extension system is going as well; I expected it to come, considering ENIGMA's extensibility. Again, however, I expect compatibility to be maintained.
Why? Because it's a bitch to try and restore it later, and everyone will get lazy and it will never happen.
Also, I'd suggest another name, like Frames or Panes or Panels. A window usually has the close button and such.
468
Function Peer Review / Re: move_towards_point
« on: January 20, 2011, 02:05:35 pm »
When you introduce the inst variable, you shouldn't keep it inline anymore I don't think, and it's redundant to return void to a void returning function. Also, indentation. This would be more likely:
Or this:
In addition, this doesn't stop when it has reached the point. It only ceases to set the motion. Recall that an object in motion continues to stay in motion until acted upon.
Append this prior to the last closing curly brace:
Code: (C++) [Select]
void move_point_stop(double x, double y, double spd) {
enigma::object_planar* const inst = ((enigma::object_planar*)enigma::instance_event_iterator->inst);
if (inst->x!=x || inst->y!=y)
motion_set(point_direction(inst->x,inst->y,x,y),spd);
}Or this:
Code: (C++) [Select]
inline void move_point_stop(double x, double y, double spd) {
if (((enigma::object_planar*)enigma::instance_event_iterator->inst)->x!=x
|| ((enigma::object_planar*)enigma::instance_event_iterator->inst)->y!=y)
motion_set(point_direction(
((enigma::object_planar*)enigma::instance_event_iterator->inst)->x,
((enigma::object_planar*)enigma::instance_event_iterator->inst)->y,
x,y),spd);
}In addition, this doesn't stop when it has reached the point. It only ceases to set the motion. Recall that an object in motion continues to stay in motion until acted upon.
Append this prior to the last closing curly brace:
Code: (C++) [Select]
else ((enigma::object_planar*)enigma::instance_event_iterator->inst)->speed = 0;Or if you already have inst defined:Code: (C++) [Select]
else inst->speed = 0;
469
Announcements / Re: Happenings
« on: January 18, 2011, 01:49:13 pm »
Yeah, scope problems, etc. I figured I'd just save myself the trouble of enumerating the problems with it and just say "it doesn't work that way"
470
Issues Help Desk / Re: Unit Formations In RTS
« on: January 18, 2011, 12:06:19 pm »
The idea, if I read this correctly, is that units maintain their orientation and distance from a central unit who goes towards the desired point, while everyone ends up at their respective distance and orientation from the central unit. This is essentially what Age of Empires II does with villagers.
So it's nothing new, and it can work, it's just somewhat ugly if the units aren't aligned already, or if they don't all fit in their target locations.
So it's nothing new, and it can work, it's just somewhat ugly if the units aren't aligned already, or if they don't all fit in their target locations.
471
Announcements / Re: Happenings
« on: January 18, 2011, 12:00:40 pm »
Yeah... it doesn't work that way.
Also, pretty sure the default case doesn't include the word 'case'.
It's unwise to initialize variables in a switch-case.
Also, pretty sure the default case doesn't include the word 'case'.
Code: (C++) [Select]
switch (existing_var_only) {
case 0: /* do stuff; */ break;
case 1: //fall into case 2
case 2: /* do stuff; */ break;
default: /* do stuff when existing_var_only takes on a value other than 0, 1, or 2; */ break;
}It's unwise to initialize variables in a switch-case.
472
Proposals / Re: switch and mp_step functions.
« on: January 12, 2011, 07:09:21 pm »
MrGriggs, the point behind peer review is that functions get reviewed by peers and improved upon before they get committed into the repository. This works any kinks out of them and ensures that they are up to efficiency specs, as well as making sure they don't break anything else. In the meantime, you may simply place the desired functions into Definitions, as Josh said.
Most notably, move_towards_point has been alleged to not even work properly due to degrees/radians issues, which could have led to a lot of unnecessary bug reports if it were already in the repository. Fortunately, peer review has alleviated that and helped diagnose and potentially correct this problem before it even makes it into the repo.
Most notably, move_towards_point has been alleged to not even work properly due to degrees/radians issues, which could have led to a lot of unnecessary bug reports if it were already in the repository. Fortunately, peer review has alleviated that and helped diagnose and potentially correct this problem before it even makes it into the repo.
473
Off-Topic / Re: Broken forums
« on: January 12, 2011, 07:01:21 pm »
I guess you didn't do a diff before you upgraded...
474
Proposals / Re: Object member functons
« on: January 07, 2011, 07:00:49 pm »
Suppose f1 and f2 return 0, and obj2.array[0,0] = 0.
The statement would be equivalent to the following:
obj1.a = 0;
As you can see, I'm totally lost, which is why someone needs to explain this one to me.
The statement would be equivalent to the following:
obj1.a = 0;
As you can see, I'm totally lost, which is why someone needs to explain this one to me.
475
Proposals / Re: Object member functons
« on: January 07, 2011, 06:04:27 pm »
You're going to have to explain that one to me... because I don't see what's wrong with it.
476
Proposals / Re: switch and mp_step functions.
« on: January 07, 2011, 04:06:13 pm »
http://enigma-dev.org/forums/index.php?topic=727.new#new
move_towards_point peer review.
move_towards_point peer review.
477
Function Peer Review / move_towards_point
« on: January 07, 2011, 04:05:11 pm »Code: (C++) [Select]
void motion_set(double newdir, double newspd) {
enigma::object_planar* const inst = ((enigma::object_planar*)enigma::instance_event_iterator->inst);
inst->direction.rval.d = newdir;
inst->speed.rval.d = newspd;
inst->hspeed.rval.d = newspd * cos(newdir);
inst->vspeed.rval.d = newspd * sin(newdir);
}
inline void move_towards_point(double x, double y, double spd) {
motion_set(point_direction(
((enigma::object_planar*)enigma::instance_event_iterator->inst)->x,
((enigma::object_planar*)enigma::instance_event_iterator->inst)->y,
x,y),spd);
}motion_set was borrowed from action_move. It's just used as a convenience method to set both speed and direction efficiently. There have been some concerns over radians vs. degrees, and I haven't looked into them fully, but oddly enough action_move seemed to work...
478
Proposals / Re: switch and mp_step functions.
« on: January 07, 2011, 02:18:31 pm »
functions like move_towards_point are very easy to implement in Definitions without the need of Josh. I'm sure anybody here with half a C++ brain could implement one for you.
480
Function Peer Review / Re: move_contact functions optimised for bbox
« on: January 03, 2011, 06:32:49 pm »
polygone, you may want to re-familiarize yourself with geometry.
First, there's two ways your statement "yet dx, dy are exactly the same" could be interpreted:
* dx1 = dy1 and dx2 = dy2
* dx1 = dx2 and dy1 = dy2
The first only occurs when the delta is at a slope of -/+ 1, so 45 degrees or 135 degrees. Since both line segments in the image have a positive slope, this could only occur if they both had an angle of 45 degrees, however this is clearly not the case. To further emphasize this, both segments begin from the same point, meaning they'd both overlap for the entirety of the travel of the shorter of the segments (or the entirety of the travel of both segments if the vectors are equal in magnitude).
The latter would imply that both segments are equivalent, but I'll spare you the proof, because it can visible be dismissed. If it were the case that dx1 = dx2 and dy1 = dy2, it would also be the case that dx1 = dx2. Since both segments begin from the same point, we know there is no vector displacement skewing. If we completely ignore the change in y coordinates of the two line segments, and only focus on the x coordinates, we can clearly see that one ends to the left of the other. Thus, dx1 < dx2 (or vice versa, depending on which one you decide is d1 and which is d2), but never dx1 = dx2.
First, there's two ways your statement "yet dx, dy are exactly the same" could be interpreted:
* dx1 = dy1 and dx2 = dy2
* dx1 = dx2 and dy1 = dy2
The first only occurs when the delta is at a slope of -/+ 1, so 45 degrees or 135 degrees. Since both line segments in the image have a positive slope, this could only occur if they both had an angle of 45 degrees, however this is clearly not the case. To further emphasize this, both segments begin from the same point, meaning they'd both overlap for the entirety of the travel of the shorter of the segments (or the entirety of the travel of both segments if the vectors are equal in magnitude).
The latter would imply that both segments are equivalent, but I'll spare you the proof, because it can visible be dismissed. If it were the case that dx1 = dx2 and dy1 = dy2, it would also be the case that dx1 = dx2. Since both segments begin from the same point, we know there is no vector displacement skewing. If we completely ignore the change in y coordinates of the two line segments, and only focus on the x coordinates, we can clearly see that one ends to the left of the other. Thus, dx1 < dx2 (or vice versa, depending on which one you decide is d1 and which is d2), but never dx1 = dx2.