How about splitting the "model dataset" from the OpenRTS?

User Code & Projects OpenRTS
1

The dataset stuff is pretty cool. Also it solves some of the problems that RedMonkey is addressing. I’d like to use it for my FPS game. So: how about splitting the “model dataset” from the OpenRTS project?

The model builder and XML importer might become a library (or, if you prefer, a ‘platform’) that can be reused by other games.

Some parts are quite general (like SoundActor) some other are tied to OpenRTS (like DamageEffect); however other games can provide their implementation of *Effect that are game-specific.

What do you think?

2

All the parsing part is already quite generic and could easily be used by any other game with few efforts.

I’m talking about :

  • xml definitions
  • xm parser
  • library of definition (we have to extract an abstract class from this one)

For the builders it is more tricky. There is an abstract builder for the basic definition management, but the mapping is hardcoded, and the final build() method (and overloads) can have very specific behavior.

A first step would be to map the builder fields by reflexion. Not trivial ! :

  • a color will be parsed as three int and will need construction,
  • a child builder will appear as a string and will need to find the builder in the library by ID,
  • etc.

This is totally feasable, thougt. And then you only have to define the building behavior.

Would you like to do it? :wink:

3

Would like to at least try :smile:

4

I’ve decided that the less painful way is to make a branch and try to trim down the parts I won’t use. I can’t commit on the repo, should I fork it? Edit: now working on my fork.

Also: why ModelManager.updateConfigs() on the update thread? Aren’t XML supposed to be loaded at init time and then forgotten?

Edit 2: I have a trimmed openrts:core. Now I’d like to use it as a library from another project; how do I do that? I’m a gradle n00b :frowning:

5

No, xml are read every second and builders are updated. You can change your dataset at runtime :smile:

Me too ! Let’s summon the master @wuendsch ^^

6

there are two ways to add a lib with gradle. The first (and the preferred way) is to add a new dependency in the build.gradle. now gradle download it automatically from a maven repository.
the second way is to copy the jar into the lib directory and gradle graps it too.

7

This is interesting at development time, but I’m not sure it’s a good idea to ship a game with this behavior, so I’ll make an Appstate which offers both options.

The first way assumes that all the projects that uses the lib are built with gradle too :frowning:
Where is the jar? Edit: found it :smile:

8

EDIT: forget about it, now it works.

Ouch! Since I’m on 3.1, it looks like I’ll have to migrate the gradle project to 3.1 :sob:

@normen
I have this error at runtime:
Caused by: java.lang.ClassNotFoundException: com.jme3.network.AbstractMessage

That’s because the lib is compiled against jme3-networking-3.0.10.jar

The build.gradle has this:

dependencies {
compile fileTree(dir: ‘lib’, include: [‘*.jar’])

compile "com.jme3:jme3-core:$jmonkeyengine_version.+"
compile "com.jme3:jme3-effects:$jmonkeyengine_version.+"
compile "com.jme3:jme3-networking:$jmonkeyengine_version.+"

How should I modify it for making it work on 3.1?

@methusalah @wuendsch how about moving to 3.1 libs? A lot of bugs are fixed, there’s java8 support, plus all the new cool things. And besides, you’ll want to make the jump sooner or later…

9

Is it backward compatible?

10

The libraries have been reorganized (this is the reason of my error above); some methods are deprecated (probably for a good reason) and so on… therefore no, it’s not backward compatible. :frowning:

However, on my experience the transition has been rather simple and the benefits outweight the efforts.

11

3.0 and 3.1 both have AbstractMessage. So I’m not sure why you get the error.

12

@methusalah forget what I said, here’s proof that it’s backward compatible :stuck_out_tongue:

banana gradle monkey? banana banana banana!
Sorry, I’m resurrecting a 3.0 build of my game and de-redmonkey-izing it. It’s… bad :frowning:

13

Cool! On my fork I’ve decoupled the xml parsing from the game logic. This means that custom Builders and XML can be plugged in. Here is the trick;

    Map<String, Builder> typed = builders.get(def.getType());
    if (typed == null) {
                builders.put(def.getType(), new HashMap<String, Builder>());
                typed = builders.get(def.getType());
        //throw new RuntimeException("Type '" + def.getType() + "' is unknown.");
    }
            try {
                typed.put(def.getId(), (Builder) Class.forName(def.getType()).getDeclaredConstructor(new Class[]{Definition.class}).newInstance(def));
            } catch (Exception ex) {
                Logger.getLogger(BuilderManager.class.getName()).log(Level.SEVERE, null, ex);
            }

So that you can declare your custom XML with the Builder class:

<mypackage.MyBuilder id="MyID">
  <Type value="whathever"/>
  <Amount value="3.1"/>
  <Other value="please migrate!"/>
  <Monkey value="@normen!"/>
</mypackage.MyBuilder>
</catalog>```

And finally you create your mypackage.MyBuilder extends Builder
14

Wow! I’m having serious fun! :smile:

Now the loaded values can also be class enums!

typeT=(MyClass.MyEnum.valueOf(type));
15

I’ve tried back with 3.1. Now it works! I have no idea why… maybe some ‘clean’ task that I didn’t do in the first place?

16

JME 3.1 isn’t release in http://updates.jmonkeyengine.org/maven/com/jme3/jme3-core/ until now. So gradle cant find it. Perhaps someone may asks the JME-Guys when it will be released?

17

Master @normen, I summon thee!

18

Well I can tell his answer already:
When its done.

1 Like
19

@Empire_Phoenix and do you release any snapshot, beta or prerelease builds? So anyone can use and test it.

20

JME is on github, you can just clone it and compile it yourself with gradle.