New game idea, but is it possible ?

[sunspot]

95.0 will contain a new handler.lua (atm just used for LuaIntro), best is to use lockluaui.txt and force using it.
With that new handler.lua ZK's modifications are deprecated and merged back into the engine + more. So no need anymore for custom handlers, instead modifications can be moved to an Utilities/* folder and so copying files between games becomes much easier.

I'm missing a lot of background information to understand your quote though JK. Do you mean that widgets.lua and main.lua contain handlers to call methods in the engine or something ??? Or has this to do with the fact that there is a hack in the engine somewhere that searches for lockluaui.txt to do some different behaviour ???

[jK]

The thing is that the engine just calls either ./luaui.lua (if it exists) or ./LuaUI/main.lua .
The engine doesn't know about `widgets` or `gadgets` it just makes calls into those files above (e.g. it calls G["DrawWorld"]), now coding this way would be very nasty and gets quite fast unmaintainable. So there is a in lua written handler, that works as a distributer of these callins and manages the widgets/gadgets.
The problem is that this in lua written handler had many downsides (missing callins, bugs, missing functions, ...), and so esp. CA/ZK patched some of those. This solved the problems for ZK but not for the other games, and it made it even more complicated to use lua code from ZK in other games.
Now the new 95.0 handler should fix all the downsides and gives interfaces to make needed modifications for specific games in a standarized way, and so simplifies copying lua code between games.

[sunspot]

The thing is that the engine just calls either ./luaui.lua (if it exists) or ./LuaUI/main.lua .
The engine doesn't know about `widgets` or `gadgets` it just makes calls into those files above (e.g. it calls G["DrawWorld"]), now coding this way would be very nasty and gets quite fast unmaintainable. So there is a in lua written handler, that works as a distributer of these callins and manages the widgets/gadgets.
The problem is that this in lua written handler had many downsides (missing callins, bugs, missing functions, ...), and so esp. CA/ZK patched some of those. This solved the problems for ZK but not for the other games, and it made it even more complicated to use lua code from ZK in other games.
Now the new 95.0 handler should fix all the downsides and gives interfaces to make needed modifications for specific games in a standarized way, and so simplifies copying lua code between games.

Ah I see so you could say that ZK actually runs on it's own forked handler instead of a standardized vanilla handler that should be used by everyone. With people copying left , right and center from ZK and branching of that code there is a wildgrowth of buggy handlers and coding by convenience instead of convention. Thats indeed something to stay away from. Nice that this will be fixed in an upcomming release

I've got ChiliUi working again and got rid of the stock ui. As an extra bonus I've updated my tutorial 3 and intro page of my ChiliUi tutorials to reflect some new stuff I just learned.

Next up : Create a chili window that is always locked on the bottom , regardless any resolution ... why do I have the feeling I'm gonna need math here ...

[gajop]

Next up : Create a chili window that is always locked on the bottom , regardless any resolution ... why do I have the feeling I'm gonna need math here ...

Math? Yes, first grade elementary level.

Imagine you want the window to be of 400x500 (width/height) dimensions.

1) It may be possible to just set the right = 400, down = 500, width = 400, height = 500, properties to the window control (with parent = screen0).
2) Otherwise check http://springrts.com/wiki/Lua_UnsyncedR ... w_Geometry. It should be able to calculate x and y via: Spring.GetWindowGeometry() or Spring.GetScreenGeometry() (not sure which one exactly) and then just subtract width/height from the maxX and maxY coordinates.

[jK]

Next up : Create a chili window that is always locked on the bottom , regardless any resolution ... why do I have the feeling I'm gonna need math here ...

Math? Yes, first grade elementary level.

Imagine you want the window to be of 400x500 (width/height) dimensions.

1) It may be possible to just set the right = 400, down = 500, width = 400, height = 500, properties to the window control (with parent = screen0).
2) Otherwise check http://springrts.com/wiki/Lua_UnsyncedR ... w_Geometry. It should be able to calculate x and y via: Spring.GetWindowGeometry() or Spring.GetScreenGeometry() (not sure which one exactly) and then just subtract width/height from the maxX and maxY coordinates.

Chili also supports so called relative coords (means the actual position & size depends on the parent ones).
examples:
Chili.Window:New{x=0,y=-100, height=100,width=100} -> bottom left corner
Chili.Window:New{x=-100,y=-100, height=100,width=100} -> bottom right corner
equal to: Chili.Window:New{right=100,bottom=100,height=100,width=100} -> bottom right corner

so there are:
1. right & bottom
2. negative numbers to `invert` the position
3. "30%" etc. for percentage positioning/sizing

[sunspot]

Well I did put the math statement kinda jokingly there , but never the less usefull info guys, I got it working about an hour ago. Still this might help other peeps as well.

The more you know and stuff

however I almost forgot to mention , there is one thing I don't get

Code: Select all

function widget:Initialize()
	CleanStockUi()
	local winSizeX, winSizeY, winPosX, winPosY = Spring.GetScreenGeometry()
	
	if (not WG.Chili) then
		widgetHandler:RemoveWidget()
		return
	end
	
	Chili      = WG.Chili
	Window     = Chili.Window
	Label      = Chili.Label

	local screen0 = Chili.Screen0
	helloWorldWindow = Window:New{
		x = '0',
		y = (winSizeY-65),	
		dockable = true,
		parent = screen0,
		caption = "my hello world window",
		clientWidth = 500,
		clientHeight = 40,
		backgroundColor = {0.8,0.8,0.8,0.9},
	}	
	
	helloWorldLabel = Label:New{
		x = '50%',
		y = '50%',
		width = 12,
		parent = helloWorldWindow,
		caption = "Hello world",
		fontsize = 13,
		textColor = {1,1,1,1},
		anchors = {left=true,bottom=false,right=false,top=false},
	}
end

My window should be 40 high, but to get it in the right position I had to add an offset of 25 , so Y became size of window Y - 65 instead of -40. Maybe the borders of the Window control of chili ?

[sunspot]

Well the first babysteps are completed. Based on a given json string , a Chili Window gets populated with buttons. It's a bit slow to my liking but maybe thats because of my approach to it.

Take following JSON

Code: Select all

local testjson_a = "{\"units\": [{\"unit\": \"unita\"},{\"unit\": \"unitb\"},{\"unit\": \"unita\"},{\"unit\": \"unitb\"},{\"unit\": \"unita\"},{\"unit\": \"unitb\"}]}"

basicly I parse this to a LUA table structure in a gadget which doesn't take to long, Then I take that table and loop over it and send messages to the widget. There the message gets processed and all buttons get put in a table there, then I use that table to draw the buttons.

Gadget important parts

Code: Select all

if (gadgetHandler:IsSyncedCode()) then
-- SYNCED
	function gadget:GamePreload()
		local message = ""
		local players = Spring.GetPlayerList()		
		for i=1, #players do
			local player = players[i]
			local playerInfo = playerInfoFetcher(player)
			debuglog(playerInfo)
			local units = getArmy(playerInfo)
			for i=1, #units do
				message = "ADDBUTTON-"..player.."-"..units[i]["unit"]
				debuglog("Sending msg " .. message)
				MessageDispatcher(message)
			end
			message = "ARMYSENDCOMPLETE-"..player
			debuglog("Sending msg " .. message)
			MessageDispatcher(message)
		end		
	end
else
-- UNSYNCED
end

Widget important parts

Code: Select all

function widget:RecvLuaMsg(msg, playerID)
	if (playerID ~= LOCALPLAYER) then return end
		
	debuglog("Recieved: " .. msg)
	local tokens = split(msg,"-");
	if (tokens[1] == "ADDBUTTON") then
		if (tonumber(tokens[2]) ~= LOCALPLAYER) then return end
		table.insert(unitButtons, tokens[3])		
	end
	
	if (tokens[1] == "ARMYSENDCOMPLETE") then
		if (tonumber(tokens[2]) ~= LOCALPLAYER) then return end
		updateRequired = true
	end	
end

function widget:DrawScreen()
    if updateRequired then
		debuglog("DrawScreen updating")
        updateRequired = false
		reloadWindows()
    end
end

Any comments on this approach ? Also if you want the entire scripts, that can be arranged :)

Next up, is getting the JSON by HTTP REST call. I first need to write the REST server though, thats not that hard I'll make it a quick DispatcherServlet in Java and get a tomcat running on my server at home. The I hope I can use LUA socket to make the call and recieve the JSON

[jK]

http://springrts.com/wiki/LuaTutorials: ... unications

LuaMessages are no solution! They get send over the internet!

trepan should have named them LuaNetMsg ...

[sunspot]

http://springrts.com/wiki/LuaTutorials: ... unications

LuaMessages are no solution! They get send over the internet!

trepan should have named them LuaNetMsg ...

ahaaaaaaaa ... I see, k lets read up and see if I can get this fixed how it should be. I hope that is the slowdown and it will speed things up

hmmm I don't get it straight away , that wiki is a mess of info hardly coherent. The best I can take away is from an example script there

gadgetHandler:AddSyncAction("LaserEvent", HandleLaserEvent)

do I need to create something like this in my gadget and a listener in my widget ???

I'm a java developer and in java it would be that I register a listener for a specific event on my widget class and then a gadget class would throw an event to that widget , and the widget would handle the code. Is it something likewise ????

[sunspot]

Lo peeps,

So I've been busy creating a REST interface, that I hopefully with LuaSocket can contact, to get a list of a collection of units a specific player has access to.

Then based on that list I'm building a Chili interface.

The basic concept would be to create a warhammer tabletop setting where you fight with a limited set of units , capturing points in a Tug Of War gametype, with on the end of the Tug line a HQ that can only be destroyed if you capture the entire Tug line. I'm playing with the idea of having multiple tug lines so you can attack from different locations.

I'm hoping to create an 8 v 8, 4 v 4 , 16 v 16 environment. I'm just not sure if the Spring engine would be able to handle that.

[hoijui]

i remember seeing a "DOTA" for spring game some months ago. that might be interesting to you.

[sunspot]

i remember seeing a "DOTA" for spring game some months ago. that might be interesting to you.

Damn , only now I can see the resemblance with a pure DOTA game. I was thinking to much like the metagame that Warhammer Online had where you had 3 zones and you had to capture keeps. But if you look back at that ... that is actually a DOTA game as well just with 100's of players ... well back then in the day 100's of players ...

[Anarchid]

i remember seeing a "DOTA" for spring game some months ago. that might be interesting to you.

Just might be ZKDota, you should be able to join it on hosts which have ZKDota in their name. Might require engine 91.

[sunspot]

well for now I'm going to hold off from the lua stuff for now. I believe this actually to be the most easy part of my project.

It seems the hardest part will be to write a lobby server that can give "currency" to winners of battles, keep track of hex ownership, actually create a hex based map that is clickable with commands to start battles on a hex. Couple specific maps to those hexes etc...

It's acutally a steep hill I'm looking at ... I'll start working in the weekend on maybe expanding on SpringLS lobby server

[knorke]

I'll start working in the weekend on maybe expanding on SpringLS lobby server

I think instead of modyfing lobby server better is to either a) make your own bot b) modify an autohost.
imo a) is best.
That way you (and players) can test it out on the normal lobby server.

[hoijui]

as said, ZK has all this stuff you want (a metagame), and they did not change the lobby server. i think they use it for all games, but they have this special campaign thing where they have a map of many planets, and each planet is a map, and there are multiple teams/factions playing to own the universe, and there is money and special stuff you can buy an what not.

[sunspot]

hmmm you both make a good point ofcourse. And know much more about it then me.

I'm just worried about making it a tad cheat free. How I'm thinking of designing it , is that with the currency you win of the matches you can buy booster packs (not with real money ofcourse just fake game currency, i'm in no way out for ANY monetairy gain, I earn more then plenty in my dayjob). Those booster packs will then contain random 3 units, that you then can use to create squads to play matches with.

But if there is a loophole where a guy could fake winning matches , he could get unlimited boosters instantly. That would well kill the gametype right then and there. So having the monetary gains limited in one place on "a server" in some kind of way where a "message" is send from within the gameengine to said server SEEMS the best approach. I thought to put that message reciever in the lobby server.

How would this work with a bot ? and will this be secure then ? Also ZK is programmed in python if i'm not mistaken, I'm not really familiar with that language, so it would take me a lot longer to assimilate that language in my skillset.

[CarRepairer]

No need for planetwars. Take a look at the awards gadget in ZK. When the game ends players win awards, which are sent by private message to the autohost Springie. Springie runs in .net and is written in c#. It ensures authenticity by comparing multiple messages from the players. Then awards are stored in the database and are viewed online in each player's profile page, as well as the hall of fame http://zero-k.info/Ladders (scroll down past the top 50).

[sunspot]

No need for planetwars. Take a look at the awards gadget in ZK. When the game ends players win awards, which are sent by private message to the autohost Springie. Springie runs in .net and is written in c#. It ensures authenticity by comparing multiple messages from the players. Then awards are stored in the database and are viewed online in each player's profile page, as well as the hall of fame http://zero-k.info/Ladders (scroll down past the top 50).

Nice I'll take a look at this over the weekend ... and here I vowed never to go in .net again ... my java hearth bleeds :) But maybe I can write a Java autohost ... well probably not , guy can dream though :)

[PicassoCT]

2 pages, no pictures, almost no code.. this gameidea is pimpossible