Whats the most complex thing

Jan 19 2005, 6:06 am In response to Theodis
SSJ Radditz	If memory serves me right, he hasn't ever released the source to anything he's done. so I am familiar. But I can still say I wouldn't mind seeing how he did it. =)

Jan 19 2005, 6:24 am In response to SSJ Radditz
OneFishDown	http://www.pages.drexel.edu/~rrm322/inventory.zip it uses screen objects to display items in your inventory. the only "trick" is how it calculates the position of the screen objects, which isn't really a trick, its just a little math. and someone mentioned this thing: http://www.pages.drexel.edu/~rrm322/wave.zip

Jan 19 2005, 6:28 am In response to OneFishDown
Wizkidd0123	OneFishDown wrote: it uses screen objects to display items in your inventory. the only "trick" is how it calculates the position of the screen objects, which isn't really a trick, its just a little math. Could you explain the "little math" for me please, OFD? =)

Jan 19 2005, 6:42 am In response to OneFishDown
Jmurph	Now why Pac Man needs inventory..... I wonder if it is terribly complex, though. Sure, it is a clever use of screen objects and some basic math for the rotation, but not terribly difficult as far as I can tell.

Jan 19 2005, 6:54 am In response to Jmurph
Foomer	Jmurph wrote: Now why Pac Man needs inventory..... I wonder if it is terribly complex, though. Sure, it is a clever use of screen objects and some basic math for the rotation, but not terribly difficult as far as I can tell. Don't know, can't ever get OFD to reveal his source code. :P At least he's thinking "outside the box" though.

Jan 19 2005, 7:20 am

In response to Foomer

Wizkidd0123

Foomer wrote:

Don't know, can't ever get OFD to reveal his source code. :P
At least he's thinking "outside the box" though.

Well, I talked to him in Chatters about it, and if anybody wants it, here's a transcipt of the important points of the conversation. All graphical triangle representations were done by OFD in a /showcode window:

/*
OneFishDown wrote:
> it uses screen objects to display items in your inventory. the only "trick"
  is how it calculates the position of the screen objects, which isn't really a
  trick, its just a little math.

Could you explain the "little math" for me please, OFD? =)

---

OneFishDown:   well, sin() and cos() are functions that return the ratio of one side of a
               right triangle to another
               
Wizkidd0123:   What's the difference between a sin and a cosin?
OneFishDown:   the difference are the sides it uses
OneFishDown:   sin(angle) = opposite / hypotenuse
OneFishDown:   cos(angle) = adjacent / hypotenuse

     /|
    / |
  H/  |
  /   | Opp
 /    |
/A____|
   adj

A is the angle

Wizkidd0123:   And you would use 360/number of items to get the angle!
OneFishDown:   right
OneFishDown:   but check if src.contents.len isn't zero so you don't get a runtime error


       ITEM
       /|
      / |
     /  |
   H/   | Y
   /    |
  /     |
P/A_____|
     X

       ITEM
       /|
      / |
     /  |
   H/   | Y
   /    |
  /     |
P/A_____|
     X

cosine is defined as being the adjacent / hypotenuse
cos(A) = X / H

multiply each side by H and you get:

H * cos(A) = X


you can do the same with sin(A) to get Y

Wizkidd0123:   So, OFD, I would use X and Y to determine how many tiles and/or pixel offsets
               the item is from the player?
               
OneFishDown:   yeah


    3________2
    /\      /\
   /  \    /  \
  /    \  /    \
4/______\/______\1
 \      /\      /
  \    /  \    /
   \  /    \  /
    \/______\/
    5        6

each item is at a different angle, the difference
between each angle is 360/contents.len

*/

Jan 19 2005, 7:21 am In response to Hazman
Foomer	Hazman wrote: I wrote a MUD parser in about 30 mins. I spent a month building the parser and all the commands and engine stuff for FoomerMUD. Then I realized the whole thing was pointless and deleted it. Whee!

Jan 19 2005, 7:48 am

In response to Crispy

Lummox JR

Crispy wrote:

That sounds seriously cool. Would you be able to do things like have some people walking on roofs, while other people are walking around inside the house? (Basically the same as you described, except that the roofs and the people on them are not visible to the people inside the house - and vice versa.)

I would pay for a library that did that semi-seamlessly. And I don't just mean "if it was on BYONDscape"; I'd pay for just that library, without gaining access to other libraries. =)

This might be doable with great difficulty. Unfortunately BYOND has two issues that limit its capabilities in this department: 1) It has no easy means of duplicating another appearance (atom or image) at another location as if it is locally visible. 2) It has no easy means of rendering certain items selectively invisible, though it can make them selectively visible. The complexity involved in a decent roof library is one example. And this ties in a bit with some of the view issues I wanted to resolve.

To allow roof walking of the sort you described, I believe that during movement to the roof it would be necessary to change the mob's icon to null and display an /image, and likewise make the roof an /image. I can see a few potential problems arising from this, including notably that many verbs and view() would all still apply normally. However this is probably not an insurmountable challenge.

Lummox JR

Jan 19 2005, 11:10 am In response to Lummox JR
Jon88	Okay, thanks. Shadowdarke's Darke Night has something like that. It's pretty fun. :)

Jan 19 2005, 11:37 am In response to Foomer
Smoko	Foomer wrote: Don't know, can't ever get OFD to reveal his source code. :P At least he's thinking "outside the box" though. Hes the like Microsoft, damn anti open source people

Jan 19 2005, 12:34 pm In response to Smoko
OneFishDown	Smoko wrote: Foomer wrote: Don't know, can't ever get OFD to reveal his source code. :P At least he's thinking "outside the box" though. Hes the like Microsoft, damn anti open source people and then i started on my DBZ game and i decided, "hey, why not make it open source too, people would like that", and everyone said that was a bad idea. geez, make up your minds =P

Jan 19 2005, 12:38 pm In response to OneFishDown
Wizkidd0123	OneFishDown wrote: and then i started on my DBZ game and i decided, "hey, why not make it open source too, people would like that", and everyone said that was a bad idea. geez, make up your minds =P I thought that it was a good idea: lots of people could learn from that.

Jan 19 2005, 3:07 pm

In response to Lummox JR

Crispy

Lummox JR wrote:

To allow roof walking of the sort you described, I believe that during movement to the roof it would be necessary to change the mob's icon to null and display an /image, and likewise make the roof an /image.

Yeah, that's what I was thinking... I was hoping you had some magical spiffy alternate way, but I guess not. =)

I can see a few potential problems arising from this, including notably that many verbs and view() would all still apply normally. However this is probably not an insurmountable challenge.

Defining custom view()-style procs would be easy enough, provided the programmer remembered to use them instead of the standard ones. The verb problem is annoying, because things like this aren't possible:

proc/strangeview(atom/viewer)
   // Replacement for view()
   // ... code goes here ...
   return something

mob/verb/prod()
   set src in strangeview(usr)
   usr << "You prod [src]."
   src << "[src] prods you."

That just gives a "strangeview: undefined proc" compilation error on the "set src". I don't suppose there's any chance of BYOND being able to do "set src in myproc()" any time soon? =) It'd help a lot with things like this.

Z levels could be used to simulate the effect. I can think of two approaches here:

1. Actually use a separate Z level for each height level. Atoms on other levels would have to be displayed using images, or "proxy" atoms (copies of the atoms that are the same type and have all the same properties - probably excepting their contents lists - but any verbs applied to them are applied to the "real" atom. This means you can have more control over "set src in" verbs; e.g., people can shoot() other people who are standing on roofs, but can't prod() them). This requires some /image trickery if you want to have, for example, roofs and people on them visible from outside the building but not inside the building; but nothing that hasn't been done before in roof libraries.

2. Put all the graphical effects and client.eyes on a single Z level, but use "shadow" Z levels where the atoms actually are to get the verbs working properly. This requires only one image or "proxy" atom per "real" atom, but (A) messes with client.eye and (B) requires extra /image trickery to get roofs and such appearing and disappearing.

That seems like far too much effort. Eh. Maybe I'll just do it in Python. =P