Standalone Featureplacer - Page 3

Standalone Featureplacer

Tutorials & Resources For Mappers

Moderator: Moderators

User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Standalone Featureplacer

Post 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.
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Standalone Featureplacer

Post 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)
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Standalone Featureplacer

Post 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.
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Standalone Featureplacer

Post by FLOZi »

Having a feature package for use with feature placer (map development side) != maps depending on the same package once released?
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Standalone Featureplacer

Post 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.
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: Standalone Featureplacer

Post 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.
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Standalone Featureplacer

Post 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.
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: Standalone Featureplacer

Post 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.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Standalone Featureplacer

Post 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.
User avatar
Funkencool
Posts: 542
Joined: 02 Dec 2011, 22:31

Re: Standalone Featureplacer

Post 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.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Standalone Featureplacer

Post by smoth »

neat-o. Best of luck.
User avatar
Funkencool
Posts: 542
Joined: 02 Dec 2011, 22:31

Re: Standalone Featureplacer

Post by Funkencool »

Thanks it seems to be coming along pretty nicely.
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: Standalone Featureplacer

Post 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.
User avatar
enetheru
Posts: 627
Joined: 11 Jun 2010, 07:32

Re: Standalone Featureplacer

Post 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
User avatar
Funkencool
Posts: 542
Joined: 02 Dec 2011, 22:31

Re: Standalone Featureplacer

Post 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.
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: Standalone Featureplacer

Post 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! :-)
User avatar
Cheesecan
Posts: 1571
Joined: 07 Feb 2005, 21:30

Re: Standalone Featureplacer

Post 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.
Last edited by Cheesecan on 10 Mar 2013, 01:55, edited 3 times in total.
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: Standalone Featureplacer

Post 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).
User avatar
Cheesecan
Posts: 1571
Joined: 07 Feb 2005, 21:30

Re: Standalone Featureplacer

Post 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.
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: Standalone Featureplacer

Post 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.
Post Reply

Return to “Map Tutorials & Resources”