Author Topic: OP2 Scenario Project for C#  (Read 2369 times)

Offline TechCor

  • Newbie
  • *
  • Posts: 42
Re: OP2 Scenario Project for C#
« Reply #75 on: April 15, 2019, 02:48:18 AM »
Hmm. I went back and checked, and Tethys::GetRand works fine. Must have been really bad luck the handful of times I used it. Like flipping heads 15 times in a row... I have no idea.

Offline lordpalandus

  • Hero Member
  • *****
  • Posts: 758
Re: OP2 Scenario Project for C#
« Reply #76 on: April 15, 2019, 10:58:16 AM »
I use random number generation a lot in the video game I'm making, so some possible reasons it is returning 0:

1. You improperly set up the array / vector, so it is using an empty array/vector. Random number of 0 between the size of the array/vector would be 0, so it will always return 0.

2. It is choosing a random number as a float, and converted into an int. If the random number was 0.9, in floats that is nearly 1, but when converted to int it becomes 0. Some round up, some round down.

3. Some random number generators, like the one I use, utilizes different streams. If your random number generator requires a specific stream, that could be the issue.

Otherwise:

We will need to see what code you are trying to execute to provide more detailed assistance. Just because there is no syntax error, doesn't mean there isn't some unintentional logic error. Without the code in question, it is really hard to say.
Currently working on Cataclysm of Chaos, Remade.
Link to OPU page = http://forum.outpost2.net/index.php/topic,6073.0.html

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2183
    • LairWorks Entertainment
Re: OP2 Scenario Project for C#
« Reply #77 on: April 17, 2019, 09:38:41 PM »
Gonna go out on a limb and assume the core code is just using a really shit PRNG. Haven't looked too far into it but I'd suggest using literally any other PRNG than whatever OP2's engine provides (unless for some reason mission DLL's must use that function as Hooman has suggested).
« Last Edit: April 17, 2019, 09:40:27 PM by leeor_net »

Offline TechCor

  • Newbie
  • *
  • Posts: 42
Re: OP2 Scenario Project for C#
« Reply #78 on: April 19, 2019, 01:11:28 AM »
Again, I don't know what happened. It's possible I coincidentally fixed some code the same time I swapped it out for C# Random. Tethys rand appears to be working, so I will leave it as is. It's easy enough to change the wrapper function to C# random later if needed.

---

I have need of accessing a lab's data for labor reassignment. Unfortunately, it appears that the lab variable addresses overlap the "bayItem" array, which are represented by different sizes. It's not simply a variable naming issue.

I assume then, that I need to put a union in here to make this work. Rather than hack a union in at that spot, what address marks the end of the base class and the beginning of each sub type?

Or am I approaching this entirely wrong?

--It just occurred to me while posting in another thread that instead of a union, I could create a separate struct and offset the address similar to how BeaconData is done. I will give this a shot.
« Last Edit: April 19, 2019, 01:36:10 AM by TechCor »

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4751
Re: OP2 Scenario Project for C#
« Reply #79 on: April 19, 2019, 01:37:14 AM »
Correct about the union. Each unit type may have it's own specific unit related fields. That will make the non-common fields appear to overlap in memory, reusing the same offsets.

We don't have clear picture of the entire unit hierarchy, or how big each unit record is. We know a handful of them, and have some general sense of parts of the unit hierarchy, just not the full info. This is one of our long standing ToDo items.

In SVN: OllyDbg/InternalData/DataStructure Unit.txt, you can find many pieces of known memory layouts. Where base classes and hierarchy relationship are known, they are marked. Where the constructor sets a different set of flags (offset 0x44), they are marked. The meaning of flags may be dependent on unit type, and isn't fully detailed or separated out by unit type, though many details are known. Similarly which offsets and fields belong to which unit types or base types isn't fully worked out. The hierarchy has multiple levels, and is a bit lopsided, so there are many sizes and offsets involved in the unit structure breakdown. Many details are known about what values can be found at what offsets. It's the breakdown of those fields and offsets into unit types and base types that is lacking.

Offline TechCor

  • Newbie
  • *
  • Posts: 42
Re: OP2 Scenario Project for C#
« Reply #80 on: April 24, 2019, 01:29:28 AM »
I ended up going with a LabData struct with a direct pointer to the first variable's address.


Base, Labor and Research management are all at a nice first draft. Currently going through now and fixing bugs and adding extras such as DIRT, geocon, and magma well handling. Then I'll move onto task priorities, customization and finally combat management.

Looking forward to doing real world tests in the next month or so.

---
I really want to get this unit stuck bug fixed, so I no longer need to "help" the AI occasionally.

I'm thinking the best way is to find out where the unit is trying to move. If I knew that, I could check if it is occupied. Is there a way to get the adjacent tile that the unit is trying to move into? This would be different from its final destination. Then I could check if there is something in the way, and how to handle it.

The other "stuck" situation seems to be due to a bug in "UnloadCargo". 1 in 50 times, UnloadCargo will fail to trigger, and can't even be triggered manually in the agridome or smelter pane despite *not* being grayed out. I can't seem to figure out the pattern, but I've yet to see it happen while only a single cargo truck is trying to dock at the same port, making me think it happens when another truck is trying to push the one on the dock off. The truck on the dock reports "moDone", but building.UnloadCargo() is ignored. This bug is only an issue for Land Rush type games where you need to unload food and metals. Ore doesn't require UnloadCargo(), and therefore the bug never happens there.

Offline Crow!

  • Jr. Member
  • **
  • Posts: 69
Re: OP2 Scenario Project for C#
« Reply #81 on: April 24, 2019, 06:45:47 AM »
I've had the inability to unload cargo in the normal game from time to time.  The best way to fix it I've found is to order the truck to move onto the dock again, even if it's already on it.
Speedruns, my FFIV game randomizer, and more can be found at my twitch page:
https://twitch.tv/iicrowii

Offline TechCor

  • Newbie
  • *
  • Posts: 42
Re: OP2 Scenario Project for C#
« Reply #82 on: April 24, 2019, 03:44:05 PM »
Yes, it seems issuing any command to the truck will resolve it. The issue is detecting that the problem is happening in the first place.

I'm thinking maybe adding a timer linked to the unit index to determine if they have been on the dock idling too long. Maybe a tenth of a second with "moDone" is all that is needed to determine that it's "gone bad". Not as elegant of a solution as I was hoping for, but any fix is better than no fix.

This solution might work for the movement problem as well, if pixelX/pixelY is a reliable way of telling if a unit is moving.

EDIT:

Checking for "spinning wheels" and waiting 200 ticks before issuing a stop command seems to work. Wish this kind of handling was built into the engine, but whatever.
« Last Edit: April 24, 2019, 07:43:13 PM by TechCor »