WOG 3.59 is out and open sorced

English source:
heroescommunity.com/viewthread.php3?TID=39810

For Russian language:
wforum.heroes35.net/showthread.p … 3#pid81383

What do you think of it?
Do another non-compatible soft is needed? ERA and WOG 3.58 mods not supported.
But it has LUA scripts support.

Is there will be gain for VCMI to use WOG 3.59 code?
VCMI lacks script support, maybe WOG will be useful as source of it’s realization?

While it could be useful in that there won’t be a need to reverse-engineer WOG stuff if it’s open-sourced, I doubt that code will be useful beyond that. For example, let’s say VCMI gets Lua scripting as well – it doesn’t mean that WOG’s Lua code and VCMI’s Lua code will be compatible, because the mapping Lua representation and internal implementation of game elements may be completely different.

VCMI being a full engine, it is the only sane and future-proof approach for extending Heroes 3.

It is sad that Grayface ignores Era and the enthusiasm it raised. Splitting era from 3.59 is a very bad idea and I hardly see how he will manage that, given that era mods will not be compatible on 3.59 and the last two years everyone worked only on era mods. I have no idea if LUA will be safer but I know what it takes to write a complete manual as the erm help, therefore I don’t expect any interesting mod soon for 3.59.

The only good thing IMO is that GF keeps his interest for Heroes.

Turnam, you’re completely right. WoG sources are not really useful for us - our internal model is too different from H3 so we can’t use it to add scripting to vcmi. And because WoG Lua is a wrapper on top of ERM we can’t use it either.
(Not mentioning quality of that code. It is a miracle that that thing works)

Valery19, yeah. H3 modding is already split too much :frowning:
As for Lua - actually you don’t need complete manual for Lua. As I said - this is a thin wrapper on top of ERM meaning that all ERM commands are still here. The only difference is syntax.
See for yourself: left is Lua code, right - ERM:

 IF:M("Hello world!")                   -- !!IF:M^Hello world!^
 FU(555):P(1,2)                         -- !!FU555:P1/2;
 CA(4,5,0):M2(0, 1, 10)                 -- !!CA4/5/0:M2/0/1/10;
 local t, st = CA(4,5,0):M2(0, ?v, ?v)  -- !!CA4/5/0:M2/0/?y1/?y2;
 local name = UN:A(2, 9, ?z)            -- !!UN:A2/9/?z-1;

These are just random bits of Lua/ERM comparison code but they show situation well

I don’t see much of a difference between the ERM and Lua, it is something, but not that much, still complicated and hard to read. How could scripting look like in VCMI?

That’s because WOG’s Lua is, as said, a thin wrapper on ERM instead of something actually tied to the engine. Lua code can be a lot cleaner and more intelligible than that.

You can look at examples here:
lua-users.org/wiki/SampleCode

Those aren’t really game-related, so maybe a better source of examples would be here:
grimrock.net/forum/viewtopic.php?f=14&t=3099

An example in particular:

-- start teleporter if both torch holders are filled
function cooltele()
    if leftholder:hasTorch() == true and
    rightholder:hasTorch() == true then
        coolteleporter:activate()
    else
        coolteleporter:deactivate()
    end
end

Doesn’t seem too horrible, does it? The same kind of logic could be used in a scripted Heroes map to have a teleporter activate after two obelisks have been visited.

The important thing here is what hooks the engine gives to allow Lua code to interface with internal stuff. In WOG’s case, the hooks are through ERM, so having Lua on top is basically useless. It doesn’t increase legibility of the code at all. In VCMI, if it got Lua scripting, it would end up looking a lot more like the Grimrock example, where you can simply perform fairly high-level stuff.

Even a bit better wrapper would be a huge improvement. For example replace ERM 2-letter commands with proper names. Compare this random set of symbols:

 CA(4,5,0):M2(0, 1, 10)

With this:

 GetCastleByLocation(4,5,0):SetAvailableCreatures(0, 1, 10)

First part is obvious - get castle at location (4,5,0), 0 stands for surface
Second part definitely does something with creatures but 0/1/10 are not really descriptive

Something like this would be even better (although difficult to implement via wrapper):

 GetCastleByLocation(4,5, MapLevel:Surface):GetDwelling(1):SetAvailable(10)
  • Provide enumeration for map levels. A bit more clear compared to 3 numbers.
  • Second part provides access to dwellings, and it is clear that “1” stands for requested level.
  • Third part changes amount of available creatures to 10.
    Much clearer now :slight_smile:

To avoid huge lines or to allow multiple operations on same object it can be stored in a variable:

local town = GetCastleByLocation(4,5, MapLevel:Surface)

town:GetDwelling(0):SetAvailable(20)
town:GetDwelling(1):SetAvailable(10)
town:GetDwelling(2):SetAvailable(5)

What does town:GetDwelling(0):SetAvailable(20) mean? So the levels range from 0-6, not 1-7?
It’s much easier to make mistakes in ERM, and get errors in mods later when playing.

That’s how all arrays are indexed in majority of programming languages including C++.

However it seems that Lua counts everything from 1. So proper Lua <-> C++ wrapper should translate 0-indexed values into 1-indexed values and vice versa.
On the other hand - Python (another language that was proposed for vcmi scripting) counts from 0 as well. So if we’ll choose Python we’ll have 0-based indexing.

F/e/ experimental Lua “Helloworld” from the depth of my archives.

function onHeroVisitTown ()
	local p = SLB.packets.SystemMessage()
	p.text = "Hello, world!"
	engine:commitPackage(p)
end

AVS seems to enjoy complicated code.

Better just check Heroes 5 scripting manual, this game implemented Lua in easy (but also limited) way.