* time.g weirdness @ 2004-08-10 17:51 Robert Goulding 2004-08-10 18:11 ` Hans Ronne ` (2 more replies) 0 siblings, 3 replies; 33+ messages in thread From: Robert Goulding @ 2004-08-10 17:51 UTC (permalink / raw) To: xconq7 [-- Attachment #1: Type: text/plain, Size: 568 bytes --] Twice I've been playing time.g using the new Mac OSX binaries; and in both games something weird has happened to one of my triremes. Having developed tech to the City level, I've sent off an unneeded trireme to explore uncharted territory by clicking at random on a black section of the map. Each time, the boat has reached the place I clicked - but that place was inland, so that the trireme is now stuck! I've attached a little snapshot from my most recent game. Here, the trireme is awaiting orders, having reached the position I sent it to... Robert. [-- Attachment #2: weird-trireme.png --] [-- Type: image/png, Size: 70896 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-10 17:51 time.g weirdness Robert Goulding @ 2004-08-10 18:11 ` Hans Ronne 2004-08-11 1:23 ` Hans Ronne 2004-08-12 15:39 ` Hans Ronne 2 siblings, 0 replies; 33+ messages in thread From: Hans Ronne @ 2004-08-10 18:11 UTC (permalink / raw) To: Robert Goulding; +Cc: xconq7 >Twice I've been playing time.g using the new Mac OSX binaries; and in >both games something weird has happened to one of my triremes. Having >developed tech to the City level, I've sent off an unneeded trireme to >explore uncharted territory by clicking at random on a black section of >the map. Each time, the boat has reached the place I clicked - but >that place was inland, so that the trireme is now stuck! I've attached >a little snapshot from my most recent game. Here, the trireme is >awaiting orders, having reached the position I sent it to... Now, that is a strange bug, indeed. I could not reproduce it, but I presume that is because it appears at City level, as you said, and I did not have time to play the game that long. Could you send me a saved game where this bug is "enabled" so that I can study it in more detail? Hans ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-10 17:51 time.g weirdness Robert Goulding 2004-08-10 18:11 ` Hans Ronne @ 2004-08-11 1:23 ` Hans Ronne 2004-08-11 16:34 ` Jim Kingdon 2004-08-12 15:39 ` Hans Ronne 2 siblings, 1 reply; 33+ messages in thread From: Hans Ronne @ 2004-08-11 1:23 UTC (permalink / raw) To: Robert Goulding; +Cc: xconq7 >Twice I've been playing time.g using the new Mac OSX binaries; and in >both games something weird has happened to one of my triremes. Having >developed tech to the City level, I've sent off an unneeded trireme to >explore uncharted territory by clicking at random on a black section of >the map. Each time, the boat has reached the place I clicked - but >that place was inland, so that the trireme is now stuck! I've attached >a little snapshot from my most recent game. Here, the trireme is >awaiting orders, having reached the position I sent it to... OK, I have managed to reproduce this now, and I think I know what is going on. The ship is actually behaving as it should, since ships can move along rivers in time.g: (table mp-to-traverse (ship river 2) (ground road 1) ) This is called a "border slide" in Xconq terminology. Now, the real problem is that Xconq fails to set a move task that requires a border slide when you try to do this manually. This is because the move command pre-flight code doesn't know about border slides. I think that Peter Garrone added some code that addressed this problem, but it was probably removed with his path-finding code. Anyway, the command pre-flight also has other problems, as I mentioned earlier, so it is probably due for an overhaul. Hans ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-11 1:23 ` Hans Ronne @ 2004-08-11 16:34 ` Jim Kingdon 2004-08-11 16:34 ` Hans Ronne 2004-08-11 16:41 ` Eric McDonald 0 siblings, 2 replies; 33+ messages in thread From: Jim Kingdon @ 2004-08-11 16:34 UTC (permalink / raw) To: xconq7 > Now, the real problem is that Xconq fails to set a move task that > requires a border slide when you try to do this manually. This is > because the move command pre-flight code doesn't know about border > slides. Ah, OK, that explains why I never could make sense of that border slide stuff. It also might be nice if the online help said something a bit more than just: Needs MP to enter terrain: 99 by default, 1 into sea, shallows, 0 into river. Needs MP to traverse terrain: -1 by default, 2 across river. although I'm not really sure how to express this best. I guess the "99 by default" could be turned into "cannot enter other terrain" (if the help code can figure out that 99 is never possible). Something similar for the "-1 by default". Although I suppose the real problem here is that the online help doesn't know about the user interface, so it can't just say "to travel along a river, click ....". Maybe the user interface could have some kind of mouseover (I could threaten to make it a tooltip for Xconq Office) when you are on a unit which has a border slide possible. Or something along these lines... Of course, all this is predicated on making border slides work from the user interface in the first place. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-11 16:34 ` Jim Kingdon @ 2004-08-11 16:34 ` Hans Ronne 2004-08-11 16:47 ` Eric McDonald 2004-08-11 16:41 ` Eric McDonald 1 sibling, 1 reply; 33+ messages in thread From: Hans Ronne @ 2004-08-11 16:34 UTC (permalink / raw) To: Jim Kingdon; +Cc: xconq7 >It also might be nice if the online help said something a bit more >than just: > > Needs MP to enter terrain: 99 by default, 1 into sea, shallows, 0 into > river. > Needs MP to traverse terrain: -1 by default, 2 across river. > >although I'm not really sure how to express this best. I guess the >"99 by default" could be turned into "cannot enter other terrain" (if >the help code can figure out that 99 is never possible). Something >similar for the "-1 by default". Heh, that makes me recall the long and at the end almost metaphyscial discussion I had with Peter Garrone last year about the meaning of the number "99" :-). >Although I suppose the real problem here is that the online help >doesn't know about the user interface, so it can't just say "to travel >along a river, click ....". Maybe the user interface could have some >kind of mouseover (I could threaten to make it a tooltip for Xconq >Office) when you are on a unit which has a border slide possible. Or >something along these lines... > >Of course, all this is predicated on making border slides work from >the user interface in the first place. Right. I'm looking into this. Even more important, however, is to fix the "map the unknown by clicking in it" exploit, which sneaked back in when we removed Peter's pathfinding. Hans ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-11 16:34 ` Hans Ronne @ 2004-08-11 16:47 ` Eric McDonald 2004-08-11 17:09 ` Hans Ronne 0 siblings, 1 reply; 33+ messages in thread From: Eric McDonald @ 2004-08-11 16:47 UTC (permalink / raw) To: Hans Ronne; +Cc: Jim Kingdon, xconq7 On Wed, 11 Aug 2004, Hans Ronne wrote: > Right. I'm looking into this. Even more important, however, is to fix the > "map the unknown by clicking in it" exploit, which sneaked back in when we > removed Peter's pathfinding. As I recall, it was also in the early version of Peter's pathfinder, and we ended up with all that CMD_EXPLORE and PND_UNMAPPED stuff and whatnot as part of the fix. (After he hacked over my initial hack, which just assigned unexplored hexes a value of 1 or 2.) Eric ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-11 16:47 ` Eric McDonald @ 2004-08-11 17:09 ` Hans Ronne 2004-08-12 4:03 ` Eric McDonald 0 siblings, 1 reply; 33+ messages in thread From: Hans Ronne @ 2004-08-11 17:09 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >On Wed, 11 Aug 2004, Hans Ronne wrote: > >> Right. I'm looking into this. Even more important, however, is to fix the >> "map the unknown by clicking in it" exploit, which sneaked back in when we >> removed Peter's pathfinding. > >As I recall, it was also in the early version of Peter's >pathfinder, and we ended up with all that CMD_EXPLORE and >PND_UNMAPPED stuff and whatnot as part of the fix. (After he >hacked over my initial hack, which just assigned unexplored hexes >a value of 1 or 2.) Well, the problem in that case was actually the opposite: it was impossible to move into the unknown because the early version of Peter's pathfinder always returned false. I think the problems we see now are due to subsequent changes in the command pre-flight code which were in prompted by and in part depended on Peter's code. Some of these changes were kept when the pathfinding was removed. I have just checked out the November 12 sources. My intention is to try to restore command processing as closely as possible to how it worked back then. With no path-finding algorithm, some of these pre-flight checks make little sense. Hans ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-11 17:09 ` Hans Ronne @ 2004-08-12 4:03 ` Eric McDonald 2004-08-12 11:16 ` Hans Ronne 0 siblings, 1 reply; 33+ messages in thread From: Eric McDonald @ 2004-08-12 4:03 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 Hans Ronne wrote: >>On Wed, 11 Aug 2004, Hans Ronne wrote: > Well, the problem in that case was actually the opposite: it was impossible > to move into the unknown because the early version of Peter's pathfinder > always returned false. Oh, right. I did flip things around. >I think the problems we see now are due to > subsequent changes in the command pre-flight code which were in prompted by > and in part depended on Peter's code. Some of these changes were kept when > the pathfinding was removed. > > I have just checked out the November 12 sources. My intention is to try to > restore command processing as closely as possible to how it worked back > then. With no path-finding algorithm, some of these pre-flight checks make > little sense. Well, just for the record, removing the pathfinding code was not an easy exercise once things had started to become entangled as they had. However, it was not a blind one either; the code surgery would have been completed much sooner than it was, if I hadn't given each reverse patch a fair amount of consideration and determined what needed to be cut out of the reverse patch (in order to keep it in the code repository). It is certainly possible that with so many different little pieces of code being touched over a period spanning half a year, and with the application of an occasional patch hunk failing (and thus needing further editing), that something slipped through the cracks. It could also be that I misjudged how a piece of machinery would behave after the alteration. I did try to pay attention to such things, but, like I said, it was not an easy task by any means. I also think that, when I completed the operation, I admonished ourselves to be on the lookout for breakage, knowing that it would almost certainly be found. Eric ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-12 4:03 ` Eric McDonald @ 2004-08-12 11:16 ` Hans Ronne 0 siblings, 0 replies; 33+ messages in thread From: Hans Ronne @ 2004-08-12 11:16 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >>I think the problems we see now are due to >> subsequent changes in the command pre-flight code which were in prompted by >> and in part depended on Peter's code. Some of these changes were kept when >> the pathfinding was removed. >> >> I have just checked out the November 12 sources. My intention is to try to >> restore command processing as closely as possible to how it worked back >> then. With no path-finding algorithm, some of these pre-flight checks make >> little sense. > >Well, just for the record, removing the pathfinding code was not an easy >exercise once things had started to become entangled as they had. You did a great job with the path-finding rollback. I'm not blaming you for this bug since it was not easy to anticipate. Hans ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-11 16:34 ` Jim Kingdon 2004-08-11 16:34 ` Hans Ronne @ 2004-08-11 16:41 ` Eric McDonald 2004-08-12 8:42 ` Jim Kingdon 1 sibling, 1 reply; 33+ messages in thread From: Eric McDonald @ 2004-08-11 16:41 UTC (permalink / raw) To: Jim Kingdon; +Cc: xconq7 On Wed, 11 Aug 2004, Jim Kingdon wrote: > It also might be nice if the online help said something a bit more > than just: > > Needs MP to enter terrain: 99 by default, 1 into sea, shallows, 0 into > river. > Needs MP to traverse terrain: -1 by default, 2 across river. > > although I'm not really sure how to express this best. I guess the > "99 by default" could be turned into "cannot enter other terrain" (if > the help code can figure out that 99 is never possible). Something > similar for the "-1 by default". I have been strongly considering the idea of introducing the concept of relative infinities. So, if a game designer says that he/she is going to use 9999 to represent an impossible action, then he/she could write: (set relative-infinity 9999) as a global, and then help system would do special interpretation with it. I am still not sure if this is the best way to proceed. As far as certain defaults that mean impossible (0 or -1), they could also be handled as such on a case-by-case basis. This is something I definitely plan to do. (The relative infinity stuff could come in handy in the actual Xconq action logic as well, since then we would no longer be divining the intent of the designer wrt a number, but would have his/her explicitly stated intention that the number should be treated as indicating an impossiblility, unlimited capacity, etc... of some sort.) I also intend to make it possible to list off several related values in the same listing, such as with the adjacent terrain changing stuff that I added a while back ago. So, yes, I do plan to do more with the online help system (the changes which will also be automatically reflected in the help file output), and I have been thinking about these very issues. But, I have been doing so much coding at work lately that I haven't felt like writing any code for Xconq. Hence my image-related work. > kind of mouseover (I could threaten to make it a tooltip for Xconq > Office) when you are on a unit which has a border slide possible. This isn't such a bad idea. (I notice that the IMFApp Office thread has thus far failed to lure Stan out onto the list again. He must be on vacation, only reading the monthly list digests, or something....) > Of course, all this is predicated on making border slides work from > the user interface in the first place. Right. It is true that Peter had some border slide logic in his code. However, it was deeply rooted into one of the functions which I had to surgically remove, and I didn't see any easy way of saving that part of the logic. The other thing is, _I have no idea whether it actually worked. It seemed reasonable, but, given all the other brokenness that came with his code, I don't think we should assume that it actually worked, unless someone has proof that it did. Eric ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-11 16:41 ` Eric McDonald @ 2004-08-12 8:42 ` Jim Kingdon 2004-08-12 8:56 ` Hans Ronne 2004-08-12 16:55 ` Eric McDonald 0 siblings, 2 replies; 33+ messages in thread From: Jim Kingdon @ 2004-08-12 8:42 UTC (permalink / raw) To: mcdonald; +Cc: xconq7 > (set relative-infinity 9999) Is this better than adding infinity to the lisp object system (with infinity getting its own value in enum lisptype)? I guess for the latter you'd need to figure out comparisons, arithmetic, etc, anew, which might be a bit of a pain. And of course there would be the problem of when it is brought into C code, does it turn into TABHI, or does the code need to check for it specifically, or what? What I had in mind was something much less deep. If mp-to-enter-terrain says you need 99 movement points, and acp-per-turn, free-mp, etc, say that a unit can never get 99 movement points in a turn, then have the help report it as infinite. The big problem with that is that it is very case-by-case, and it would be easy for this computation to be out of sync with the action code. So maybe one of the infinity variants would make more sense anyway. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-12 8:42 ` Jim Kingdon @ 2004-08-12 8:56 ` Hans Ronne 2004-08-12 15:42 ` Jim Kingdon 2004-08-12 16:55 ` Eric McDonald 1 sibling, 1 reply; 33+ messages in thread From: Hans Ronne @ 2004-08-12 8:56 UTC (permalink / raw) To: Jim Kingdon; +Cc: xconq7 >What I had in mind was something much less deep. If >mp-to-enter-terrain says you need 99 movement points, and >acp-per-turn, free-mp, etc, say that a unit can never get 99 movement >points in a turn, then have the help report it as infinite. The big >problem with that is that it is very case-by-case, and it would be >easy for this computation to be out of sync with the action code. So >maybe one of the infinity variants would make more sense anyway. In fact, I did something very similar to supply_desc last year: /* Don't print out storage space if it is set to arbitrarily large (9999, 999 or 99) as in many games. */ if (um_storage_x(u, m) == 9999 || um_storage_x(u, m) == 999 || um_storage_x(u, m) == 99) { tprintf(buf, "%s %d ", m_type_name(m), unit->supply[m]); } else { tprintf(buf, "%s %d/%d ", m_type_name(m), unit->supply[m], um_storage_x(u, m)); } This is what the subsequent discussion with Peter Garrone was about. He thought (based on a less than perfect documentation) that 9999 really meant infinite storage space. Hans ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-12 8:56 ` Hans Ronne @ 2004-08-12 15:42 ` Jim Kingdon 2004-08-12 16:58 ` Eric McDonald 0 siblings, 1 reply; 33+ messages in thread From: Jim Kingdon @ 2004-08-12 15:42 UTC (permalink / raw) To: hronne; +Cc: xconq7 > /* Don't print out storage space if it is set to arbitrarily large > (9999, 999 or 99) as in many games. */ Well, that's more problematic, in that it doesn't check storage against consumption, production, etc. Certainly in the standard game, 99 is nowhere near "infinite" for storage space. It does seem like an argument for some more real form of infinity (maybe just TABHI). ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-12 15:42 ` Jim Kingdon @ 2004-08-12 16:58 ` Eric McDonald 2004-08-12 17:35 ` Hans Ronne 0 siblings, 1 reply; 33+ messages in thread From: Eric McDonald @ 2004-08-12 16:58 UTC (permalink / raw) To: Jim Kingdon; +Cc: hronne, xconq7 On Thu, 12 Aug 2004, Jim Kingdon wrote: > > /* Don't print out storage space if it is set to arbitrarily large > > (9999, 999 or 99) as in many games. */ > > Well, that's more problematic, in that it doesn't check storage > against consumption, production, etc. I agree. This is one of the pieces of code I had in mind when I suggested that relative infinity would be useful beyond just the help system. > It does seem like an argument for some more real form of infinity > (maybe just TABHI). I agree. Eric ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-12 16:58 ` Eric McDonald @ 2004-08-12 17:35 ` Hans Ronne 0 siblings, 0 replies; 33+ messages in thread From: Hans Ronne @ 2004-08-12 17:35 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >On Thu, 12 Aug 2004, Jim Kingdon wrote: > >> > /* Don't print out storage space if it is set to arbitrarily large >> > (9999, 999 or 99) as in many games. */ >> >> Well, that's more problematic, in that it doesn't check storage >> against consumption, production, etc. > >I agree. This is one of the pieces of code I had in mind when I >suggested that relative infinity would be useful beyond just the >help system. > >> It does seem like an argument for some more real form of infinity >> (maybe just TABHI). > >I agree. I also agree that a real infinite instead of the bogus ones (99 etc) would be nice, so if any of you want to give it a try, I'm all for it. There was one other consideration with the above code, though, and that was to save space and reduce the clutter in the unit info box (and Mac unit closeup popup). This is what they would look like in most games before the change: Food: 4 / 9999 Minerals: 6 / 9999 Fuel: 2 / 9999 Ideas: 12 / 9999 Typically, the right half of this line would be truncated in the closeups (which are smaller than the unit info boxes). Now it says instead: Food: 4 Minerals: 6 Fuel: 2 Ideas: 12 which is much neater. Now, if the game designer sets capacity to a bogus infinite, it usually means that he doesn't expect the ceiling to be hit in a real game. If 99 is too low, he would use 999 or 9999 instead. This, in turn, means that the player has no interest in knowing about the capacity. All he needs to know is that there is no ceiling that he has to worry about. Which is why I suppressed the printing of bogus infinites. The weak point here is of course that the game designer may deviate from this rule, by intention or mistake. Having a relative infinite that defaults to TABHI, and which is suppressed in most outputs, is therefore a superior solution. Hans ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-12 8:42 ` Jim Kingdon 2004-08-12 8:56 ` Hans Ronne @ 2004-08-12 16:55 ` Eric McDonald 1 sibling, 0 replies; 33+ messages in thread From: Eric McDonald @ 2004-08-12 16:55 UTC (permalink / raw) To: Jim Kingdon; +Cc: xconq7 On Thu, 12 Aug 2004, Jim Kingdon wrote: > > (set relative-infinity 9999) > > Is this better than adding infinity to the lisp object system (with > infinity getting its own value in enum lisptype)? I don't know. I haven't forgotten that you have suggested adding an actual infinity quantity before, but I have some qualms about that too, some of which you bring up below. >I guess for the > latter you'd need to figure out comparisons, arithmetic, etc, anew, > which might be a bit of a pain. And of course there would be the > problem of when it is brought into C code, does it turn into TABHI, or > does the code need to check for it specifically, or what? In the case of tables, the only storage type that they currently support is 'short'; even TABDICE are just shorts. Even in the case of properties, assignments of varying types are not supported, and so if there is an integer property it could not be bound to an 'Obj* lispinf' or whatever. > What I had in mind was something much less deep. If > mp-to-enter-terrain says you need 99 movement points, and > acp-per-turn, free-mp, etc, say that a unit can never get 99 movement > points in a turn, then have the help report it as infinite. The big > problem with that is that it is very case-by-case, and it would be > easy for this computation to be out of sync with the action code. Exactly. This is not such a big deal as long as one writes functions that are common to both. >So > maybe one of the infinity variants would make more sense anyway. The relative infinity idea would be the easiest to code, in my estimation, but it is also the crudest. The case-by-case logic probably makes the most sense in the long run. I have already been heading in this direction with the common ACP and MP arithmetic functions that I have been written (with more to come). Hans has already created some fairly decent volume checking functions that can be used rather ubiquitously as well. Eric ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-10 17:51 time.g weirdness Robert Goulding 2004-08-10 18:11 ` Hans Ronne 2004-08-11 1:23 ` Hans Ronne @ 2004-08-12 15:39 ` Hans Ronne 2004-08-12 16:53 ` Jim Kingdon 2 siblings, 1 reply; 33+ messages in thread From: Hans Ronne @ 2004-08-12 15:39 UTC (permalink / raw) To: Robert Goulding; +Cc: xconq7 I have now checked in fixes that re-enable border slides and at the same time block the the click-in-unseen exploit. The border slide issue raises some interesting questions, though. I'm not sure that the way it now works in time.g (and possibly in other games) really makes sense. Here is how border slides are supposed to work, according to the manual: \ land / \ / \ river / A sea ------------- B sea / \ / \ / land \ Ships in the sea cell A can slide along the river to reach the sea cell at B. In some low resolution maps, "rivers" are used to implement straits, such as Gibraltar or Kattegatt. All of which makes sense. However, in time.g, ships can also move on land using border slides along rivers. The reason for this is that ships are allowed to occupy land cells. So why, in that case, is it not possible to just move the ship onto a beach by clicking on it? The answer is mp-to-enter-terrain. There are three ways to restrict access of a unit to a specific terrain in Xconq: 1. By volume restrictions (terrain capacity and unit-size-in-terrain). 2. By move restrictions (mp-to-enter-terrain and mp-to-leave-terrain). 3. By survival restrictions (vanishes-on and wrecks-on). Most games use volume restrictions or a combination of volume restrictions and other restrictions. However, time.g relies exclusively on move restrictions to prevent access of land units to sea cells and vice versa. This scheme breaks down when border slides are used. So is this a feature or a bug? I think the latter. If border slides were supposed to enable navigation of rivers in general, it should be possible for a ship to move along the river to any cell that borders on it (or contains it in the case of connection-type rivers). However, this is not how things now work in time.g. Instead, the ship is limited to jumping back and forth between a limited number of non-adjacent cells along the river that happen to fit the border slide scheme. It ends up moving somewhat like a knight in chess. I doubt that this is what Stan had in mind when he wrote the code. It is of course easy to fix this by adding volume restrictions in time.g. However, I am not sure how many other games also rely on move restrictions, and would have to be changed accordingly. Hans ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-12 15:39 ` Hans Ronne @ 2004-08-12 16:53 ` Jim Kingdon 2004-08-12 16:59 ` Hans Ronne 2004-08-12 17:08 ` Eric McDonald 0 siblings, 2 replies; 33+ messages in thread From: Jim Kingdon @ 2004-08-12 16:53 UTC (permalink / raw) To: xconq7 > 1. By volume restrictions (terrain capacity and unit-size-in-terrain). > 2. By move restrictions (mp-to-enter-terrain and mp-to-leave-terrain). > 3. By survival restrictions (vanishes-on and wrecks-on). This has always seemed confusing to me. The game designer, to get things to work consistently, seemingly has to set a bunch of these properties. Maybe the number of properties controlling which units can go where can be reduced? Not that I've looked through the existing games trying to figure out what combinations are in use (and whether they are doing so intentionally or unintentionally). ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-12 16:53 ` Jim Kingdon @ 2004-08-12 16:59 ` Hans Ronne 2004-08-12 17:08 ` Eric McDonald 1 sibling, 0 replies; 33+ messages in thread From: Hans Ronne @ 2004-08-12 16:59 UTC (permalink / raw) To: Jim Kingdon; +Cc: xconq7 >> 1. By volume restrictions (terrain capacity and unit-size-in-terrain). >> 2. By move restrictions (mp-to-enter-terrain and mp-to-leave-terrain). >> 3. By survival restrictions (vanishes-on and wrecks-on). > >This has always seemed confusing to me. > >The game designer, to get things to work consistently, seemingly has >to set a bunch of these properties. > >Maybe the number of properties controlling which units can go where >can be reduced? Not that I've looked through the existing games >trying to figure out what combinations are in use (and whether they >are doing so intentionally or unintentionally). We could hardly do without either terrain capacities or movement costs. And the wreck-unit code also serves its own purpose. The question is rather what the best way is to restrict access to certain terrain types. I usually use capacities, but I'm not sure it's a good idea to enforce them in all games. FWIW, volume restrictions appear to be more robust than move restrictions, where all sorts of complicated situations can arise due to units entering or leaving other units etc. Perhaps you remember the "tank sitting in water bug"? (see last year's mail archive). That was another case of move restrictions failing to work the way they were supposed to. Hans ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-12 16:53 ` Jim Kingdon 2004-08-12 16:59 ` Hans Ronne @ 2004-08-12 17:08 ` Eric McDonald 2004-08-12 17:19 ` Hans Ronne 1 sibling, 1 reply; 33+ messages in thread From: Eric McDonald @ 2004-08-12 17:08 UTC (permalink / raw) To: Jim Kingdon; +Cc: xconq7 On Thu, 12 Aug 2004, Jim Kingdon wrote: > > 1. By volume restrictions (terrain capacity and unit-size-in-terrain). > > 2. By move restrictions (mp-to-enter-terrain and mp-to-leave-terrain). > > 3. By survival restrictions (vanishes-on and wrecks-on). > > This has always seemed confusing to me. > > The game designer, to get things to work consistently, seemingly has > to set a bunch of these properties. Hans and I had a thread about this before (I don't remember if it was public or not), but, generally speaking, the move restrictions should be used to limit whether or not an unit can enter a given terrain. Using survival restrictions is not reliable, especially since deliberate movement in wreck/vanish situations should not necessarily be prohibited (even though the AI should try to avoid them). Eric ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-12 17:08 ` Eric McDonald @ 2004-08-12 17:19 ` Hans Ronne 2004-08-12 17:24 ` Eric McDonald 0 siblings, 1 reply; 33+ messages in thread From: Hans Ronne @ 2004-08-12 17:19 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >On Thu, 12 Aug 2004, Jim Kingdon wrote: > >> > 1. By volume restrictions (terrain capacity and unit-size-in-terrain). >> > 2. By move restrictions (mp-to-enter-terrain and mp-to-leave-terrain). >> > 3. By survival restrictions (vanishes-on and wrecks-on). >> >> This has always seemed confusing to me. >> >> The game designer, to get things to work consistently, seemingly has >> to set a bunch of these properties. > >Hans and I had a thread about this before (I don't remember if it >was public or not), but, generally speaking, the move restrictions >should be used to limit whether or not an unit can enter a given >terrain. Using survival restrictions is not reliable, especially >since deliberate movement in wreck/vanish situations should not >necessarily be prohibited (even though the AI should try to avoid >them). I would modify that to say that either move or volume restrictions, but not the wreck-unit code, should be used to limit access. And I would in fact recommend volume restrictions to somebody who is writing his first game, since they are less likely to produce unexpected results (like the one we are discussing). Move restrictions are more versatile, but also trickier to use. Hans ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-12 17:19 ` Hans Ronne @ 2004-08-12 17:24 ` Eric McDonald 2004-08-12 18:15 ` Hans Ronne 0 siblings, 1 reply; 33+ messages in thread From: Eric McDonald @ 2004-08-12 17:24 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 On Thu, 12 Aug 2004, Hans Ronne wrote: > I would modify that to say that either move or volume restrictions, but not > the wreck-unit code, should be used to limit access. And I would in fact > recommend volume restrictions to somebody who is writing his first game, > since they are less likely to produce unexpected results (like the one we > are discussing). Move restrictions are more versatile, but also trickier to > use. You now seem much more comfortable with the volume restrictions than you did a year ago. I guess haven't found any good volume checking bugs in a while. ;-) Eric ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-12 17:24 ` Eric McDonald @ 2004-08-12 18:15 ` Hans Ronne 2004-08-13 23:46 ` Eric McDonald 2004-08-14 3:50 ` Wrecked-Type Doesn't Apply to Detonating Units Elijah Meeks 0 siblings, 2 replies; 33+ messages in thread From: Hans Ronne @ 2004-08-12 18:15 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >On Thu, 12 Aug 2004, Hans Ronne wrote: > >> I would modify that to say that either move or volume restrictions, but not >> the wreck-unit code, should be used to limit access. And I would in fact >> recommend volume restrictions to somebody who is writing his first game, >> since they are less likely to produce unexpected results (like the one we >> are discussing). Move restrictions are more versatile, but also trickier to >> use. > >You now seem much more comfortable with the volume restrictions >than you did a year ago. I guess haven't found any good volume >checking bugs in a while. ;-) Well, volume checking is a problem for anyone who is writing kernel code. But to a newbie game designer, volume restrictions are easier to use. That was my whole point. No need to worry about border slides, ferry costs etc. Hans ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: time.g weirdness 2004-08-12 18:15 ` Hans Ronne @ 2004-08-13 23:46 ` Eric McDonald 2004-08-14 3:50 ` Wrecked-Type Doesn't Apply to Detonating Units Elijah Meeks 1 sibling, 0 replies; 33+ messages in thread From: Eric McDonald @ 2004-08-13 23:46 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 On Thu, 12 Aug 2004, Hans Ronne wrote: > Well, volume checking is a problem for anyone who is writing kernel code. > But to a newbie game designer, volume restrictions are easier to use. That > was my whole point. No need to worry about border slides, ferry costs etc. If the newbie game designer just sticks to using 'mp-to-enter-terrain', and doesn't worry about traversal, ferry, and leave costs, then I would argue that that is just as simple as volume restrictions, if not simpler. Eric ^ permalink raw reply [flat|nested] 33+ messages in thread
* Wrecked-Type Doesn't Apply to Detonating Units 2004-08-12 18:15 ` Hans Ronne 2004-08-13 23:46 ` Eric McDonald @ 2004-08-14 3:50 ` Elijah Meeks 2004-08-14 9:19 ` Eric McDonald 1 sibling, 1 reply; 33+ messages in thread From: Elijah Meeks @ 2004-08-14 3:50 UTC (permalink / raw) To: xconq7 It seems that the wrecked-type-if-destroyed table doesn't apply to units destroyed by detonating units. Is this by intention? __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Wrecked-Type Doesn't Apply to Detonating Units 2004-08-14 3:50 ` Wrecked-Type Doesn't Apply to Detonating Units Elijah Meeks @ 2004-08-14 9:19 ` Eric McDonald 2004-08-14 15:36 ` Hans Ronne 2004-08-16 0:27 ` Elijah Meeks 0 siblings, 2 replies; 33+ messages in thread From: Eric McDonald @ 2004-08-14 9:19 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 Elijah Meeks wrote: > It seems that the wrecked-type-if-destroyed table > doesn't apply to units destroyed by detonating units. > Is this by intention? I don't recall intentionally setting it up that way. I suppose it could be made to do so, but I am not sure whether that would be a good idea or not. What if a detonating unit can also destroy another unit through conventional means? I guess we could pretend that this is never a real game design possiblility, and let the 'wrecked-type-if-destroyed' table handle detonation deaths as well. If we don't, then probably YANT (yet another new table) is called for: 'wrecked-type-if-blown-up', perhaps? Eric ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Wrecked-Type Doesn't Apply to Detonating Units 2004-08-14 9:19 ` Eric McDonald @ 2004-08-14 15:36 ` Hans Ronne 2004-08-14 16:00 ` Eric McDonald 2004-08-16 0:27 ` Elijah Meeks 1 sibling, 1 reply; 33+ messages in thread From: Hans Ronne @ 2004-08-14 15:36 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >Elijah Meeks wrote: > >> It seems that the wrecked-type-if-destroyed table >> doesn't apply to units destroyed by detonating units. >> Is this by intention? > >I don't recall intentionally setting it up that way. I suppose it could >be made to do so, but I am not sure whether that would be a good idea or >not. What if a detonating unit can also destroy another unit through >conventional means? I guess we could pretend that this is never a real >game design possiblility, and let the 'wrecked-type-if-destroyed' table >handle detonation deaths as well. If we don't, then probably YANT (yet >another new table) is called for: 'wrecked-type-if-blown-up', perhaps? How about simply wrecked-type, a default table to catch everything that is not further specificed? There are other cases as well, such as WRECK_TYPE_TERRAIN, that are not covered right now. Ideally, the code should also check wrecked-type if wrecked-type-if-destroyed et al. are missing, so that the game designer can use one table for everything if he wants to make things simple. Hans ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Wrecked-Type Doesn't Apply to Detonating Units 2004-08-14 15:36 ` Hans Ronne @ 2004-08-14 16:00 ` Eric McDonald 2004-08-14 17:42 ` Eric McDonald 0 siblings, 1 reply; 33+ messages in thread From: Eric McDonald @ 2004-08-14 16:00 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 Hans Ronne wrote: > How about simply wrecked-type, a default table to catch everything that is > not further specificed? There is already the 'wreck-type' unit property. >There are other cases as well, such as > WRECK_TYPE_TERRAIN, that are not covered right now. Ideally, the code > should also check wrecked-type if wrecked-type-if-destroyed et al. are > missing, It does. The default wrecked type for any sort of wreckage is still 'wreck-type', both in the case where there the default value is found in a special wreckage table, and in the case where there is no special wreckage table. I believe I mention this in the documentation and/or announcement of the the special wreckage tables. >so that the game designer can use one table for everything if he > wants to make things simple. Yes, the code should already do that, and I made the behavior that way for precisely this reason. Eric ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Wrecked-Type Doesn't Apply to Detonating Units 2004-08-14 16:00 ` Eric McDonald @ 2004-08-14 17:42 ` Eric McDonald 0 siblings, 0 replies; 33+ messages in thread From: Eric McDonald @ 2004-08-14 17:42 UTC (permalink / raw) To: xconq7 Eric McDonald wrote: > Hans Ronne wrote: > >> How about simply wrecked-type, a default table to catch everything >> that is >> not further specificed? > > > There is already the 'wreck-type' unit property. 'wrecked-type', not 'wreck-type' Also, the table that we were discussing earlier is 'wrecked-type-if-killed' and not 'wrecked-type-if-destroyed'. (Just setting the record straight in case a new game designer is reading this.) Eric ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Wrecked-Type Doesn't Apply to Detonating Units 2004-08-14 9:19 ` Eric McDonald 2004-08-14 15:36 ` Hans Ronne @ 2004-08-16 0:27 ` Elijah Meeks 2004-08-16 18:24 ` Eric McDonald 1 sibling, 1 reply; 33+ messages in thread From: Elijah Meeks @ 2004-08-16 0:27 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 > I don't recall intentionally setting it up that way. > I suppose it could > be made to do so, but I am not sure whether that > would be a good idea or > not. What if a detonating unit can also destroy > another unit through > conventional means? I guess we could pretend that > this is never a real > game design possiblility, and let the > 'wrecked-type-if-destroyed' table > handle detonation deaths as well. If we don't, then > probably YANT (yet > another new table) is called for: > 'wrecked-type-if-blown-up', perhaps? I think it's forseeable that you could want different wreck-types depending on whether a unit destroys another unit conventionally (In this case I'm thinking of ships or battlemechs with nuclear engines, which when destroyed or self-destructed perhaps cause different effects than their regular attacks) but, for now, I think it would be fine to just default the wrecked-type-if-killed table to apply to detonating units. As far as I'm aware, there are no current games that would be adversely affected by this and there are a couple cute things I want to do with this feature in Opal. __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Wrecked-Type Doesn't Apply to Detonating Units 2004-08-16 0:27 ` Elijah Meeks @ 2004-08-16 18:24 ` Eric McDonald 2004-08-16 21:34 ` Elijah Meeks 0 siblings, 1 reply; 33+ messages in thread From: Eric McDonald @ 2004-08-16 18:24 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 Elijah Meeks wrote: > but, for > now, I think it would be fine to just default the > wrecked-type-if-killed table to apply to detonating > units. The problem is that later on, if we want to separate out the detonation damage from the conventional attack damage, it might be troublesome, and will add to the complexity. If we make the 'wrecked-type-if-killed' provide the wrecked types for units killed by explosion, and if you start using it for that purpose, then we would have to make 'wrecked-type-if-blown-up' default to the value of 'wrecked-type-if-killed' rather than directly to the value of 'wrecked-type'. But, maybe this is how it should behave anyway. I haven't thought it through completely. Until I get around to making 'wrecked-type-if-killed' apply to explosion casualties as well, or making a new 'wrecked-type-if-blown-up' table, could you just assign the blown up types using the 'wrecked-type' properties of the units? Or are your needs more complicated than that? Eric ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Wrecked-Type Doesn't Apply to Detonating Units 2004-08-16 18:24 ` Eric McDonald @ 2004-08-16 21:34 ` Elijah Meeks 2004-08-17 0:50 ` Eric McDonald 0 siblings, 1 reply; 33+ messages in thread From: Elijah Meeks @ 2004-08-16 21:34 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 > Until I get around to making > 'wrecked-type-if-killed' apply to explosion > casualties as well, or making a new > 'wrecked-type-if-blown-up' table, > could you just assign the blown up types using the > 'wrecked-type' > properties of the units? Or are your needs more > complicated than that? As I understand it, what you're saying is set the unit property 'wrecked-type' to one setting and then override it with the wrecked-type-if-killed for all normal units? Example: (unit city (wrecked-type nuked-city)) (table wrecked-type-if-killed (city u* ruined-city) ) I'll check this at home, but my understanding of the wreck-typing code is that the result would be what I'm looking for, a different wreck-type as a result of an exploding unit which ignores the wrecked-type-if-killed table but does call the wrecked-type unit property. That would work. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Wrecked-Type Doesn't Apply to Detonating Units 2004-08-16 21:34 ` Elijah Meeks @ 2004-08-17 0:50 ` Eric McDonald 0 siblings, 0 replies; 33+ messages in thread From: Eric McDonald @ 2004-08-17 0:50 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 Elijah Meeks wrote: > Example: > > (unit city (wrecked-type nuked-city)) > > (table wrecked-type-if-killed > (city u* ruined-city) > ) Yes. This is what I had in mind. > I'll check this at home, but my understanding of the > wreck-typing code is that the result would be what I'm > looking for, a different wreck-type as a result of an > exploding unit which ignores the > wrecked-type-if-killed table but does call the > wrecked-type unit property. > > That would work. OK, good. If it doesn't do what you need, let me know, and I will try to work out a better arrangement in the fairly near future. Eric ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2004-08-17 0:35 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-08-10 17:51 time.g weirdness Robert Goulding 2004-08-10 18:11 ` Hans Ronne 2004-08-11 1:23 ` Hans Ronne 2004-08-11 16:34 ` Jim Kingdon 2004-08-11 16:34 ` Hans Ronne 2004-08-11 16:47 ` Eric McDonald 2004-08-11 17:09 ` Hans Ronne 2004-08-12 4:03 ` Eric McDonald 2004-08-12 11:16 ` Hans Ronne 2004-08-11 16:41 ` Eric McDonald 2004-08-12 8:42 ` Jim Kingdon 2004-08-12 8:56 ` Hans Ronne 2004-08-12 15:42 ` Jim Kingdon 2004-08-12 16:58 ` Eric McDonald 2004-08-12 17:35 ` Hans Ronne 2004-08-12 16:55 ` Eric McDonald 2004-08-12 15:39 ` Hans Ronne 2004-08-12 16:53 ` Jim Kingdon 2004-08-12 16:59 ` Hans Ronne 2004-08-12 17:08 ` Eric McDonald 2004-08-12 17:19 ` Hans Ronne 2004-08-12 17:24 ` Eric McDonald 2004-08-12 18:15 ` Hans Ronne 2004-08-13 23:46 ` Eric McDonald 2004-08-14 3:50 ` Wrecked-Type Doesn't Apply to Detonating Units Elijah Meeks 2004-08-14 9:19 ` Eric McDonald 2004-08-14 15:36 ` Hans Ronne 2004-08-14 16:00 ` Eric McDonald 2004-08-14 17:42 ` Eric McDonald 2004-08-16 0:27 ` Elijah Meeks 2004-08-16 18:24 ` Eric McDonald 2004-08-16 21:34 ` Elijah Meeks 2004-08-17 0:50 ` Eric McDonald
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).