Page 3 of 5

Re: Standalone Featureplacer

Posted: 25 Jan 2013, 17:38
by knorke
Features are a small part of map archive filesize.
example:
http://springfiles.com/spring/spring-ma ... r-crossing
file size is 11,5 MB
Of that only 700 kb are features (3d objects and textures in packed form) so less than 10%
There is not much to save with a seperate features-archive especially since this is a small 8x8 map.

Re: Standalone Featureplacer

Posted: 25 Jan 2013, 18:26
by FLOZi
I'd weigh in with my opinion but I am not a mapper. 8)


(Never really seen the utility in an all-in-one dependency, sorry Forb)

Re: Standalone Featureplacer

Posted: 25 Jan 2013, 19:34
by jK
@knorke it simplifies the work and speeds up development a lot.
E.g. you just add the package to your dependencies and tada they are available in feature placer, w/o any featuredef, model, texture copying.
The easier the better.

PS: I would prefer if the feature package would be on github so anyone can contribute to new versions.

Re: Standalone Featureplacer

Posted: 25 Jan 2013, 20:20
by FLOZi
Having a feature package for use with feature placer (map development side) != maps depending on the same package once released?

Re: Standalone Featureplacer

Posted: 25 Jan 2013, 21:09
by smoth
Several of the gundam maps I copied over the feature files into them.. then ba people bawed so I stopped doing that.

It was a planned thing for feature placer to crap out all the required files as well but I never got to it.

Re: Standalone Featureplacer

Posted: 25 Jan 2013, 23:36
by Forboding Angel
jK wrote: PS: I would prefer if the feature package would be on github so anyone can contribute to new versions.
It's on google code. All I need is an email address to add you to the commit list.
knorke wrote:Features are a small part of map archive filesize.
example:
http://springfiles.com/spring/spring-ma ... r-crossing
file size is 11,5 MB
Of that only 700 kb are features (3d objects and textures in packed form) so less than 10%
There is not much to save with a seperate features-archive especially since this is a small 8x8 map.
1 dependency is much better than features in varying states spread across 100 different maps.

Re: Standalone Featureplacer

Posted: 26 Jan 2013, 00:05
by gajop
Imo, github and similar websites are better than google code, and not just because they use git.
It's really easy to fork your own version, do changes and commit them to your version. Only then will you send it back to the main repo with a pull request, when someone smarter will do a sanity check and decide what of what you just commited should really be included and in what form.

I'm already using git-svn with some svn repos, and I guess we can still hold some (personal) versions on github, even subversion does that! :). Hell I'm probably going to hold more and more of the unstable/unfinished stuff on github now that my PC has been giving me all these BSODs...

PS: enetheru: I've implemented that multiple feature select using rectangle select (in ToolBox), it's still largely untested and units and features can't be selected together yet (will need to make them share some code). (Also multiple feature rotation is kinda stupid atm).

PPS: Feel free to copy anything I created (scen_edit/ and the scenario editor's widget & gadget) from ToolBox into FP, assume it's PD licensed or w/e suits you.

Re: Standalone Featureplacer

Posted: 26 Jan 2013, 01:52
by Forboding Angel
Git on windows is synonymous with shit. And please don't mention pulling git with svn. It's possible, but it's ugly and it sucks pretty badly.

Re: Standalone Featureplacer

Posted: 26 Jan 2013, 02:03
by smoth
Forboding Angel wrote:Git on windows is synonymous with shit. And please don't mention pulling git with svn. It's possible, but it's ugly and it sucks pretty badly.
Tortoise git has much improved.

Re: Standalone Featureplacer

Posted: 07 Mar 2013, 01:30
by Funkencool
So I've been working on a few features for feature placer, including
metal spot placement both mod/map side,
some chili command/feature windows,
and gave the dump features its own button all for itself among some others changes.

Here's a terrible youtube video for example.
http://www.youtube.com/watch?v=tpsfeiFbkYk
still working out a few bugs but I'll probably start committing the less drastic - but useful - changes pretty soon if that's cool.

Re: Standalone Featureplacer

Posted: 07 Mar 2013, 01:39
by smoth
neat-o. Best of luck.

Re: Standalone Featureplacer

Posted: 07 Mar 2013, 22:18
by Funkencool
Thanks it seems to be coming along pretty nicely.

Re: Standalone Featureplacer

Posted: 08 Mar 2013, 00:54
by Forboding Angel
Hey, a word of caution... Commit early and commit often (but don't commit broken stuff please), otherwise you'll get stuck with merge conflicts that you'll have to sort out.

Looks pretty neat btw. I dislike the fact that the default tooltip is hidden though. That tooltip is pretty useful for mappers because you can get exact pixel location and height (useful for placing geovents and start locations), etc etc.

Re: Standalone Featureplacer

Posted: 08 Mar 2013, 01:04
by enetheru
Forboding Angel wrote:That tooltip is pretty useful for mappers because you can get exact pixel location and height (useful for placing geovents and start locations), etc etc.
WORD

Re: Standalone Featureplacer

Posted: 08 Mar 2013, 01:09
by Funkencool
Forboding Angel wrote:Hey, a word of caution... Commit early and commit often (but don't commit broken stuff please), otherwise you'll get stuck with merge conflicts that you'll have to sort out.

Looks pretty neat btw. I dislike the fact that the default tooltip is hidden though. That tooltip is pretty useful for mappers because you can get exact pixel location and height (useful for placing geovents and start locations), etc etc.
Yea, I just had the chili windows floating around didn't really have a set position for them, but I also plan on incorporating the cursor tooltip which should be helpful when picking features.
Does the command window really need any of the non feature placer commands? I'm cleaning that up right now and it occurred to me they're all pretty useless so I'll probably just filter them out.

To the committing, the only reason I haven't yet is its all a little messy and a lot of my features depend on each other. So, I just have to decide which ones should be committed first and iron them out. I am however keeping up with your updates.

Re: Standalone Featureplacer

Posted: 08 Mar 2013, 03:33
by Forboding Angel
Oh ok, good. That's more or less all I was worried about. The rapid tags are spring-features:test/stable and feature-placer:test/stable (respectively), and they are all set now.

Good deal, and nice work! :-)

Re: Standalone Featureplacer

Posted: 10 Mar 2013, 00:10
by Cheesecan

Code: Select all

function widget:GetInfo()
  return {
    name      = "Debug Mouse to Mexes Portable",
    desc      = "Click to make a mex table. Alt+M to toggle. Works with any game. Alt+C to draw boxes, Alt+X to increase box width, Alt+Z to decrease box width.",
    author    = "Google Frog",
    date      = "April 28, 2012",
    license   = "GNU GPL, v2 or later",
    layer     = 0,
    enabled   = false --  loaded by default?
  }
end

include("keysym.h.lua")

local floor = math.floor

------------------------------------------------
-- Variables
------------------------------------------------
local enabled = false
local spots = {}
local displayList 		= 0
local displayListBoxes 	= 0
local metalSpotWidth    = 64
local metalSpotHeight   = 64
local sel = metalSpotWidth/2
local drawBoxesOn = false
local boxWidth = 20

------------------------------------------------
-- Press Handling
------------------------------------------------

function widget:KeyPress(key, modifier, isRepeat)
	if modifier.alt then
		if key == KEYSYMS.M then
			if enabled then
				for i = 1, #spots do
					local spot = spots[i]
					Spring.Echo("{x = " .. floor(spot.x+0.5) .. ", z = " .. floor(spot.z+0.5) .. ", metal = false},")
				end
				--spots = {}
			end
			enabled = not enabled
		elseif key == KEYSYMS.C then
			drawBoxesOn = not drawBoxesOn
			Spring.Echo("Toggles drawing boxes on: " .. tostring(drawBoxesOn))
			displayListBoxes = gl.CreateList(drawBoxes)
		elseif key == KEYSYMS.X then
			boxWidth = boxWidth + 1
			Spring.Echo("Box width set to " .. boxWidth .. "%.")
			displayListBoxes = gl.CreateList(drawBoxes)
		elseif key == KEYSYMS.Z then
			boxWidth = boxWidth -1
			Spring.Echo("Box width set to " .. boxWidth .. "%.")
			displayListBoxes = gl.CreateList(drawBoxes)
		end		
	end
end

local function legalPos(pos)
	return pos and pos[1] > 0 and pos[3] > 0 and pos[1] < Game.mapSizeX and pos[3] < Game.mapSizeZ
end

function widget:MousePress(mx, my, button)
	if enabled and (not Spring.IsAboveMiniMap(mx, my)) then
		local _, pos = Spring.TraceScreenRay(mx, my, true)
		
		if legalPos(pos) == false then
			return
		end
		
		if button == 1 then
			spots[#spots+1] = {
				x = pos[1],
				z = pos[3],
			}
		elseif button == 3 then
			local selectionIndex = selected(pos[1], pos[3])
			if selectionIndex ~= nil then
				table.remove(spots, selectionIndex)
			end
		end	
			
		displayList = gl.CreateList(drawPatches)
	end
end

function selected(x, z)
	for i = 1, #spots do
		local minx = (spots[i].x - sel)
		local maxx = (spots[i].x + sel)
		local minz = (spots[i].z - sel)
		local maxz = (spots[i].z + sel)
	
		if x >= minx and x <= maxx then
			if z >= minz and z <= maxz  then
				return i
			end
		end
	end
	
	return nil
end

function drawPatches()
   local mSpots = spots

    gl.PolygonOffset(-25, -2)
    gl.Culling(GL.BACK)
    gl.DepthTest(true)
	gl.Texture("LuaUI/images/metal_spot.png" )
	gl.Color(1, 1, 1) -- fix color from other widgets
	
	for i = 1, #mSpots do
	  gl.DrawGroundQuad( mSpots[i].x - metalSpotWidth/2, mSpots[i].z - metalSpotHeight/2, mSpots[i].x + metalSpotWidth/2, mSpots[i].z + metalSpotHeight/2, false, 0, 0, 1, 1)
	end
   
    gl.Texture(false)
    gl.DepthTest(false)
    gl.Culling(false)
    gl.PolygonOffset(false)
end

function drawBoxes() 
	if(drawBoxesOn) then
		gl.PushMatrix()
   
   		local maxx = Game.mapX * 512
   		local maxy = Game.mapY * 512
   		local wx = maxx  * boxWidth/100
   		local wy = maxy  * boxWidth/100
   
		gl.Color(1, 0.33, 0, 0.2)
		
		-- left edge
		gl.DrawGroundQuad(0.0, 0.0, wx, maxx)
		
		-- right edge
		gl.DrawGroundQuad(maxx - wx, 0.0, maxx, maxy)
		
		gl.Color(0.33, 1.0, 0, 0.2)
		
		-- top edge
		gl.DrawGroundQuad(0, 0, maxx, wy)
		
		-- bottom edge
		gl.DrawGroundQuad(0, maxy - wy, maxx, maxy)
		
		gl.PopMatrix()
   end

end

function widget:DrawWorldPreUnit()
   gl.CallList(displayList)
   gl.CallList(displayListBoxes)

end
Updated with add/remove and drawing boxes for reference. I like to put it into spring widgets so I can run it with BA and check if ground is buildable, distance to llt, etc.

Re: Standalone Featureplacer

Posted: 10 Mar 2013, 00:23
by Forboding Angel
Google code is better.

The image isn't necessary and is completely superfluous. This widget that you quote is only used for sending a dump of marked locations to infolog which can then be used to mark lua mex spot locations. It does not lay textures for the mapper (other than the image being simply a visual representation - they will not show up in successive runs).

Re: Standalone Featureplacer

Posted: 10 Mar 2013, 00:45
by Cheesecan
Forboding Angel wrote:Google code is better.

The image isn't necessary and is completely superfluous. This widget that you quote is only used for sending a dump of marked locations to infolog which can then be used to mark lua mex spot locations. It does not lay textures for the mapper (other than the image being simply a visual representation - they will not show up in successive runs).
I like to get the best impression I can of how the final map will look. If you don't want to include it, that's fine. Just thought i'd share.

Re: Standalone Featureplacer

Posted: 10 Mar 2013, 05:31
by Forboding Angel
There are some patches I made that fit almost any map floating around this forum somewhere... I'll see if I can find them.