Standalone Featureplacer - Page 5

Standalone Featureplacer

Tutorials & Resources For Mappers

Moderator: Moderators

User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14572
Joined: 17 Nov 2005, 02:43

Re: Standalone Featureplacer

Post by Forboding Angel » 03 Nov 2014, 00:15

FLOZi wrote: Can you address
Seems the current google code FP doesn't come with SpringFeatures as a dependency, which means if you download it via rapid it won't grab features, and even if you have it won't then use it -> only feature to select is the (broken) metal spot.
? Just a tweak of modinfo.lua
No, that would be stupid. Claim whatever feature package you like in your map as a dependency. It would be monumentally dumb to have to have spring features in order to use featureplacer.

Moreover, there are multiple versions of spring features, so calling it in featureplacer would be even more dumb. What if in your map you want to use 1.1 but fp is locked to 1.0?

What if you want to use your own features package? It is done the way it is for a lot of very good reasons. If knorke can't figure it out on his own, that's his problem. Perhaps he should make a map using fp rather than just talk about it.
0 x

User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6100
Joined: 29 Apr 2005, 01:14

Re: Standalone Featureplacer

Post by FLOZi » 03 Nov 2014, 03:04

It is me that is trying to use FP "to make a map rather than just talk about it", knorke has nothing to do with this request. And I am finding that getting it via rapid, as it stands currently, is a Very Bad Idea(TM).

If FP calls SF as a dependency that does NOT mean that the map will be required to use it! It just means that a newbie map maker, loading up FP for the first time is guaranteed to see a wide selection of features and to be able to use the software as intended. Right now if you load FP with a non-Spring Features map, you get precisely 1 (broken) feature in the panel!
0 x

gajop
Moderator
Posts: 3022
Joined: 05 Aug 2009, 20:42

Re: Standalone Featureplacer

Post by gajop » 03 Nov 2014, 03:10

FLOZi wrote: If FP calls SF as a dependency that does NOT mean that the map will be required to use it! It just means that a newbie map maker, loading up FP for the first time is guaranteed to see a wide selection of features and to be able to use the software as intended. Right now if you load FP with a non-Spring Features map, you get precisely 1 (broken) feature in the panel!
Agreed, sane defaults ftw. For the same reason SF are required by scenario editor.

But whats wrong with using rapid in general?
0 x

User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6100
Joined: 29 Apr 2005, 01:14

Re: Standalone Featureplacer

Post by FLOZi » 03 Nov 2014, 03:13

gajop wrote:But whats wrong with using rapid in general?
I was being a bit dense and coming at it from the gamedev perspective expecting it to be like ToolBox where you had to change the dependency of the game, didn't occur to me that you could just change the map dependency, so you need mymap.sdd, but don't need featureplacer.sdd. :oops: Well it is 2am.
0 x

User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14572
Joined: 17 Nov 2005, 02:43

Re: Standalone Featureplacer

Post by Forboding Angel » 03 Nov 2014, 04:58

FLOZi wrote:If FP calls SF as a dependency that does NOT mean that the map will be required to use it! It just means that a newbie map maker, loading up FP for the first time is guaranteed to see a wide selection of features and to be able to use the software as intended. Right now if you load FP with a non-Spring Features map, you get precisely 1 (broken) feature in the panel!
... no.

Git gud.

Edit: If FP calls it as a dependency, then that means you have a bunch of bullshit features to sort through if you are wanting to use your own set. Calling SF is a one liner in your mapinfo, but cleaner and better.

Feel free to improve the UI to show different features in different packages. Otherwise, it works as intended, and thanks to knorke, smoth doesn't really have any interest in fucking with it anymore, so thanks for that.

User was warned for this post. Felony 1.

People in glass houses, etc.

-- FLOZi
0 x

User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6100
Joined: 29 Apr 2005, 01:14

Re: Standalone Featureplacer

Post by FLOZi » 03 Nov 2014, 20:30

I agree that it would be better off on github (whoever thought I'd say that :oops: )

The problem you suggest wrt having many FP features available that you want to ignore is readily fixed by filtering - as you point out an improvement to the UI. I am thinking about FP as part of ToolBox and the dependency chain inherent there - as well as discussing with Smoth what improvements he made.


At the end of the day we all want the same thing - an effective tool. I am interested both in the short term of what is currently available and the longer term of what is possible. Please can we take the blame game elsewhere.
0 x

User avatar
smoth
Posts: 22295
Joined: 13 Jan 2005, 00:46

Re: Standalone Featureplacer

Post by smoth » 03 Nov 2014, 22:04

Forboding Angel wrote:thanks to knorke, smoth doesn't really have any interest in fucking with it anymore, so thanks for that.
To be fair, I don't like doing anything related to spring, I feel like he is playing some evil game of community whack a mole where if I show up and post something I will be immediately slammed for being somehow incompetent in his eyes or something.

I am not sure about FP. As we discussed the a while back forb, I can get in your git and update the features file and all of that. There are a few major changes I need to do to FP. One of them is to change the way rand rot, jitter and spread does. There are a few things planned, I will outline it for people to debate for a while:
  • 1: FP is going to become it's own dependency file. I am splitting it out of my RTSCore
    • 1a: FP will require a command utility dependency file that I am splitting out of my RTSCore
    • 1b: FP will require a specific version of CHILI it would be super helpful if chili was on rapid and chili had versions pushed to rapid over time. For all our sakes.
  • 2: FP_featureplacer.lua is confusing. I am going to change it to objectplacer.lua. Featureplacer since the begining was capable of more than just features but having them in gundam let me do stupid things like the tool and the actual placer having the same name leading to much confusion. In the future, my maps will include GBS_ObjectPlacer.lua. This will be my updated version from the feedback thread.
  • 3: if I start work on featureplacer again, I need to add a bunch of tags to features. i will be adding category, scale size and featureset.
    • 3ex:

      s44 sized winter pine tree:
      category: "vegitation, winter"
      set: "s44 flora"
      scale: "infantry game"

      gundam HLV:
      category: "structure, zeon"
      set: "gundam structures"
      scale: "standard"

this is my plan on how I intend on handling dependencies

GBS has been my codename for my core project, RTS core which included all my gundam functional code. I have been quietly upgrading it over time

the way it was:
Gundam
-split-
RTSCore
GBS_gundam

so now..
testgame
+ RTSCORE

in the future...

My game
+ RTSCORE
+ LUPS
+ CHILI
+ FeaturePack

RTSCORE (still contains my general game logic crap.
+ featureplacer(not split out yet)
+ CommandsUtilities(not split out yet)

The idea:
EVO(I have no control over this but feel this should happen...)
+ featureplacer(not split out yet)
+ LUPS
+ CHILI
+ CommandsUtilities(not split out yet)
+ FeaturePack

standalone FP mkII
+ featureplacer(not split out yet)
+ LUPS
+ CHILI
+ CommandsUtilities(not split out yet)
+ FeaturePack

+ = dependency

I need versions of LUPS and CHILI to eventually get on rapid though so I can use them as a proper dependency.

At the moment LUPS had some major issues though so until I get a relatively stable version, I need to wait on that dependency. I need time to test it and get bug squashed. For that JK will be needed and the man is pretty busy as it is. Also all the ZK unit stuff needs to be stripped out.
0 x

User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Standalone Featureplacer

Post by jK » 03 Nov 2014, 22:26

smoth wrote:I need versions of LUPS and CHILI to eventually get on rapid though so I can use them as a proper dependency.
They are since a few weeks. Sorry that I didn't wrote the forum thread yet.
0 x

User avatar
smoth
Posts: 22295
Joined: 13 Jan 2005, 00:46

Re: Standalone Featureplacer

Post by smoth » 03 Nov 2014, 22:29

<3 I love you man! VERY AWESOME!
0 x

gajop
Moderator
Posts: 3022
Joined: 05 Aug 2009, 20:42

Re: Standalone Featureplacer

Post by gajop » 04 Nov 2014, 07:10

Chili is the way the go, but is there any reason to continue developing FP if you switch to that?

Every contribution could just be sent to Scenario Editor which also has a Chili tool for feature editing, which I think is superior because:
It can add, move, rotate, delete, copy/cut/paste (multiple) features, as well as undo/redo any number of actions, and it also supports collaborative editing (multiplayer). It doesn't rely on having a special unit which "builds" features, but instead it's done just by selecting features from the GUI.

Alternatively feel free to take what you can from Scenario Editor, however note that taking the undo/redo mechanics would be a bit hard. Also the feature placer window code looks kinda ugly, as that's one of the first things I ever did in Spring, so it's to be expected. But still, it's out there if you need a reference.
0 x

User avatar
smoth
Posts: 22295
Joined: 13 Jan 2005, 00:46

Re: Standalone Featureplacer

Post by smoth » 04 Nov 2014, 09:44

I still need to grock the scenario editor. I would have no problem moving my fp code over to that project of yours. I just need to sit down and read through it so I can understand your stuff :).
0 x

gajop
Moderator
Posts: 3022
Joined: 05 Aug 2009, 20:42

Re: Standalone Featureplacer

Post by gajop » 04 Nov 2014, 15:56

Jools wrote: Also, maybe I'm wrong on the performance issues, but then that's hardly an issue for a a tool. I can't imagine a mapmaking tool maxing out the GPU.
mapmaking tool = tool for making maps
I made one, it's called the "Scenario Editor", and it has issues with GPU, mostly memory based ones (I hit GPU limits because I'm using uncompressed textures).
I haven't done automatic (height/slope-based?) terrain texturing, but I'm sure that's where the speed bottleneck would be.

Still, Chili really doesn't have such a great impact in any case. If it does produce a slowdown, it could be that a certain part that's being wrongly used and should be fixed - although I've never run into that direct issue.
0 x

User avatar
Silentwings
Moderator
Posts: 3579
Joined: 25 Oct 2008, 00:23

Re: Standalone Featureplacer

Post by Silentwings » 04 Nov 2014, 16:01

gajop wrote:(height/slope-based?) terrain texturing, but I'm sure that's where the speed bottleneck would be.
Definitely my bet too. Eg. My current heightmaps/textures for large maps typically take 20+ mins to build in World Machine on 8 threads.
0 x

User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6100
Joined: 29 Apr 2005, 01:14

Re: Standalone Featureplacer

Post by FLOZi » 06 Nov 2014, 19:39

Split the crap out. Please lets keep it focussed this time.

So as I see it we have:

1. 'Standalone' FP, which has its issues regarding implementation & some older code
2. Smoths refurb/rewrite - not sure how far that progressed?
3. gajops ScenEd feature placement tool - currently doesn't support FP-format placement if I am right?

I would like to see FP as part of a wider suite like ToolBox or ScenEd, and it makes sense to me for all map-editing tools to be in the latter.
0 x

User avatar
smoth
Posts: 22295
Joined: 13 Jan 2005, 00:46

Re: Standalone Featureplacer

Post by smoth » 07 Nov 2014, 12:18

yeah I think gaj and I touched on that earlier in the thread, I have no problem porting my code into scene ed. Honestly Gaj will probably end up refactoring it or just redoing it himself later. I am not sure if there is much of a point of me jumping in. HOWEVER, I do think that the idea of collaboration on somethings can produce better results so I am rather interested in playing with his sceneEd code. If it is possible, I think FP should be dissolved as a project and merged into sceneEd where possible.

My reasons for this are:
1) gaj is a dedicated developer and this is his pet project.
2) I feel gaj has a positive Open Source minded spirit and will keep his source out there. No throwing hissy fits and taking his tools with him.
3) I think that having tools that work in a similar fashion between one another is a good idea for most of our less technical people. Just because we had to understand it all doesn't mean our users should. Expecting people to learn 2 tool flows is folly.
4) Every time I work with someone I have a chance to learn a great deal and they may learn something from me. EVERYBODY WINS! YAY!

I just cannot fiddle with it right now as I am going to be away from spring busy for the next month.
0 x

Post Reply

Return to “Map Tutorials & Resources”