Messages

31

Gallery / Re: Stalkers vs Humans - A magical multiplayer interactive story (by cmen)

« on: October 04, 2011, 07:57:07 PM »

Our policy is that if you come back and start participating you're a member again. So just show up in the chat if you want to be a part of cmen.

So if I start playing BL again you guys will take me back?

32

General Discussion / Re: Convince Me.

« on: May 21, 2010, 11:30:58 PM »

It would be as easy as making a weapon.

Not really 'cause with a weapon you can start by just increasing the damage and changing the color-shift and going: "OOH LOOK, I ACCOMPLISHED NOTHING AND NOW HAVE REDUNDANT DATABLOCKS! ISN'T IT SO COOL!" whereas with 'gear' you cannot.

33

General Discussion / Re: Convince Me.

« on: May 21, 2010, 11:26:44 PM »

I see less noobs,

That is fluctuating.

1.Is C++ simular to HTML style sheets? I know the later language.

Only in that you use a keyboard to produce them. CSS is a markup language, and isn't even turring complete. C++ on the other hand is a real programming language. (Not that it matters in this case, because the engine isn't open source anyway.) Use torquescript to do stuff.

2.Is making vehicles and weapons difficult? If I know what I just listed?

Only if you are afraid of reading documentation.

3.I see being able to build with 100,00 bricks (more that I think I want suprisingly). How do vehicles, weapons, explosions, and excess game scripts effect the recomended amount?

Exactly how you would expect. Lag is lag, and it comes from having too many things to process.
If you really want to know, download a bunch of add-ons, and type metrics(fps); in the console (open it by pressing ~) and then look at the mspf as you build with more and more bricks. The mspf value is the number of miliseconds it takes to process each frame.

4.Will I get crap from low ID people for having a high ID?

I was once automatically banned from a server upon joining because I had an 8k blid, yeah, there is discrimination, suck it up and deal with it until a thousand more people buy BL after you. It's really not a big deal.

5.Are large scale vehicles (battleships, bombers) possible, as well as being able to walk on them?

http://forum.blockland.us/index.php?topic=87075 - out of bricks (see various screenshots)
http://forum.blockland.us/index.php?topic=74382 - as a vehicle (see carrier at bottom of first post)

6.Is custom character content easy to make?

Same as #2

7.I thought I had more to ask...

If so, I might have had more answers...

34

Suggestions & Requests / Re: V15

« on: May 21, 2010, 09:43:19 PM »

So? Didn't we all?

Nope.

35

General Discussion / Re: Percentage of Progress

« on: May 21, 2010, 09:36:17 PM »

for most projects, the trend seems to be:

0% - not started
75% - thought about doing it
increment by 5% each time you touch the project (regardless of how much you actually did) until you get to 90%
increment by 1% each time you touch the project (regardless of how much you actually did) until you get to 95%
abandon the project (when in reality it's only about 25% completed)

36

General Discussion / Re: Old servers...

« on: May 21, 2010, 09:24:30 PM »

USSR servers (especially their DMs)
mote servers (when I wasn't banned for no reason)
yuki's DMs (especially once the mechs came out)
NiXiLL's servers were always fun and always had something new and interesting that he was working on

and most of all, The Titanium's Team Blocktress 2

37

Modification Help / Re: RTB Development

« on: May 19, 2010, 08:37:39 PM »

Do you  have any idea what you've just done?
inb4massiveinfomaniactipparodies

Yes, wasted my time.
I spent about 15 minutes trying to get a screenshot of him in blockland saying that. I got it how I wanted (well, almost), but then crashed BL before I could actually take the screenshot, so I halfassed it in this post.

38

Modification Help / Re: RTB Development

« on: May 19, 2010, 08:27:35 PM »

Did you know,

I don't think I'd be too keen on ruining the minimalism of the loading screen, though.

39

Modification Help / Re: Projectile Emitter Nodes

« on: May 19, 2010, 05:59:08 PM »

How to save the rest of us time on questions that someone who really knows what they're talking about has taken the time to explain:

1) Find out what you are really trying to do. (In your case, I suppose you want a projectile to emit particles.)

2) (and you get Muffinmix's awesome guide to what you are trying to do)

3) Read until you understand. (Yeah, stuff about projectiles is after a bunch of other information, but you should still read it in order so you understand what he is talking about in the projectiles section.)

4) Think about how to accomplish what you wanted to do now that you know how. (What you originally wanted to doesn't really make sense because a projectile kind-of acts as an emitter node with its trail emitter.)

5) (Make your cannonball that leaves giant green lightning bolts in its wake or whatever.)

40

Modification Help / Re: Build in Mining mod

« on: May 19, 2010, 05:55:41 PM »

The misalignment occurs when bricks are rotated at 90 or -90 degrees. Or should I say AREN'T rotated at 90 or -90 degrees. They are actually rotated (-)90.0002 degrees, and (most likely not coincidentally) this is the same as the error produced when torque converts between radians and degrees.

Place 4 bricks each rotated 90 degrees more than the other, and look at <thebrick>.rotation for each
Then look at what is returned by mradtodeg(mdegtorad(90))
WOAH! IT'S THE SAME!

Floating bricks, buried bricks, overlapping bricks, etc. can be checked via containers and raycasts.

Now I'm not saying that you should reinvent the wheel, I'm just saying that it's possible (as far as I can tell atleast. That said, ::plant() may be in the engine and not written in torquescript, in which case the reason it's there is because it does things which are not exposed to us via torquescript, so we should call it regardless).

41

Modification Help / Re: Creating a .zip

« on: May 19, 2010, 05:28:59 PM »

Use WinRAR. It zips files.

<sigh>

42

Modification Help / Questions regarding undocumented GuiBitmapCtrl functionality

« on: May 19, 2010, 05:23:19 PM »

How does the value of overflowImage of a GuiBitmapCtrl change how the image is rendered.
Common sense would lead me to believe that if I were to leave wrap off, and the size of the image is greater than the extent of my GuiBitmapCtrl, the image would extend past the bounds of the gui element, however this is not the case.
I can't find any relevant documentation, and so far I see no difference when experimenting.

Also, GuiBitmapCtrl::setActive() appears to have no effect...  but then why would it exist?

I also want to be able to maintain an image's original size (1 pixel in the image file is 1 pixel rendered on screen, no antialiasing) and so far it appears the only way to really ensure that is to use GuiBitmapCtrl.wrap=1, but I really want to avoid wrapping the image.

Also, GuiBitmapCtrl.setValue() allows you to specify an offset (from the bottom left corner?) of the image to place at the bottom left corner of the GuiBitmapCtrl, however I want to be able to do the inverse (have the image start with the bottom left pixel of the image at an offset from the bottom left pixel of the guibitmapctrl). As you can see in the screenshots provided, simply specifying a negative offset doesn't solve this problem. (NOTE: the reason i want to avoid wrapping the image as stated above is because I want to be able to have an offset such that part of the guibitmapctrl is transparent, instead of viewing the other edge of the image.) The only way I can really think of doing this is setting the extent of the guibitmapctrl equal to the size of the bitmap, and then putting the guibitmapctrl inside another gui element (i tested it with a GuiControll) and that seems to work, although this leaves the problem of determining the proper extents and positions. (The position needs to be based off of the extent, which needs to be based off of the dimensions of the bitmap (as not to scale it) and I don't have a reliable way of getting that.)

Finally, GuiBitmapCtrl::getPixelColor() return values that do not reflect the actual color being displayed, is this a bug?

I think the GG forums may be the place to go for these questions, however overflowImage appears to be specific to blockland, so I'm starting here.

43

Modification Help / Re: Using the ammo system

« on: May 19, 2010, 04:11:45 PM »

I too am curious about those states.

As for the ammo field,
http://forum.blockland.us/index.php?topic=102790.0
however I never could find the crossbow script Space Guy referred to. (I eventually concluded that it must part of private documentation that you need to buy some torque product to receive.)


inb4spaceGuy

44

Modification Help / Re: GUI-calling functions

« on: May 19, 2010, 03:56:21 PM »

no, playGui.listObjects();

Guess what the lag icon is named... lemme take a wild guess, "LagIcon"? YES!
and it's just a normal guibitmapctrl, so it's fairly simple to interact with.

As for the function that shows and hides it, i believe that's an engine callback and if it isn't already it may be protected from packaging at some point, so I'd just use ::onWake() and ::onSleep() if you're trying to do something special when it comes and goes, and change LagIcon.visible or call LagIcon.setVisible() to show and hide it.

But beware, if it is still how it was last time I dealt with it, the lag icon can be shown quite frequently but for a very short duration (so short that you don't see it), and this can cause problems depending on what you are doing. Say for example that you want to automatically chat LAG whenever the lag icon appears, you would wind up chatting LAG when you didn't even see the lag icon, and it would probably end in you being kicked or banned. So, it would be wise to schedule whatever you wanted to do to happen like 250 miliseconds after the lag icon is shown, and cancel that schedule if it is hid again before the scheduled function is called, that way (if you are implementing the example above) you would only chat LAG when you actually knew you were lagging.

45

Modification Help / Re: Creating a .zip

« on: May 19, 2010, 03:35:20 PM »

If you are talking about updating and re-implementing a new library right in Blockland's source, then I laugh at you. Though it may take a bit more time, it's possible and there are other libraries out there that are way faster at zip i/o than zLib making them the logical choice. Programming a game is complicated, what do you expect?

No, zlib doesn't have anything to do with .zip files, it just handles the deflate standard. zip can use deflate as a compression algorithm but that's up to the zip implementation, not zlib.

zlib is not just used for dealing with zip files, it is used for much more (for example the png standard uses the zlib format for its IDAT chunk (among others)). also, if you look at the source distrobution for zlib, it includes more than just an implementation of the deflate standard, it has stuff for calculating various checksums (namely crc32 and adler32) which is needed to implement gzip and stuff.
Also, zip doesn't necessarily need to use deflate as it's compression algorithm.

Also, you can't just link zlib with blockland and expect it to work, you must properly interact with it, and as all big libraries go, the newer the version, the more bloated it gets and you have more and more overhead to do the exact same thing as a previous version. The reason you would go through that trouble is if there was a security vulnerability in the version you currently use, or there is new functionality in the most recent library that you want to use, or that is a more efficient replacement to your current implementation, not because you think that linking a newer version of said library would magically have torque hook into it's api and expose a console method to create zips.

I don't want to seem mean or whatever, but please do your homework before coming here and posting a link to something you know about but do not understand as it is usually not relevant and doesn't help anyone.