People are making posts with a lot of words in them. I just don't have the time to look at all those words, especially if they turn out to be poopy ones. So I will just state my opinionated opinions in a grand, "I am better than you" order list.

1) The Verge Source was poopy. Except for all the nice files made by other people.

2) I liked everyone who worked on the Verge Source, except tatsumi. He was poopy.

3) There were rarely any long posts on the Verge source forum, which was good.

4) Vecna and Loretian are much better names that tatsumi and the Speed Bump.

5) Python, VC, PASCAL. I don't care, they're all poopy. But I'm leaning towards tatsumi's PASCAL version of PERGE because Python seems poopy.

6) Why is six afraid of seven?

7) 8) 9) HAHA ^_^

10) Everyone and everything is stupid and poopy. Except for Bumpy's wonderful Python engine based on Verge.

And we drank out of dirty glasses. And it was good.

Now for the morals in all the poopy:

Get the files and articles to Verge-Rpg so we don't have to rape all of the Verge Source.

Stop complaining about the many Verge versions. v2.7 will be standard when Bumpy is finished. In the mean time either use V2 + j for Dos or V2k for Windows. However there aren't many differences between the Dos versions and people seem to be using them effectively.

Give VDE more glory. It is very good. Package it with the engine.

Verge isn't dead, don't be stupid. And if the Verge Source was a great era then I can't see the great works it has produced.

Stop writing dissertations on the afformentioned points and morals. I can't believe you people can write whole pages of on this blah.

I can't think of anything else to say, as it should be. But I'll leave you with a writting tip. Verbosity and cleverness are great things. But anyone can be verbose and clever. Being brief and brilliant however, is unique.

I give this post a D+ for effort, or lack thereof.

---

Companions the creator seeks, not corpses, not herds and believers. Fellow creators the creator seeks--those who write new values on new tablets. Companions the creator seeks, and fellow harvesters; for everything about him is ripe for the harvest.

I said no text...

---

"Thats my Candy Bitch!" -Albert Einstein

If you can't read so many words, go back to elementary school and read some Dr. Seuss books. Those will help you read the books that the big kids can read. And you use the word poopy too much, which sounds gay.

-rpgking

---

Out of clutter, find simplicity. -Einstein

What's with all of these praises of v2.7 and Python?

When is someone going to glorify VC? P

---

Never. Because it sucks.

Before, for stats, you could use big ugly arrays.
stats[340]=34;

Now, you can use:
Mark.HP=34 c[0].HP=34 c['Mark'].HP=34
Mark.s[0]=34 c[0].s[0]=34 c['Mark'].s[0]=34
Mark.s['HP']=34 c[0].s['HP']=34 c['Mark'].s['HP']=34
----------------------------------------------------
VC's array support:
string a[4];
a[0] = "cheese";
a[1] = "ham';
a[2] = "pepperoni";
a[3] = "pineapple";
When you try to get a[4], Verge crashes.
TO ADD TO AN ARRAY: Impossible.

Python's list support:
a = ["cheese",'ham',"pepperoni","pineapple"]
When you try to get a[4], Verge crashes.
TO ADD TO AN ARRAY: a.append('canadian bacon')
----------------------------------------------------
VC's string support (to get the 3rd to last char):
string name,thirdtolast;
name = "Mark";
thirdtolast = mid(name,strlen(name)-4,1);

Python's string support:
name = "Mark"
thirdtolast = name[-3]
----------------------------------------------------
VC's int support and Python's int support are pretty much the same, except that Python has tons of math libs, making your old functions worthless.
----------------------------------------------------
VC's float support?: No
Python's float support?: Yes
----------------------------------------------------
VC's long support?: No
Python's long support?: Yes
----------------------------------------------------
VC's multi-typed arrays?: No
Python's multi-typed arrays?: Yes
----------------------------------------------------
VC's returning conditional types:
Impossible.

Python's returning conditional types:
def func(params): # NO TYPES AT ALL
a = [30,'cheese']
Either one can be returned in its actual form.
----------------------------------------------------
VC's codebase?: Meager
Python's codebase?: Huge
----------------------------------------------------
VC's array passing to function ability?: No
Python's array passing to function ability?: Yes
----------------------------------------------------
VC's array passing from function ability?: No
Python's array passing from function ability?: Yes
----------------------------------------------------
VC's base changer: Make it yourself.
Python's base changer: Built-in.
----------------------------------------------------
Python also has:
- associative arrays (called dictionaries)
- Great help at python.org
- Support with Blender, a 3d renderer that uses Python scripts
- Hundreds of pre-made libs.

That is all.

---

Yeah, I understand the likes of Quantum Physics and Molecular Theory. What's the point? I just need you to tie my shoes.

VC is a simplifed version of C. If you were expecting it to be easy like BASIC, you're diluted. I find nothing wrong with it, although you do have some good points. Nonetheless, I'd like to agrue and take the stance of a devoted VC coder.
You don't mind that it's hard? You can learn Python in hours. (closer to an hour if you've already programmed before)
Floats and longs, feh. Set up algothrims to emulate the effect.
Hacking things in results in messy code that's harder to read, alter and share.
Multi-dimesonal arrays were present in a early beta of V2.7, maybe someone can add them to VC version.
Good luck. v2.7's VC core was completely rewritten by myself. It's not possible to add that to the existing vc2 core without extnsive knowledge of the VC VM.

Returning Conditional Types. They exist and quite frankly they're easy to use. Then again, you could be referring to something else.
You misunderstand. Python functions can return any type. So, the same function can be made to return a string in one instance, a float in another, and a list of objects in yet another case. (personally, I think using the language in such a manner is a sign of bad design, but I'm used to strictly typed languages)

Array passing into and from functions. I don't see your point. What would you need this and if you wanted it, couldn't you still pull it off with VC? It might be harder, but if you use local variables or set up functions, you could probably do the same thing.
The answer to your first question is simply this. Modular code (that which does not rely on other code) is easy to reuse. Reusing code means more work done with less code, which is a good thing. Second, sorry, you can't fake this one in VC without hacking it to all hell and using stuff like malloc and quad[]. (which would reduce the code to a disgusting mess, see above)

Base Changer. Elaborate. This eludes me.
He's talking about hexadecimal and such. It's a minor point, I think, but he's right. Python intrinsically supports decimal (der), hex, octal, binary, and probably a few that I'm unaware of. VC has hex and decimal. (and the original V2 parsed hex incorrectly)

Associative arrays. Would be a good addition to VC but it still isn't needed.
Associative arrays aren't needed but neither are strings, strictly speaking. We could just use integers and use lots of copysprites to print text. (and use arrays of integers to hold the string data, since that's what strings really are anyway) It's messy and ugly though.

3D Support. It's a 2D game engine. If you want 3D, find someone to fix TMAPLine and TMAPPOLY, or you can always make a fine subsitute in VC like CYWolf (or was that Mythril?) did.
This is a simple matter of hardware acceleration. There's a partially working OpenGL driver for v2.7 now, and it's insanely fast. You can perform a scaled translucent RotScale type blit with no more speed hit than a normal blit operation. This kind of enhancement is out and out impossible in the current v2 core. Not "very hard", impossible. Due to the way v2 allows you full access to the images, no abstraction can be done, and thus the blits must always be done purely by software.

Pre-made libraries. VC has pre-made libraries and code that is easily readable (with the V2C reference manual) and assertable into any game. Just check tVs before it crumbles to dust.
Yes. v2.7's packin libraries will be both easier to use and more robust, however, due to Python's propensity to make extendible, modular code. Moreover, Python itself is shipped with about 30 (maybe more, it's a ballpark figure) modules for useful odds and ends. (sockets, math, etc)

I think that this is a glorious thing in VC and I am troubled that you would actually need a whole complete programming language to code your game. There are probably a lot of functions that you will never actually use and are not completely game specific.
v2 is flawed in that you have to program your game, yet it does not provide a sufficiently powerful language to make the task easy, neither does it provide any base code. (the community has done that, but most people reinvent the wheel anyway :P)

v2.7 embraces that aspect, yet will be shipped with a huge amount of code to fill in all the blanks v2 left open.

VC is game-specific. It's specific to the point where it doesn't shower you in immense completeness, leaving to wonder whether to use that lovely pre-defined functions or code your own.
Python is used all over the place. You can obtain documentation on it easily, and if you can code a game in v2.7, you can say you can program in Python. That's a real job skill, if you didn't know by now.

I think this whole switch to Python is yet another "point and make them look here" excuse for the lack of games. Hell, it is probably why no one has announced progress or projects with Verge because they are more likely than not afraid that the engine they have so passionately used will be left to rot, unupdated and uncared about. Then they'll have to switch. I am happy to admit that I am one of these people. I have learned VC well and I don't see any point (or benefit) in switching to Python. Maybe I might for the sake of satiating my laggard attitude, but I doubt it. I don't need the thrills of a completed language to build a game when I have a devoted one at my fingertips.
1) I never make any design decision based on 'publicity' or 'politics'. Ever. My focus is to make VERGE the best. Nothing else.
2) Python saves me a buttload of effort, and if you take the time to learn it (both of the hours that it would probably take) it'll save you a buttload of effort too.
3) Python is not complicated. It's becoming famous for its simple, consistent syntax. (some schools are teaching Python instead of Pascal as a first programming language, because it's so simple)

VC is a beautiful work, although not without it's imperfections and quirks, it does the job of gamemaking well and enabled game creation with a bigger sense of accomplishment than either RM2K or OHRPGCE.
I'm amazed that vecna made it work at all. You're right, though, it does work. But where VC is 'good enough', Python excels.

So basically...what does all of this mean? I don't give a heck about why Python is l33t. If it doesn't cause a phelthora of games to be released by next year's winter, it has done nothing but delayed and permanently killed a thousand novel ideas.
Nobody ever asked you to drop v2 and pick up v2.7. You did, however, ask why nobody was evangelizing VC. I think me and Thrasher have made that clear. :)

That's all, folks!

---

"I can't wait for this latest pile of melodrama to disappear, so that the VERGE community can once again concentrate on games rather than on itself." -- Joe Lee