Acissathar

That was it, thank you so much!

Vlastan

@gamingislove I'm recreating my game setup in ORK3, here are some issues i have:

In Ork2 i defined some nested input keys to handle camera rotation with both mouse movement and gamepad right stick, in the case of mouse i also wanted to enable rotation when mouse right click is held down.

I recreated the exact setup in Ork3 but it does not work anymore. Here's a screen of the input keys:
https://dropbox.com/s/09ts1ebd4v5bw4e/Input.jpg?dl=0

It seems that the input values get lost after the second InputKey level. I tried removing the right click key and leaving only Mouse X at the second InputKey combination to see if it worked but it made no effect. Mouse X axis works if used alone in the View_Horizontal input key.

Second issue is that collision camera does not seem to work. I have it setup similar to my Ork2 project where it used to work.

gamingislove

I'll check it out.

Edit: Collision camera working fine here - make sure to use the correct layer setup.

The input key is an issue with the order of the keys, I'll fix that in the next update. However, you can already get the right click + move in a single input key. The Mouse input origin gets input from mouse buttons and axis input from mouse movement (Mouse Axis settings). Using the Hold input handling will only use the key while holding down the mouse button.

Acissathar

I believe there might be a bug with combatant spawners, and that it gives a null reference error:


Spawner Settings:



If I change CheckDifficulty to IsEqual and None, it no longer gives the error but does not spawn the combatant (even with 100% chance). If I change it from None to Default, it gives the null reference again and same with setting any of the other requirements.

Granted it's a dll so I'm just guessing, but since it goes away with setting check difficulty to None but appears for everything else I think that is what is related to. Or maybe I'm just missing something again :)

Happens with Single and Combatant Groups (thought it might be related to follow leader maybe) it seems.

Vlastan

@gamingislove Here's a screen of the camera collision component and the way collision layers are setup. The project is in hdrp, but i don't think it should make any difference.
https://dropbox.com/s/xrh4lna7vonr33g/CameraCollision.jpg?dl=0

In regards of the new UI, are the animation options on Gui box open/close that were available in Ork2 be ported over to the new system?

gamingislove

@Acissathar
I think this is due to no player being added yet - I assume this happens when you directly start in a scene?

@Vlastan
Well, are the things in your scene that should cause the camera to move also on those layers?
Also, which camera control are you using? One of ORK's built-in or a custom control (or schematics)?

The open/close animations from GUI boxes are not available 1:1 in ORK 3 (or rather, Makinom 2). Due to the completely new UI system, this now depends on the used UI module - currently only the Unity UI being available, this is handled by the Open State Change and Close State Change settings of the UI Box, HUD and UI Background (e.g. for menu screen backgrounds) components.
You'll handle this with regular animations, both legacy and Mecanim animations are supported. E.g. fading in/out can be handled via a Canvas Group component, changing it's Alpha value.

Acissathar

@gamingislove Correct, right as the scene loads up.

Edit: Changing it to wait a few seconds after Level Loaded rather than auto start solves the issue and things are spawning :)

gamingislove

Alright, started writing some basic documentation for ORK 3. For now just a few things for getting started, an overview over the different editor sections and informations on using the new UI system.

I'll mainly focus on the UI system documentation (especially HUDs) for now, as that's what is fundamentally different than it was in ORK 3, so there's a lot to unpack :)


@Acissathar
Will be fixed in the next beta, for now just use the workaround :)

Acissathar

@gamingislove Will do!

Two more quick questions, relating to HUDs this time. For this part we want to set some elements to show the Time, Area, and Currency. Looking at all of the options for a HUD Text Content, I'm not seeing any that allow for any of those values to be displayed. Everything in the text seems to be "combatant" specific and nothing to grab Player info, how would we go about setting that up?

Sort of related, when we have multiple combatants, how do we let the system know that this set of content goes to Combatant A while this set goes to Combatant B? I have the battle hud working for a single player combatant, so might be getting ahead of myself, but was wondering about that one as well.

gamingislove

@Acissathar
Like in ORK 2, that's just handled by regular text codes. The texts usually only have their special (local) text codes printend above them. You can still use any other text code in the text like in ORK 2 - you have access to them via the text editor (when clicking on More to show more options).

E.g. prints the current game time and the name of the current area.

As for multiple combatants, that, too, is handled just like in ORK 2. I.e. your HUD/menu setup just defines the content you want to display, ORK will handle the combatants. E.g. the Combatant menu part displaying the group would add one button per combatant (with the HUD as template or HUD content directly on the button). For the regular HUDs, that'll also be displayed like in ORK 2, i.e. if you set it up to show the player's battle group, it'll create one HUD per combatant.

Acissathar

You can still use any other text code in the text like in ORK 2 - you have access to them via the text editor (when clicking on More to show more options).

That makes a lot more sense, I was under the impression those listed codes were only what could display and pull info in the boxes, but knowing that just means they have special context clears it up.

For the regular HUDs, that'll also be displayed like in ORK 2, i.e. if you set it up to show the player's battle group, it'll create one HUD per combatant.

Okay so I was approaching this wrong, the HUD should be designed as per a combatant and not as one larger group piece that needs info.

I haven't touched my ORK2 project in quite a while if I'm honest (life always gets in the way it seems) so I thought I'd help provide a "clearly has no clue what is going on" perspective to the beta test :)

gamingislove

Acissathar said: Okay so I was approaching this wrong, the HUD should be designed as per a combatant and not as one larger group piece that needs info.

Exactly - since you never know which combatants (or even which number of combatants) will be displayed by it, things are set up with a single 'entity' in mind, and it'll be used/created for each individual.

huulong

For people struggling with NullReferenceException in GamingIsLove.ORKFramework.GameHandler.get_DeltaBattleTime () on start: just open the Makinom window and Save Settings even if you didn't change anything, just to generate the default ORK assets. That will fix the error.

Of course, if you start working on any data for your game you'll have to do that anyway. But just for people like me who like to press Play just after importing the package and adding a Starter object, to make sure that the empty scene runs without errors...

UPDATE: oops, I didn't notice there was a second page on this thread, and I've started reading the new doc for ORK 3. It looks nice! It also explained the importance of the initial save on http://orkframework.com/guide/documentation/getting-started/first-steps/... So my case is covered.

huulong

I noticed a new setting in Base/Control > Game Controls > Player Settings > Prefab Settings where ORK 2 has no Player Settings at all.

I tried to set a prefab, but the party's 1st Combatant's prefab takes over, unless the party is empty, in which case I get a warning on SpawnPlayer: "Set a player before spawning it!" and then it falls back to the Player prefab in the new setting indeed. But I cannot control this one so it must not be bound properly.

Maybe that new setting is meant for generic Makinom games, and was kept when extending it with ORK 3? Does it still make sense in ORK 3?

That said, with the original system you could only define the same character prefab for map/city navigation and battles. This means that if you want to use different models, you have to make your own events to spawn another prefab (which may not inherit from ORK Player control and may need custom scripts) or to change the appearance of the combatant (which may not be fitting if the changes are too heavy).

In this case, having a separate Player prefab for control on the map may be appropriate.

While this is not an issue in 3D games reusing the same character (except old games like FF7), some 2D games use more detailed, side-view sprites for character during battle. To cover that, we'd actually need to be able to customize "map exploration" prefabs for every party character, not just set a single Player Prefab; unless we just swap models. But that's another issue. Maybe that Player Prefab thing was just a leftover in this case.

Vlastan

gamingislove said: Well, are the things in your scene that should cause the camera to move also on those layers?
Also, which camera control are you using? One of ORK's built-in or a custom control (or schematics)?

I use the built in top down camera from ork and of course colliding scene elements are properly set to each layer. I currently have two branched projects, one in bult in rendering and the latest in hdrp. Camera collision does not work in my hdrp project even with the same ork2 project, so could it be related to the changes in the rendering pipeline ?
Very strange though