Archived from groups: alt.games.vga-planets (
More info?)
KlingonKommand wrote:
> Stefan Reuther <stefan.news@arcor.de> writes
>> I have not understood many of the choices done in v4. What do we need
>> "ore" for? "Contraband"? Why do we need the distinction between "point
>> defense", "small", "large" and "super" weapons?
>
> <grinds teeth> don't talk to me about ore! I argued against it a lot.
>
> Contraband is essentially a risky way to invest cash. It will eventually
> go up in price (it fluctuates) but you may have to lock up cash for
> several turns. And you will raise crime if you meddle in it. It turns
> out to be an interesting set of tradeoffs. There were some loopholes
> which allowed experienced players to exploit it into their primary cash
> generation thing, but those are closed now.
Hmmm, okay. There is at least one v3 add-on which does something similar
("Friendly code lottery"). But I doubt that function needs to be in the
game core.
I think one point why v4 still is not ready is that Tim got lost in details.
>> Other things in v4 would nicely plug into the v3 universe. Pods maybe
>
> There is another frustrating thing about V4 - certain things only fit in
> certain kinds of carrier. Why can't a ship carry natives or ore, but a
> pod can? It is arbitrariness like this which puts off some people;
> difficult to learn.
It's similar in v3. A carrier cannot carry torps. No-one can carry
natives. I'm not too unhappy with these restrictions. Of course, if you
add new means to carry stuff around (in v4 it's pods - for v3 there is
an add-on called "Starbeamers", and quite a number of "Bank"-type
add-ons, and doubtlessly a wealth more; at least the starbeamers can be
configured to allow transport of natives), it starts getting inconsistent.
So far, v3 has had only one annoying inconsistence, which is that you
cannot drop money onto a planet you do not own yet. Well, I "fixed" that
in PHost 4
(JFTR: if you use add-ons, this feature is broken in all
current PHost 4's. New version follows soon, I hope.)
>> v4 seems to actively try to lock out add-ons. Why else would you encrypt
>> strings with the moral equivalent of rot-13?
>
> I *think* the "problem" is this:
> (1) Tim is using Visual Basic and Quickbasic to write it, not C.
> Therefore the data is held in weird Microsoft-defined data structures
> where V3 would have had a regular array defined by Tim.
Although Visual Basic has some restriction, this one is bogus. Even
BASIC PDS (=the one v3 is written in) supports arbitrary file access.
You can easily say "give me the 32-bit value at address 32498."
> (2) VGAP3 was rife with cheating and host addons which clashed because
> they tweaked data structures without really knowing what they were up
> to. Therefore DLL's are a sensible way of allowing data manipulation:
> the DLL's can contain error checks and checksum corrections.
It's a myth that this prevents cheating, because you still can bypass
the DLLs. To prevent cheating, you have to (a) trust all software that
runs on host side, and (b) validate everything that comes in from the
client. This works in v3 as well as in v4. Tim just did not implement it
in its entirety in host.exe. But there's the (older) check.exe, and
there's PHost.
And the best thing to avoid add-on clashes is to document the file
formats and protocols
> (3) Tim didn't want VGAP4, which was going to take a long time to
> develop, to get locked into one data structure. He realised he might
> have to add new fields and such. If host addons appeared too early he
> would not be able to retro-change data structures, you see. So he only
> wanted to allow host addons towards the end of development.
Although this is a weak argument (it's not too hard to define data
formats in an upward, across, and downward-compatible manner, it's just
some work), this is the main reason why I do not gripe too loudly about
v4. I know it's not yet finished, and I know that Tim wants to invest
time in finishing it, not writing a programmer's manual.
Actually, even having a programmer's manual does not avoid clashes. If
you look into your PHCC archive, that one comes bundled with a Killrace
utility which claims to support PHost. It supports PHost 2 (or another
dinosaur of that type), and happily blasts PHost 3 and 4 games into
pieces, because it chose to ignore the version number we placed in the
auxdata.hst file.
Stefan
(Is there a download link for the planets4.hlp somewhere? I recall there
was one someday, and my Planets4 installation seems to lack a help file.)