Spring RTS Engine

just adding an alpha channel doesn't solve your issue.

Ok, I'mma share my super secret trick into fooling plasmaserver and the mission editor and zklobby.


I add an smd to all of my maps that contains this: I notice that you caught on to that ;p

However, plasmaserver rarely picks up my maps from springfiles (plasmaserver really does suck giant cock), so what you have to do, is open up zklobby so that zklobby will register your map and upload it to plasmaserver (you need to go into settings and turn on the debugger window so that you can monitor what it says about your map). It's stupid and fucking retarded, but that's the way it is.

Unfortunately, Licho hasn't taught plasmaserver to read mapinfo.lua yet, which is pretty sad considering that mapinfo has been around for over a year. By tricking it with the smd, apparently it doesn't know that it's actually reading mapinfo instead of an smd file.

Crude, but effective.

smoth wrote:just adding an alpha channel doesn't solve your issue.

I'm pretty sure that at this point, he understands that.

I feel I've done my best so I'm quite pleased with the result: V3 link

For those of you interested, this map showcases dynamic lua metal spots. Combine with this to make the metal.lua file. I previously removed this widget from springfiles because older versions were broken and would draw in the air.

I also wrote a start positions generator widget (included inside), but it's disabled because of some dependency issues when loading mapinfo.lua. Worked pretty well though, if that issue can be solved. It triangulates positions so you get 3 mex per player (adjustable). Interesting future work in that area could be to support adjacent placement of allies in 'team ffa' e.g. 2v2v2 - players really want. Would be best to have in modoptions(team ffa mode) for BA(maybe ZK has it?).

I updated my start position java tool as well, it now spits lua positions to the clipboard. But since I was met with scorn last time I posted it, I won't do so again.

What else? I think map making has become very tedious. The tools are better, and there's more potential but I can see how a lot of people would give up. I don't think I would have bothered to get into mapping today if I had not started before ssmf came along.

This is why I think spring needs a new mapping tool (lua map editor like what gajop is working on) with support for every facet of mapping: heightmap, ssmf library, feature placer, mapinfo, metal map, etc plus packaging. Might be a good way to attract content makers. It should also meet the stylistic requirements that artsy types have, so no circas 1996 GUIs with hotkeys found in readme.

I also think BA should include springfeatures. BA players run SL and tasclient so they won't autodownload map dependencies. Manual dl is not an option for the masses. Having to extract every feature I used was a pita, which among other things included making a pivot table in excel to sort out unique feature defs in the dumpfile from featureplacer.

All BA would need to do is add a dependency for Spring Features 1.0 in modinfo. It would solve a lot of problems.

Haven't tested the map yet. Will soon

dynamic lua metal spots

As in mobile?

As in mobile?

vrooooooommm

Anarchid wrote:

dynamic lua metal spots

As in mobile?

They are defined in lua so you could in fact have them move around during play by editing dynamic_metal.lua.

To test it you will need:
- mapconfig/metal.lua - containing absolute coordinates of each metal spot
- LuaGaia/Gadgets/dynamic_metal.lua - sets the metal extraction
- LuaUI/Widgets/LuaMetalSpots-v4_1.lua - displays metal spot textures*

The easiest way to generate metal.lua is to use the modified featureplacer that I posted here.
* Note: This widget creates a static display list, so moving metal spots would require the display list to be refreshed.

I also made a new version of the dynamic start positions which will output a file named teams.lua to your spring folder when enabled (there is no need to place them yourself). Then you just paste it into the mapinfo.lua and voila you have start positions with even less effort than the metal spots -- it works by identifying areas containing three metal spots in close enough proximity that a player could start there. PM if you want it, it's too long to post here and the widget itself won't be included in any map.

All BA would need to do is add a dependency for Spring Features 1.0 in modinfo. It would solve a lot of problems.

Sorry, this won't happen. It's a big file, a hefty request on new players to download this before trying BA (probably with a map that doesn't even need it), and existing BA players don't need it.

Package features inside your maps imo, thats best because most maps are downloaded via rapid these days, where its better to download things in small filesizes and often, even if that leads to a low percentage of duplication. The amount of filesize you'll end up duplicating is not large - at a guess you'll need to make make ~30 maps with some common features before the amount of bytes you've duplicated is equal in size to a one off download of Spring Features. At worst make Spring Features a dependency of the map.

On another note - me and Abma tried this map when we were testing Spring versions. It's very pretty but in places it was hard to see through the fog, and that's frustrating when you're fighting. It would make for interesting team play imo.

Spring features is an easy way for map makers to include features on maps. Though, it would probably be best to have all the features in spring features included in Feature Placer, for instance; then implement a way to automatically unload all the used features into the map.sdd.

That would alleviate the need for players to have the springfeatures archive, and still be easy for mappers. It would also allow mappers to customize the features specifically for that map (which you can't do if they're archived).

Silentwings wrote: On another note - me and Abma tried this map when we were testing Spring versions. It's very pretty but in places it was hard to see through the fog, and that's frustrating when you're fighting. It would make for interesting team play imo.

Thanks! May I ask which version did you try? There's two kinds of fog on this map - "old" fog that is only visible when viewing the map at a distance when zoomed out. It just adds some red luminous glow that is fairly non-disturbing.

The second type of fog is the one you enable through mapoptions. This fog is intended for use with the inverted heightmap mode only - I wouldn't recommend it otherwise. In V3 it is now disabled by default for this reason.

The only real problem with distributing features in each map is that adding them in can be quite tedious when you have used a lot of features.

Cheesecan wrote: The only real problem with distributing features in each map is that adding them in can be quite tedious when you have used a lot of features.

Unless I, or someone else, wrote a gadget for FP to automagically do the tedious work..

Spring features is an easy way for map makers to include features on maps. Though, it would probably be best to have all the features in spring features included in Feature Placer, for instance; then implement a way to automatically unload all the used features into the map.sdd.

+1, I would use this if it existed.

Thanks! May I ask which version did you try?

I'm afraid I can't remember; the water was in the same place as it is on the picture at the start of this thread, which is v1, so I assume that whatever we played was without the heightmap inverted. The fog was almost everywhere, I think it was visible at all zooms, it was grey in colour, and was very thick over the water.

Just played this map for the 1st time, and I really liked it. Was some fiddling with the boxes. I can imagine lots of different games and start positions on this map. Very nice!!