The Star Wars: Imperial Winter Eyecandy Thread [56k warning]

[Warlord Zsinj]

Ok; but I'm still keen on seeing it as a symbol on the ground rather then a DoW style obelisk thing. But, you seem to have an idea in your head, so run with it.

[smoth]

no, that obelisk is part of the flag.

Something like this:



except in the center it is clear and it would be about 2X2. like someone put down a beacon there to take this point.

[AF]

If its a feature, aside from being able to apply lua sfx as smoths suggesting, you would also be able to use something like arghs world builder to add them to existing maps, it'd be much easier than having to compile them in and rebuild from scratch to move them around. It would also be much easier for AIs and lua scripts than metal deposits.

[Warlord Zsinj]

That would work, Smoth.

Artistically I am still inclined to abstract it from the gameworld as much as possible. The fact that it is an object sitting on the ground makes it immediately part of the universe, and players must assume it is there to be interacted with by things existing in the gameworld (units, whatever).

Do you have any ideas that would make the logo on the ground seem more like part of the player's HUD then part of the in-game universe?

For example, here is what our current beacons look like:
(They are animated to look like a holograph, which you can't really see here, and they always turn to face the camera)

EDIT: I should note that while I would prefer something more abstracted from the gameworld, what you are suggesting would be ok

[Warlord Zsinj]

Excuse the double post

AF, the worldbuilder would likely require us to repackage all the maps we want, correct? The problem with that is that it forces us to have to provide all the maps for our players. If we make sure our game works on most spring maps, then we provide our players with a huge variety of maps, and the ability to play on all newly released maps, without any effort on our part. It's a great part of spring, and we'd be foolish to place the requirement to play a map on it needing someone from the team to adjust it for SWS play.

What would be ideal, however, would be for there to be a widget that ran, detected where all the metal patches were on a map, and immediately spawned the features on the metal patches all over the map. I don't know if this is possible or not - but I seem to recall AI's being able to build metal mines in the correct locations, so it seems to me that there must be some way of accessing that information.
That would solve another gameplay problem we have - in that while ground troops are required to capture flags, we still have to have an awkward phase at the outset of a game where players have to build the flags on all the metal patches, and only afterwards can they be captured. So it becomes a huge clickfest for the first minute of the game so that you can get as many strategic points as you can as quickly as you can. Which is annoying.

Any ideas?

[smoth]

well lua can detect the metal patches. However, I have been told that that sort of thing could be rather expensive.

[Zpock]

Why when it only needs to be done once at the start?

[Warlord Zsinj]

Well, it would only need to run once at the outset of the game, after which everything would be spawned and existing in the game. Perhaps we could hijack the game with another false loading screen ("Please wait while your HUD jack is uploaded") made by a lua widget, and then only allow players control once everything has been spawned.

I wonder if that has the potential to cause desyncs in online games though, if there is a second loading procedure within the game after the two players have joined...

[AF]

Yes AIs do it by manually running the metal map through a set of algorithms. No such algorithm exists in lua as of yet.

Also you wouldnt have to redistribute the maps totally, just the 'mutators' containing the lua feature placement scripts.

[Warlord Zsinj]

But we'd have to do that for any existing map that we want to work with SWS, and would have to continue doing so for any newly released maps, correct? I think that would significantly increase the maintenance on keeping SWS up to date for our players.

It needs to be something inbuilt into the game that runs dynamically at the outset, irrespective of the map.

Also;

Yes AIs do it by manually running the metal map through a set of algorithms. No such algorithm exists in lua as of yet.

well lua can detect the metal patches.

[SinbadEV]

I think the World Builder was going to be able to included in the mod to change aspects of any map loaded by that mod.

[AF]

No metal patch detection script has been showcased on these forums, nor has anyone laid claim to haven written such a script as far as I am aware, nor is spring itself aware of the locations. Spring has no concept of a metal patch and sees it as an array of values, a metal field/distribution.

[Warlord Zsinj]

Smoth; can you rebutt AF, or is it impossible for lua to detect metal patches? (or anyone else who knows otherwise)

[Kloot]

Lua cannot directly access the metal-map the way AI's can,
but does let you read details about a given (x, y) coordinate
via GetGroundInfo() (which returns a bunch of variables that
include the amount of metal extractable from that spot, see
http://spring.clan-sy.com/wiki/Lua_Sync ... formations).

[Zpock]

Maybe the best idea is to ditch map compatibility and define your resource spots directly from LUA in SWTA only maps. Then you can make the resource system work exactly as you want it to and not what the archaic TA system lets you hack together. And then you wouldn't need to hesitate about scripting maps with LUA for all kinds of stuff like starwars NPCs since compatibility is alredy broken.

[SinbadEV]

Seriously you are not trying to place metal makers here so a quick poll of each x/y for the whole map, find the co-ordinates with the highest 10% of metal, place a beacon on the first one, and then place subsequent ones on the next one while ensuring that they aren't within a specific radius of each other... tadahh...

[Warlord Zsinj]

Kloot; so what you are saying is that we could make it so that where metal density is say, >1, place a neutral holobeacon at the outset of the game? Presumably we would have a system (which is already more or less in place) to ensure that any flag existing within x range of another flag kills the subsequent flag, so that we don't have high metal areas (say, the centre of Small Divide) covered with flags.
However, does this mean that we essentially have to scan every pixel of the map at the start of every game? Would that a) take too long, b) bring most computers to a crawl, potentially desyncing a multiplayer game, and/or c) mean that very large maps have players waiting for long times ?

In essence, how feasible is that option for creating a system where we can spawn neutral beacons over the entirety of the map, in roughly the correct metal locations?

Zpock: That option has certainly come up and been considered by the team. I am very against it, and will remain so for the foreseeable future. In my opinion, one of the most valuable features of spring is the fact that, in effect, we have 'outsourced' the whole map making procedure to a 3rd party (4th party?). We are able to produce content, release it, and have our players select from literally hundreds of excellent maps - that we had nothing to do with producing, but get to reap the rewards of.
I think that designing a mod that is unable to take advantage of this system is somewhat foolish. Certainly some mods have no choice (Final Frontier, Kernel Panic, etc), but atleast SWS is one that can work on pretty much most maps made by map makers. While it can be limiting in certain ways (specifically the current problem), I think it is our responsibility to ensure our mod is compatible with the majority of spring maps, rather then to make a handful of maps that are compatible with our mod. To do that puts great responsibility on our team to produce enough maps (of high enough quality) for players to have a wide variety of fun on, and requires us to continue to introduce new maps to avoid things getting stale. If we ensure that our mod is compatible with the general line of maps being produced, we don't have to do anything at all!

So, to my mind, it is very important that we work out a system whereby we can use almost any spring map and still utilise prespawned flags - otherwise our system itself has to be adjusted, rather then the maps.

[AF]

Seriously you are not trying to place metal makers here so a quick poll of each x/y for the whole map, find the co-ordinates with the highest 10% of metal, place a beacon on the first one, and then place subsequent ones on the next one while ensuring that they aren't within a specific radius of each other... tadahh...

If only it were that simple. That algorithm would spam holobeacons in the middle of small divide and nowhere else, and it falls on its face when presented with metal heck. Core prime industrial estate would have hundreds of beacons packed together into those 2 raised bits at the top and bottom and nothing anywhere else.

Your going to need to port krogothes metal patch finder algorithm from C++ to lua.

[Warlord Zsinj]

Seriously you are not trying to place metal makers here so a quick poll of each x/y for the whole map, find the co-ordinates with the highest 10% of metal, place a beacon on the first one, and then place subsequent ones on the next one while ensuring that they aren't within a specific radius of each other... tadahh...

Or

Presumably we would have a system (which is already more or less in place) to ensure that any flag existing within x range of another flag kills the subsequent flag, so that we don't have high metal areas (say, the centre of Small Divide) covered with flags.

I think physically one of those would be possible. Whether it is functionally succesful is another question (see questions I pose kloot in my previous post).

[AF]

The second solution would place a single or 3-4 flags at the centre of small divide