HoI2 Patch Project

[rich-love]

Hmmm...... Paradox has not responded in 2 swedish working days whether I can forward the contract. I don´t think they will have anything against it, but you known I really don´t want to do anything yo jepordise the project. But on the other hand, I would like you to read it and keep the project going. Suggestions?

I'd wait until Paradox gets back to you. The contract won't tell us THAT much (I guess); and what we really want is source code.

 

[MartinBG]

There are enough bugs into Arma 1.2 cumulative bug list to start with - some of them seems to be easy to fix and others - not. I agree that we should start with fixing the easiest/cosmetic bugs first and then move to the rest.
IMO we should (at least try to) fix everything we can that doesn't work as designed into the code even if there are some kind of workarounds available.

I'd wait until Paradox gets back to you. The contract won't tell us THAT much (I guess); and what we really want is source code.

I totally agree with rich-love on this.

 

[coreymas]

I can wait as well....

Weekends are when i would do alot of my coding ... and since this weekend is upon us already I think i could wait another week.

Just as a precursor my information about the code is that it in Visual C++ 6.0 format... So guys dig out your Visual Studio 6.0 CD's...

Corey

 

[IndoEsia45]

Can it work with VS2008 ?

 

[Gormadoc]

We should fix the bug by code. If only to allow modders to actually use the paratrooper eff. to a higher degree.

I agree to suing the cbl, but with actually reconsider every point. 32 and 33 for instance are not bugs.

Germadoc:
I figure we can use all things that are not workarounds. So if you can provide a package of all typo fixes and stuff, that would be useful i guess.

I would suggets that you fix the code and not use workarounds in database files, if it can be avoided. Having a -50% modifier as result of researching a new tech is kind of weird even that it works.

I could easily make a package where workarounds and other similar things are removed. Things also to be considered removed are some of the province renamings, ID cleanups and file renaming, some inc files is named wrong, AUT instead of correct tag AUS, which not really do anything.

Some other issues you might want to look at:
Rename one of the two Georgia areas, one in USA and one in soviet. It still messes up airbombing targetting where ones bombers try to bomb in USA when one really orders an attack on the soviet area. It must be done in the exe. Renaming the area in the config files are not enough.

AI convoy routing is not working, you can literally bomb UK convoys to death from Nat. Spain, the AI will not reroute them further out into the Atlantic regardless of how many losses it takes. I think it was originally intended that the AI would shift routes when losses occur, but i dont think it takes air convoy raiding losses into consideration only losses from ship/sub raiding.

A more complicated thing would be to get the internal clock to work correctly after saving and reload. As it is now the internal clock are set to 00.00 on reload regardless of what time you save. So if you save at say 15.00 gametime, when you reload, the game time will still be 15.00. But the internal clock will be 00.00 so from now on, all events that triggers usually at 00.00 will trigger at 15.00 for some time. not sure if it get realligned end of year or end of month. I also suspect other things the AI usually does at 00.00 will be done at 15.00.

That little glitch above makes the usage of the "Hour" trigger in events completely useless. But if the internal time always followed game time we could use the hour trigger in event chains and be sure that the events where checked in the correct sequence.

other event commands that would be nice to have working.
difficulty = x ; currently it only works to se if the difficulty is 0 or 4.
under_attack = [tag] ; returns true if country is at war and not only if the country is the defender.
wakeleader ; no explanation is needed i gues.
delete_unit ; only works for landunits not for air or naval.
intel_diff = x ; currently does not checks home country vs target country, but home country vs target country + any country allied with target country.
The well know bug with USA having good intell_diff against manchuko, so they are able to kill Yamamoto. (I know the event is disabled, but never the less would be nice to have the command working)

Inc files commands:
dormant_teams; is used to sleep techteams example where this would be usefull are the soviet teams sleept in purges. They are not sleept in later campaigns because the dormant teams command does not work.
province_revoltrisk = X; this iam not 100% sure of yet, but i have seen strong indications of that this command are reversed So "province_revoltrisk = 10" Does not increase base revolt risk in a province but instead decreases it by 10. Dont know if this is also the case with the event command aswell but probably is.

This next one is perhaps not a bug, but just a silly possibility.
But strat-tac & nav bombers with escorts attached can be set to air superiority mission. Would make sense to disable that mission interily, escorts attached or not. Most likely a thing overlooked when making escorts brigades instead of units.

The AI uses subs to shore bombard quite often on empty provinces. This has perhaps been remedied in arma 1.2 where subs no longer can see into land provinces.

hmm will shut up for now

 

[coreymas]

Can it work with VS2008 ?

I would say maybe -- with alot of tweaking etc.

Let's not complicate our lives by trying to port code over to a newer version..

Besides everyone knows that Visual C++ 6.0 is practically free... and if you need it and can't get it I can find a way to get it to you.

Corey

 

[Ghost_dk]

just wanted to add that if paradox does not open a seperate mantis project for you guys I can set one up on the mantis.terranova.dk server to any category etc. specification you would like.

 

[De_Genius]

I would say maybe -- with alot of tweaking etc.

Let's not complicate our lives by trying to port code over to a newer version..

Besides everyone knows that Visual C++ 6.0 is practically free... and if you need it and can't get it I can find a way to get it to you.

Corey

nice to know. I only have access to VC2008 so this might come in handy.

 

[unmerged(76495)]

A more complicated thing would be to get the internal clock to work correctly after saving and reload. As it is now the internal clock are set to 00.00 on reload regardless of what time you save. So if you save at say 15.00 gametime, when you reload, the game time will still be 15.00. But the internal clock will be 00.00 so from now on, all events that triggers usually at 00.00 will trigger at 15.00 for some time. not sure if it get realligned end of year or end of month. I also suspect other things the AI usually does at 00.00 will be done at 15.00.

Wouldn´t something like this reduce performence quite a bit? I mean, events are currently checked once a day. If they had to be checked 24 times a day, then that would be a bit heavy strain on performence espacially for event-heavy mods?

Which leads me nicely to my next point. Performence enhancement regarding events. Currently every single event is checked for being true at the start of the day, this is in my honest opinion a needless drain on memory. Why should the CPU check for whether FDR is going to die in 36? Instead, the event list the CPU checks every day should only contain events that could potentially fire. Meaning either events with no timeframe, or events with timeframes that fit the current year. The list (or some other form of storage) would be updated every Jan 1 or upon loading the game. Should espacially be beneficial to players using event heavy mods.

And on a more serious note, I want to change the audio side of the game so that it can only run falalal

 

[Dakk]

Which leads me nicely to my next point. Performence enhancement regarding events. Currently every single event is checked for being true at the start of the day, this is in my honest opinion a needless drain on memory. Why should the CPU check for whether FDR is going to die in 36? Instead, the event list the CPU checks every day should only contain events that could potentially fire.

Hear hear!
I've thought about that too, it's always struck me as wasted CPU-cykles checking for every event every day year after year...

And on a more serious note, I want to change the audio side of the game so that it can only run falalal

Excellent.

 

[IndoEsia45]

Is that like MTTH(Mean time) system in EU3 ?

What about ghostfleet problem ?

 

[unmerged(76495)]

Is that like MTTH(Mean time) system in EU3 ?

No, its far more simplistic. The following is an extract from the german event, fall weseruberung.

trigger = {
                [....]
		random = 10            
                [....]
	}

        date = { day = 0 month = march year = 1940 }
        offset = 2
	deathdate = { day = 29 month = may year = 1943 }

It will check if the conditions are met on 1 march 1940. If they all are, including the random trigger which in this case is only true 1/10 then the event will happen. If not then the CPU will check for it being true again every 2 days (the offset), it will only stop checking once the event fires (since its a non-repetitative event), another event causes it to sleep or it expires. Which in this case it does on 30 may 1943.

What about ghostfleet problem ?

This is IMO one of the biggest bugs remaining, but everybody was aware of it before the 1.2 patch. Yet paradox failed to fix it. To me, this indicates that the dev team tried to fix it, yet for one reason or another didn´t do it. Perhaps they thought the problem was too complex, too time-consuming, too prone to cause other problems by fixing it or something like that. We are very likely to hit the same problems they did, so chances are that any fix of this problem will take quite a lot of time. Far better, in my opinion to get our feets wet with problems we are certain that we can solve than attack the biggest one head on.

 

[Jamie550]

Is that like MTTH(Mean time) system in EU3 ?

What about ghostfleet problem ?

No, it just means that if an event has startdate 1940 and enddate 1944, its other conditions will only be checked in 1940, 1941, 1942, 1943, and 1944. This is more efficient than checking it every year from 1936 on.


White Daimon: Do you already have the source or something? How did you know how events are checked?

So we are allowed to do these small performance-enhancing improvements?

Also, for events on the hour, we could make 23 lists of events on the nonzero hours and check the appropriate list each hour?

 

[IndoEsia45]

Ow..yeah i understood.

Anyway now i am trying to get VC 6.0.

 

[unmerged(76495)]

No, it just means that if an event has startdate 1940 and enddate 1944, its other conditions will only be checked in 1940, 1941, 1942, 1943, and 1944. This is more efficient than checking it every year from 1936 on.

Ahh, I didn´t know they did this. Clever, thinks this makes my idea slightly less useful. Although it likely still is.

White Daimon: Do you already have the source or something? How did you know how events are checked?

I don´t have the source. I´m just referring to what I assume and think must be true. What are you specificly referring to?

So we are allowed to do these small performance-enhancing improvements?

That would be up to the group to decide. Coreymas seems very keen to do this, I certainly wouldn´t mind my game running faster.

Also, for events on the hour, we could make 23 lists of events on the nonzero hours and check the appropriate list each hour?

Thats an option. But again, wouldn´t that just use too much memory for it to be worthwhile?

 

[Jamie550]

Ahh, I didn´t know they did this. Clever, thinks this makes my idea slightly less useful. Although it likely still is.

Actually, I was explaining to IndoEsia45 what my understanding of our tentative proposed plan was. I thought that the events are checked every day every year as you stated. Is my understanding of your proposal incorrect?

That would be up to the group to decide. Coreymas seems very keen to do this, I certainly wouldn´t mind my game running faster.

If we did do enhancements, would our project still be free?

 

[unmerged(76495)]

Is my understanding of your proposal incorrect?

I think we are talking past each other right now... Not quite sure what you´re saying. I proposed something about streamlining the event checking system, but actually it could be that there already is a more effective system than what it looks like on the surface. Think that perhaps I should just slow down and wait until I´ve actually seen the code before I suggests improvements

If we did do enhancements, would our project still be free?

Dunno, will have to ask paradox. But I think so, since this is basicly performence enhancement rather than new features or similair.

 

[The Great Duck]

Well,I think Paradox added 500 new province ids in a patch for EU2,so I think such features would be free.If the patch will add features,I think new province ids and change_flag command should be the first added.Fixing the bugs should be the priority,though.

 

[coreymas]

Well,I think Paradox added 500 new province ids in a patch for EU2,so I think such features would be free.If the patch will add features,I think new province ids and change_flag command should be the first added.Fixing the bugs should be the priority,though.

I do not think this qualifies as a Bug fix..... The game is functioning as designed with the current number of provinces/country tags.

We have to be very careful about what we change to ensure that the changes remain in the free category.

The performance enhancements that we are suggesting are very small ones... and right now it would be extremely persumptuous of me to think that something like the Ghost Fleet bug would be something easily fixed.

The first steps once the source code is available is to understand how the code works. This is going to take a significant amount of time (read months here.... not hours or days). After that it would be prudent to start off with small fixes (usually the cosemetic ones are the best to start off with as they are readily apparent when they are fixed)

Then more serious issues (like the 1.2 Arma Para bug and the Ghost fleet issue) would be issues to tackle next.

Then finally once a developer has gained experience working with the engine would performance enhancements like the event code be worth looking at.

Corey

 

[The Great Duck]

I didn't say it is a bug fix.I just said that some small enhancement may go through as free.